-Although GUI applications are mostly built programmatically, there is a dialog editor to help +Although GUI applications are mostly built programmatically, there are several dialog editors to help build attractive dialogs and panels. Robert Roebling's wxDesigner -makes light work of resizable, portable dialogs.
+and Anthemion Software's DialogBlocks +are two commercial examples, but there are others: see the Useful Tools page.
-You don't have to use C++ to use wxWindows: there is a Python interface for wxWindows 2, +You don't have to use C++ to use wxWidgets: there is a Python interface for wxWidgets, and also a Perl interface.
-
-The conditions for using wxWindows 2 are the same whether you are a personal, academic +The conditions for using wxWidgets are the same whether you are a personal, academic or commercial developer.
-
@@ -89,7 +94,7 @@ Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch K and his Open Source Applications Foundation.
-
-
-In other words, wxWindows is not a 'lowest common denominator' approach, +In other words, wxWidgets is not a 'lowest common denominator' approach, but it will still be possible to write portable programs using the core API. Forbidding some platform-specific classes would be a stupid approach that would alienate many potential users, and encourage -the perception that toolkits such as wxWindows are not up to the demands +the perception that toolkits such as wxWidgets are not up to the demands of today's sophisticated applications.
Currently resources such as bitmaps and icons are handled in a platform-specific way, but it is hoped to reduce this dependence in due course.
-Another reason why wxWindows 2 is not a 'lowest common denominator' toolkit is that +Another reason why wxWidgets is not a 'lowest common denominator' toolkit is that some functionality missing on some platform has been provided using generic, platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.
-
+wxWidgets is strenuously trying to avoid.
The standard C++ string class is not used, again because it is not available to all compilers, and it is not necessarily a very efficient implementation. Also, we retain more flexibility @@ -148,7 +153,7 @@ by being able to modify our own string class. Some compatibility with the string has been built into wxString.
There is nothing to stop an application using templates or the string class for its own -purposes. With wxWindows debugging options on, you may find you get errors when including +purposes. With wxWidgets debugging options on, you may find you get errors when including STL headers. You can work around it either by switching off memory checking, or by adding this to a header before you include any STL files:
@@ -161,41 +166,41 @@ or by adding this to a header before you include any STL files:
-
-
There are a few issues to keep in mind, though:
-
-To build source from CVS, see the file BuildCVS.txt in the top-level wxWindows distribution +To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution directory.
-
If you are feeling adventurous, you may also check out the sources directly from cvs.
+
You may find more about wxUniversal here. @@ -267,14 +264,104 @@ You may find more about wxUniversal here. The Java honeymoon period is over :-) and people are realising that it cannot meet all their cross-platform development needs. We don't anticipate a major threat -from Java, and the level of interest in wxWindows is as high as ever.
+from Java, and the level of interest in wxWidgets is as high as ever.
+ +
+ +Although this may be attractive to some developers, there +is a variety of reasons why the .NET/Mono combination is unlikely +to make wxWidgets redundant. Please note that the following comments +are Julian Smart's opinions.
+ +
+
+Each port consists of a platform-specific part (e.g. src/msw, include/wx/msw), +a generic set of widgets and dialogs for when the port doesn't support +them natively (src/generic, include/wx/generic) and the common code +that all ports use (src/common, include/wx). By browsing the source +you should get a good idea of the general pattern.
+ +Take a port that most closely matches your port, and strip out +the implementation so you have a skeleton port that compiles. Ask on wx-dev +first for the wxStubs port - however, any such predefined skeleton +port may be out of date, so make a judgement on whether to use it. +Perhaps it will still save you time to clean up wxStubs, and +others may benefit from this too.
+ +You will need to define a symbol for the new port, e.g. __WXXBOX__. +Look at files such as wx/defs.h, wx/wxchar.h for areas where you'll +need to add to existing conditionals to set up wide character +support and other issues. If the GUI runs on a Unix variant, +define the __UNIX__ variable in your makefile.
+ +Then you can start implementing the port, starting with +wxWindow, wxTopLevelWindow, wxFrame, wxDialog so you +can get the minimal sample running as soon as possible.
+ +If GDI objects (wxPen, wxBrush, etc.) are not concepts in your +native GUI, you may wish to use very generic versions of +some of these - see the wxX11 port.
+ +Consider using the wxUniversal widget set as a quick way +to implement wxWidgets on your platform. You only need +to define some basic classes such as device contexts, +wxWindow, wxTopLevelWindow, GDI objects etc. and +the actual widgets will be drawn for you. See wxX11, +wxMGL, and wxMSW/Univ for sample wxUniversal ports.
+ +To begin with, you can use whatever makefiles or project +files work for you. Look at existing makefiles to see what +generic/common/Unix files need to be included. Later, you'll want to integrate support +for your port into configure (Unix-like systems and gcc under Windows), +and bakefile (for other makefiles on Windows).
+ +Submit your port as patches via SourceForge; you might +wish to separate it into one patch that touches common headers +and source files, and another containing the port-specific code, to make +it much easier for us to review and apply the patches.
+ +Good luck! +