-
-
-
-|
-
-wxWindows 2 FAQ: General
-
- |
-
-
-
-
-
-See also top-level FAQ page.
-
-
-
-
-wxWindows is a class library that allows you to compile graphical C++ programs on a range of
-different platforms. wxWindows defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform,
-so your program will take on the native 'look and feel' that users are familiar with.
-
-Although GUI applications are mostly built programmatically, there is a dialog editor to help
-build attractive dialogs and panels.
-
-You don't have to use C++ to use wxWindows: wxWindows 1 has been interfaced to several interpreted languages,
-such as CLIPS, Python, Scheme, XLisp and Perl, and there is a Python interface for wxWindows 2.
-
-
-
Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?
-
-Yes. Please see the licence for details, but basically
-you can distribute proprietary binaries without distributing any source code, and neither will wxWindows
-conflict with GPL code you may be using or developing with it.
-
-The conditions for using wxWindows 2 are the same whether you are a personal, academic
-or commercial developer.
-
-
-
Is there support?
-
-No official support, but the mailing list is very helpful and some people say that
-wxWindows support is better than for much commercial software. The developers are
-keen to fix bugs as soon as possible, though obviously there are no guarantees.
-
-
-
-
-Many organisations - commercial, government, and academic - across the
-world. It's impossible to estimate the true number of users, since
-wxWindows is obtained by many different means, and we cannot monitor
-distribution. The mailing list contains around 300-400 entries which is
-quite large for a list of this type.
-
-
I am about to start a wxWindows 1.xx project. Should I use 2 instead?
-
-wxWindows 2 is still in beta but it's actually pretty useable (Windows, GTK, Motif).
-
-Porting to wxWindows 2 from 1.xx will not be too painful; see the next question
-for ways in which you can make it easier.
-
-
Why would I want to use wxWindows 2 in preference to wxWindows 1.xx?
-
-Some reasons:
-
-
-- In 2 there is far more flexibility, for example in the way windows can be
-nested, and the way events are intercepted.
-
- There is more functionality for producing sophisticated applications,
-for example using the wxTreeCtrl and wxListCtrl classes.
-
- There is better C++-conformance (such as usage of wxString and const) which
-will make your applications more reliable and easier to maintain.
-
- wxWindows 2 will be better supported than 1.xx.
-
- The GTK version is attractive for people interested in writing Linux and GNOME
-applications.
-
- The Mac version will be one of the best frameworks available on that platform.
-
-
-How can I prepare for wxWindows 2?
-
-To make porting to wxWindows 2 easier in the future, take a look at some
-tips for writing existing code in a 2-compatible way.
-
-
How much has the API changed since 1.xx?
-
-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.
-
-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).
-
-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.
-
-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.
-
-
What classes have disappeared?
-
-wxForm, wxTextWindow (subsumed into wxTextCtrl).
-
-Does wxWindows 2 mean that wxWindows 1.xx is dead?
-
-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.
-
-
What platforms will be supported by wxWindows 2?
-
-
-- Windows 3.1, Windows 95/98, Windows NT;
-
- Linux and other Unix platforms with GTK+;
-
- Unix with Motif or the free Motif clone Lesstif;
-
- Mac (coming later in 1999);
-
- A BeOS port is being investigated.
-
- A Windows CE port is being investigated.
-
- 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.
-
-
-
-
How does wxWindows 2 support platform-specific features?
-
-This is a hotly-debated topic amongst the developers. My own philosophy
-is to make wxWindows as platform-independent as possible, but allow in a
-few classes (functions, window styles) that are platform-specific.
-For example, Windows metafiles and Windows 95 taskbar icons have
-their own classes on Windows, but nowhere else. Because these classes
-are provided and are wxWindows-compatible, it doesn't take much
-coding effort for an application programmer to add support for
-some functionality that the user on a particular platform might otherwise
-miss. Also, some classes that started off as platform-specific, such
-as the MDI classes, have been emulated on other platforms. I can imagine
-that even wxTaskBarIcon may be implemented for Unix desktops one day.
-
-
-In other words, wxWindows 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
-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
-some functionality missing on some platform has been provided using generic,
-platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.
-
-
Does wxWindows use STL? or the standard string class?
-
-No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in
-wxWindows' best interests to avoid use of templates. Not all compilers can handle
-templates adequately so it would dramatically reduce the number of compilers
-and platforms that could be supported. It would also be undersirable to make
-wxWindows dependent on another large library that may have to be downloaded and installed.
-In addition, use of templates can lead to executable bloat, which is something
-wxWindows 2 is strenously 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
-by being able to modify our own string class. Some compatibility with the string class
-has been built into wxString.
-
-There is nothing to stop an application using templates or the string class for its own
-purposes.
-
-
How is wxWindows 2 being developed?
-
-We are using the CVS system to develop and maintain wxWindows. This allows
-us to make alterations and upload them instantly to the server in Edinburgh, from
-which others can update their source.
-
-
How is wxWindows 2 distributed?
-
-By ftp, and via the wxWindows CD-ROM.
-
-
What are the plans for the future?
-
-Currently we're working too hard on getting wxWindows 2 finished (are GUI toolkits ever
-finished?) to think very far ahead. However, we know we want to make wxWindows as robust
-and well-publicised as possible. We also want to aim for better platform-independence of
-resources such as icons and bitmaps, standardising on the PNG for all platforms.
-
-Other possibilities include: DCOM/CORBA compatibility; a wxWindows book; an
-IDE;
-other platforms; other interface abilities such as speech output.
-
-We will investigate the possibility of compiler or operating system vendors bundling wxWindows with
-their product.
-
-The high-level goal of wxWindows is to be thought of as the number one C++ framework,
-for virtually any platform. Move over, MFC!
-
-
What about Java?
-
-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.
-
-
How can I help the project?
-
-Please check out the Backroom pages,
-in particular the suggested projects, and
-mail Julian Smart or the developers' mailing list with your own suggestions.
-
-
-
-
-
-