-<li>In 2 there is far more flexibility, for example in the way windows can be
-nested, and the way events are intercepted.
-<li>There is more functionality for producing sophisticated applications,
-for example using the wxTreeCtrl and wxListCtrl classes.
-<li>There is better C++-conformance (such as usage of wxString and const) which
-will make your applications more reliable and easier to maintain.
-<li>wxWindows 2 will be better supported than 1.xx.
-<li>The GTK version is attractive for people interested in writing Linux and GNOME
-applications.
-<li>The Mac version will be one of the best frameworks available on that platform.
-</ul>
-
-<H3>How can I prepare for wxWindows 2?</H3>
-
-To make porting to wxWindows 2 easier in the future, take a look at some
-<a href="http://www.wxwindows.org/prepare.htm">tips</a> for writing existing code in a 2-compatible way.<P>
-
-<H3>How much has the API changed since 1.xx?</H3>
-
-It's difficult to summarize, but some aspects haven't changed very much. For example, if you have some
-complex drawing code, you will mostly need to make sure it's parameterised with a device
-context (instead of obtaining one from a window or storing it). You won't have
-to completely rewrite the drawing code.<P>
-
-The way that events are handled has changed, so for example, where you overrode
-OnSize before, you now have a non-virtual OnSize with a single event class argument.
-To make this function known to wxWindows, you add an entry in an 'event table' using macros. Addition of these macros
-will eventually be made easier by a tool which will allow selection from a list
-and copy-and-paste into your editor. This is extended to button presses, listbox selection
-etc. so callbacks have gone (they may be added back for limited backward compatibility).<P>
-
-The class hierarchy has changed to allow greater flexibility but it probably won't affect your
-existing application. One exception to this is MDI applications which now use separate MDI classes instead of style
-flags. As a result, it won't be possible to switch between MDI and SDI operation at run-time
-without further coding, but a benefit is less interdependence between areas of code,
-and therefore smaller executable size.<P>
-
-Panel items (now called controls) no longer have labels associated with most of them,
-and default panel layout has been removed. The idea is that you make greater use
-of dialog resources, for better-looking dialogs.<P>
-
-<H3>What classes have disappeared?</H3>
-
-wxForm, wxTextWindow (subsumed into wxTextCtrl).
-
-<H3>Does wxWindows 2 mean that wxWindows 1.xx is dead?</H3>
-
-While wxWindows 2 is being developed, there will be further patches to wxWindows 1.xx.
-Obviously we are investing most of our energy into the new code, but we're also trying
-to fix bugs in the current version.<P>
-
-<H3>What platforms will be supported by wxWindows 2?</H3>
-
-<ul>
-<li>Windows 3.1, Windows 95/98, Windows NT;
-<li>Linux and other Unix platforms with GTK+;
-<li>Unix with Motif or the free Motif clone Lesstif;
-<li>Mac (coming later in 1999);
-<li>A BeOS port is being investigated.
-<li>A Windows CE port is being investigated.
-<li>There are no plans to support OS/2 or XView. However,
-you may be able to compile the GTK and Motif versions under OS/2 with X and GTK
-installed, or the Windows version with IBM's Open32 extensions.
projects / wxWidgets.git / blobdiff