-
-
-
-|
-
-wxWidgets 2 FAQ: General
-
- |
-
-
-
-
-
-See also top-level FAQ page.
-
-List of questions in this category
-
-
-
-
-
-wxWidgets is a class library that allows you to compile graphical C++ programs on a range of
-different platforms. wxWidgets 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 are several dialog editors to help
-build attractive dialogs and panels. Robert Roebling's wxDesigner
-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 wxWidgets: there is a Python interface for wxWidgets 2,
-and also a Perl interface.
-
-
-
-
-Yes. Please see the licence for details, but basically
-you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets
-conflict with GPL code you may be using or developing with it.
-
-The conditions for using wxWidgets 2 are the same whether you are a personal, academic
-or commercial developer.
-
-
-
-
-No official support, but the mailing list is very helpful and some people say that
-wxWidgets 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
-wxWidgets 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.
-
-See Users for a list of some users and their applications, and
-also Feedback for comments.
-Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch Kapor
-and his Open Source Applications Foundation.
-
-
-
-
-
-- Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME.
-
- Linux and other Unix platforms with GTK+.
-
- Unix with Motif or the free Motif clone Lesstif.
-
- Mac OS.
-
- Embedded platforms are being investigated. See the wxUniversal project.
-
- An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif
-on OS/2.
-
-
-
-
-
-This is a hotly-debated topic amongst the developers. My own philosophy
-is to make wxWidgets 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 wxWidgets-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, 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 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 wxWidgets 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.
-
-
-
-No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in
-wxWidgets' 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
-wxWidgets 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
-wxWidgets 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. 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:
-
-
-#ifdef new
-#undef new
-#endif
-
-
-
-
-
-
-
-These are the possibilities so far:
-
-
-- See www.scintilla.org for
-a very nice syntax-highlighting editor widget. Robin Dunn has written a wxWidgets wrapper
-for this widget, available in the wxWidgets distribution under contrib/src/stc.
-
- If you only need to display marked-up information, rather than edit it,
-then wxHTML will suit your needs. wxHTML is built into wxWidgets - please see the reference
-manual for details, and samples/html.
-
- There are rich edit widgets in both WIN32 and GTK+, but there is currently
-no wxWidgets wrapper for these (but text attribute functions are being added in the wxWidgets 2.3.x series).
-
-
-
-
-
-
-wxWidgets library itself is unfortunately not exception-safe (as its
-initial version predates, by far, the addition of the exceptions to the C++
-language). However you can still use the exceptions in your own code and use
-the other libraries using the exceptions for the error reporting together with
-wxWidgets.
-
-
-There are a few issues to keep in mind, though:
-
- - You shouldn't let the exceptions propagate through wxWidgets code,
- in particular you should always catch the exceptions thrown by the
- functions called from an event handler in the handler itself and not
- let them propagate upwards to wxWidgets.
-
-
- You may need to ensure that the compiler support for the exceptions is
- enabled as, considering that wxWidgets itself doesn't use the
- exceptions and turning their support on results in the library size
- augmentation of 10% to 20%, it is turned off by default for a few
- compilers. Moreover, for gcc (or at least its mingw version) you must
- also turn on the RTTI support to be able to use the exceptions, so you
- should use --disable-no_rtti --disable-no_exceptions options
- when configuring the library (attention to the double negation).
-
-
-
-
-
-
-We are using the CVS system to develop and maintain wxWidgets. This allows
-us to make alterations and upload them instantly to the server, from
-which others can update their source.
-
-To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution
-directory.
-
-
-
-By ftp, and via the wxWidgets CD-ROM.
-
-If you are feeling adventurous, you may also check out the sources directly
-from cvs.
-
-
-
-
-Currently we're working too hard on getting wxWidgets finished (are GUI toolkits ever
-finished?) to think very far ahead. However, we know we want to make wxWidgets 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 PNG and XPM for all platforms.
-
-Other possibilities include: DCOM/CORBA compatibility; a wxWidgets book;
-wxWorkshop, an IDE;
-other platforms, especially embedded systems; other interface abilities such as speech output.
-
-We will investigate the possibility of compiler or operating system vendors bundling wxWidgets with
-their product.
-
-The high-level goal of wxWidgets is to be thought of as the number one C++ framework,
-for virtually any platform. Move over, MFC!
-
-
-
-wxBase is a subset of wxWidgets comprised by the non-GUI classes. It includes
-wxWidgets container and primitive data type classes (including wxString,
-wxDateTime and so on) and also useful wrappers for the operating system objects
-such as files, processes, threads, sockets and so on. With very minor
-exceptions wxBase may be used in exactly the same way as wxWidgets but it
-doesn't require a GUI to run and so is ideal for creating console mode
-utilities or server programs. It is also possible to create a program which can
-be compiled either as a console application (using wxBase) or a GUI one (using
-a full featured wxWidgets port).
-
-
-
-The main difference between wxUniversal-based ports (such as wxX11, wxMGL) and other ports (such as wxMSW, wxGTK+, wxMac)
-is that wxUniversal implements all controls (or widgets) in
-wxWidgets itself thus allowing to have much more flexibility (for example, support for
-themes even under MS Windows). It also means that it is now much easier to
-port wxWidgets to a new platform as only the low-level classes must be ported
-which make for a small part of the library.
-
-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 wxWidgets is as high as ever.
-
-
-
-Microsoft is spending a lot on promoting the .NET initiative, which
-is a set of languages, APIs and web service components for Windows.
-Ximian has started an open source version of .NET, mostly for Linux.
-C# is Microsoft's alternative to Java, supporting 'managed code',
-garbage collection and various other Java-like language features.
-
-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.
-
-
-- Not everyone wants or needs net services.
-
- C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain.
-
- Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as
-wxWidgets (I'm aware there is GTK# for use with the C# language).
-
- C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer
-that wxWidgets does not require.
-
- Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
-
- You may not wish to buy into Microsoft marketing spin and APIs.
-
- Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all,
-platform-independence is not in Microsoft's interest.
-
- .NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
-
- wxPython and other language variants provide further reasons for wxWidgets to continue.
-
- The same issue exists for Qt: if Qt sales remain strong, it's a good indication that
-the market for a C++-based approach is still there. (Either that, or everyone's turning to wxWidgets!)
-
-
-There is nothing to stop folk from developing a C# version of the wxWidgets API;
-we already have bindings to Python, Perl, JavaScript, Lua, Basic, and Eiffel.
-Update: a wx.NET project is now in progress.
-
-
-
-
-
-Please check out the Community pages,
-in particular the suggested projects, and
-mail the developers' mailing list with your own suggestions.
-
-
-
-
-
-