Development: Platform Independent Notes

Bigger Issues

Development: wxFileSystem & wxUrl
wxGraphicsPaths (mailing list thread here and here)
Development: Gradients
Development: ZipStream

wxPDFDC

Zlib'ed library at http://sourceforge.net/projects/libharu/ for creating pdfs...

Theres a public domain php "library" that's less moduler and may be better for wx here (PDF-PHP).

Makefile / Project File Generator

As most of you know, wxWidgets supports a large number of platforms and compilers, and while all these compilers are performing more or less the same steps, they all use slightly different syntax to do so. What we would like, ideally, is a system which will take a set of defines, includes, libraries, and other configuration issues, and generate appropriate templates for each supported compiler and platform from them. Here are the requirements of such a system:

must not require the user installing wxWidgets to install special software. It should work natively with their platform and compiler, so that they can compile it just like any other software on their platform
must allow for compiler and platform specific defines/includes/libs, etc.
must allow for different versions of a compiler or platform
must be developed using a commonly available programming/scripting language, such as Python

wxDC::FloodFill() (Non-wxMSW Since Native)

In the docs:

Note: The present implementation for non-Windows platforms may fail to find colour borders if the pixels do not match the colour exactly. However the function will still return true.

Possibly better implementations/more info (FloodFill is simply a maze-style traversion algorithm):

RTTI with Static Builds

The problem: when a compiler compiles wxWidgets in static mode then it gets rid of RTTI code that wxWidgets doesn't use itself, but could be used by applications.

One thing that we could do is implement the RTTI of all wxWidgets classes in a single header and force compilers not to pre-compile that header. --RN
- Yes, we'd need a source file which could be included, with a method body that would be called from the app. We can have an additional method body what would be alled from a wxApp method, to make sure all "core" RTTI objects are known. This would have to be setup-nicely as not to infere with the library independencies. --Stefan Csomor

See also: the mailing list thread here

System Menus

Currently, it seems there is no documented way to change the per-window system menus in Windows and KDE, or the dock menu in OS X.

A single function in wxWindow (Maybe wxFrame) for setting this (Maybe SetSystemMenu?) should be fine.

A "wx" Namespace

Every now and the someone comes up with the idea of dropping the "wx" prefix to classes and using a namespace instead.

The general consensus seems to be that this creates more problems than it solves.

See also: