Development: Todo List

This is a collection of the various things which it would be nice to include in wxWidgets. They may or may not be scheduled or funded. If you're interested in helping with wxWidgets development, one of the small projects below could be a great way to join the team!

General

High priority

• Implementing a platform independent rendering engine using Cairo (making the current wxDC & co. obsolete): for a more comprehensive list of the needed features see here: http://doc.trolltech.com/4.3/qt4-arthur.html; it's important to achieve drawing capabilities on widgets, opengl contexts, bitmap and printers with the same API.

• Implementing PDF printer (see above)

• Implementing/using a signal/slot based architecture throughout the whole library: it's easier to understand and makes the code cleaner and shorter

• The documentation should include parent/child class relationship

• Give wxFileSystem a better API and further integrate it with wxWidgets (currently only wxHtml uses it but it could be also used by many other classes)

• wxHTML2, using native HTML renderers where available

• Implementing a powerful text control architecture like QTextEdit in Qt4

• wxString: use a faster search algorithm; find and replace: use regular expressions, case sensitive options; encoding conversion functions; splitting/explode functions; for a more comprehensive list of the needed features see here: http://doc.trolltech.com/4.3/qstring.html

• Throughout use of smart (reference counted) pointers in wxWidgets with no macros

• DirectX 9 support to make it as easy as possible to create DirectX applications

• Official support/maintenance of at least one opensource audio library (this is what multimedia programmers miss in wxWidgets)

• Finish wxDataViewControl:
  • Add support for hierarchical structure (so that it could replace wxTreeCtrl as well as wxListCtrl)
  • Write native wxMSW and wxMac implementations

(note that this is one of our GSoC 2007 projects)

• Provide a possibility to use individual wxUniv controls from the native ports

• Add image support to wxButton (Jamie Gadd has the patch for wxMSW, with a bit work it should be extended to others ports) merging wxBitmapButton with wxButton, see this thread for more information.

• Implement wxMaskedTextCtrl in C++ (it's already available in wxPython)

• Update the included third party libraries, especially libtiff which is currently a modified 3.6.1 version while 3.8.2 is available and fixes a lot of bugs, some of them fatal.

Medium priority

• MIME types code needs a cleanup and a GUI interface to allow setting the MIME types and related information from the program itself

• wxReBar control (moveable toolbars, menubars) - see http://www.planet-berlin-it.de/project/wxCoolBar for an already existing implementation

• Avoid calling the wxYield family of functions in internal code. wxYield causes problems in combination with pending events leading to all sorts of strange side-effects.

• Move wxApp::Yield() to wxEventLoop::Yield(), where it logically belongs (see wxDFB port for partial step in this direction)

• add persistent control support: see PersistentControls page for more info

• add wxFont::SetAntiAliasingMode(enum { Default, On, Off }) method which can be implemented easily at least for MSW by using the corresponding LOGFONT::lfQuality values.

• add possibility to add custom controls to file open dialog, e.g. ideally by providing a virtual GetCustomControlsSizer() function in it which could be overridden to create a sizer containing the custom controls which would then be inserted in the standard dialog in an appropriate way (and the events from them would be processed normally)

Low priority

• Write wxConfig implementation using XML as backend:
  • portable wxXMLConfig for all platforms (there is a version doing it here and here but it duplicates too much of wxFileConfig code unfortunately)
  • wxApplePrefConfig for working with .pref files on Mac OS X

• wxStaticBox: Hide the platform problems (GTK: 'children' must be siblings) in encapsulation in order to avoid problems on ports where the hierarchy must be 'correct'.

• Standard menu and toolbar customization dialogs

• Extend wxLocale to return more information, e.g. currency formatting, list separator, ...

• Improve wxSpinCtrl to allow showing something else than just its value in the text field. This should be done by implementing support for wxSpinCtrlFormatter class which would have Format() and Parse() virtual methods which could be implemented by a user-defined class which the user coode would associate with the control and which would mediate the conversion between the value and the text field contents.

• Remove wxUSE_PROLOGIO stuff from contrib/src/ogl sources to suppress warnings about wxUSE_PROLOGIO not being defined (this is trivial)

Everything else

• Synchronisation API between mobile and desktop.
• Extend and unify drag and drop handling (e.g. we need to specify multiple drop targets that can handle multiple formats).
• Serial and parallel port support.
• Modem and telephony support.
• Improve accessibility support.
• wxDC Support for point to char-position with text rendering

Documentation

• The possibility of moving doc into header files with tool support, or translation to XML with support from scripts (comparison of headers and documentation).
• Detailed review of doc accuracy.
• wxDC: Precise definition of default/initial state.
• wxDC: Pixelwise definition of operations (e.g. last point of a line not drawn).
• Events: for all controls state clearly when calling a member function results in an event being generated and when it doesn't (possibly updating also the 'Events generated by the user vs programmatically generated events' paragraph of the 'Event handling overview' with the list of the functions which break that rule).
• Coordinates: state clearly which type of coordinates are returned by the various Get*Point() or similar functions - often they are client coordinates but not always
• Document all wxUSE_XXX settings (it would be also nice to centralize their definitions in a single file instead of having them in several different setup.h)
  See patch 1755127 "Add wxUSE Doc as tex file" as partial solution.
• Update the coding standards guide

Infrastructure

• Set up [buildbot] or similar system for continuous build tests
• Use SourceForge compile farm (or other facilities) to automatically spin at least some of the releases using a specification of the type of release, tag to use, etc.
• Make building Debian packages less painful, in particular try to make it possible to build them in the source tree instead of current roundabout way; automate building of both ANSI and Unicode packages (the former doesn't work with dpkg-buildpackage as there is no way to pass WX_UNICODE=0 to debian/rules when using it).