1 Enhancements for wxWindows 3.0
2 ==============================
4 This table contains the brief summary of the issues below. Priority and
5 Difficulty are values from 1 to 10 with 1 being the least important/difficult
9 ----------------------------------------------------------------------------
12 Making code exception-friendly 8 10
21 We want to have all wxWindows identifiers in "wx" namespace but provide
22 typedefs/#defines for backwards compatibility. This can be done easily
23 for the classes and the only real problem are the enums as they would
24 all have to be duplicated at both the global scope (with "wx" prefix) and
25 in wx namespace (without it)
28 This involves providing optional wxString implementation using std::string
29 and doing the same for all our containers with the exception of wxHashMap
30 which should simply be rewritten using templates (but keeping the old
31 version for backwards compatibility -- ideally wx 3.0 would still be usable
32 without templates, even if not all of its features would be available then)
35 We are not going to use exceptions in wxWindows itself but our code should
36 become exception safe. This is a very difficult task as it means that no
37 resource allocations (including memory, files, whatever) should be done
38 without using a smart pointer-like object to store the result as it is the
39 only way to prevent resource leaks in presence of exceptions
42 Optionally use the real RTTI instead of wx emulation of it. Keep the
43 current stuff for backwards compatibility.
45 - Complete replacing TRUE/FALSE with true/false
52 - use wxEventLoop in all builds
53 wxApp and wxDialog should use wxEventLoop objects (the exact class can be
54 customized by user code by overriding some wxApp::CreateEventLoop())
55 instead of duplicating the same code
57 - remove wxCOMPATIBILITY (1.X)
58 At least WXWIN_COMPATIBILITY and maybe WXWIN_COMPATIBILITY_2 code should be
59 removed from the library. wxDEPRECATED() should be used with everything
60 inside WXWIN_COMPATIBILITY_2_2. The stuff inside WXWIN_COMPATIBILITY_2_4
61 probably should not be deprecated (yet?) because this would give thousands
62 of warnings for the existing code.
64 - Modularization/Build System
65 Candidates for components:
66 + contrib widgets (and maybe some of the ones currently in the core)
73 - Project File Generation
74 We need a (GUI) tool to generate the project/makefiles for all supported
75 platforms/compilers. Not sure if it should be used for the library itself
76 (would be nice to have something like "make menuconfig" for Linux kernel
77 which allows you to navigate easily amon all of the configure/setup.h
78 options but there is a problem with distributing such tool as it can't be
79 compiled by the user because it is needed before the library is built) but
80 we definitely need it for the users makefiles.
82 - Properties/Member-Metadata, 2-Step Init with virtual create
83 TODO: still unclear what do we need exactly
85 - Tidy code and add comments to headers (preferably in
86 Doxygen/Javadoc style)
92 - The possibility of moving doc into header files with tool
94 - Detailed review of doc accuracy.
95 - wxDC : Precise definition of default/initial state.
96 - wxDC : Pixelwise definition of operations (e.g. last point of a
99 For all controls state clearly when calling a member function results in an
100 event being generated and when it doesn't.
101 - Update the coding standards guide
107 - Change Idle Handling
108 Current Implementation is using too many CPU cycles
110 - Loose Coupling Event-Source Event-Sink
111 kind of the NextStep/C# very performant coupling, exposing events via
114 - Add Lazy Init of Eventtables
123 We aim to arrive at a lazy initializiation of modules only when they are first
124 needed. Dependency information between modules is needed. Dynamic Plug-In
125 loading and unloading must be compatible with that.
131 - Renderers within native ports.
137 - Page preflighting capabilities in order to determine number
139 - Preview UI enhancement.
145 Hide the platform problems (GTK: 'children' must be siblings) in encapsulation
146 in order to avoid problems on ports where the hierarchy must be
153 In addition to wxCOMPATIBILITY code:
155 - wxProperty classes.
156 - All wxCOMPATIBILITY (1.X) code.
157 - contrib/src/canvas?
159 - contrib/src/applet?
163 - wxExpr (rewriting some OGL code or bundling wxExpr with OGL)
164 - Old resource system
167 - generic/src/htmlhelp.cpp
168 - all code that uses layout constraints,
169 so constraints can be compiled out of the
176 - wxDC Support for point to char-position with text rendering
177 - wxLocale Extension (eg Currency)
180 - a way to tell wxWindows to check for any non-portable usage,
181 for a given set of platforms. Sometimes you want to be able
182 to get away with non-portable usage, and sometimes not.
183 This is probably way too time-consuming to implement.
184 - In headers, don't silently omit contents if the features for this
185 header is switched off. Instead, emit an error message.
186 - Implement native tree view and colour dialog in wxGTK.
187 - Better way to specify About, Preferences menu ids under wxMac.
188 - Must be able to portably specify relaying out a frame after the toolbar
189 has been destroyed or recreated. On wxMSW, this is done in
190 ~wxToolBar. On wxGTK, in SetToolBar. In wxMac, not at all,
191 but sending a wxSizeEvent will do it.
192 - wxMac font selector dialog is the generic font selector -
194 - No Append(wxArrayString&) for wxChoice and wxComboBox in wxGTK.
195 Probably other functions too. Consider adding Insert to
196 these classes, as per the patch on SF.
197 - Rewrite wxFileHistory using wxString and wxArrayString, and
198 put in separate file.