wxWidgets is a programmer’s toolkit for writing desktop or mobile applications with graphical user interfaces (GUIs). It’s a framework, in the sense that it does a lot of the housekeeping work and provides default application behavior. The wxWidgets library contains a large number of classes and methods for the programmer to use and customize. Applications typically show windows containing standard controls, possibly drawing specialized images and graphics and responding to input from the mouse, keyboard, or other sources. They may also communicate with other processes or drive other programs. In other words, wxWidgets makes it relatively easy for the programmer to write an application that does all the usual things modern applications do.

While wxWidgets is often labeled a GUI development toolkit, it is in fact much more than that and has features that are useful for many aspects of application development. This has to be the case because all of a wxWidgets application needs to be portable to different platforms, not just the GUI part. wxWidgets provides classes for files and streams, multiple threads, application settings, interprocess communication, online help, database access, and much more.

One area where wxWidgets differs from many other frameworks, such as MFC or OWL, is its multi-platform nature. wxWidgets has an Application Programming Interface (API) that is the same, or very nearly the same, on all supported platforms. This means that you can write an application on Windows, for example, and with very few changes (if any) recompile it on Linux or Mac OS X. This has a huge cost benefit compared with completely rewriting an application for each platform, and it also means that you do not need to learn a different API for each platform. Furthermore, it helps to future-proof your applications. As the computing landscape changes, wxWidgets changes with it, allowing your application to be ported to the latest and greatest systems supporting the newest features.

Another distinguishing feature is that wxWidgets provides a native look and feel. Some frameworks use the same widget code running on all platforms, perhaps with a theme makeover to simulate each platform’s native appearance. By contrast, wxWidgets uses the native widgets wherever possible (and its own widget set in other cases) so that not only does the application look native on the major platforms, but it actually is native. This is incredibly important for user acceptance because even small, almost imperceptible differences in the way an application behaves, compared with the platform standard, can create an alienating experience for the user. To illustrate, Figure 1-1 shows a wxWidgets application called StoryLines, a tool to help fiction writers plot their stories, running on Windows XP.

Figure 1-1 StoryLines on Windows

It’s recognizably a Windows application, with GUI elements such as tabs, scrollbars, and drop-down lists conforming to the current Windows theme. Similarly, Figure 1-2 shows StoryLines as a Mac OS X application, with the expected Aqua look and feel. There is no menu bar attached to the StoryLines window because it follows the Mac OS convention of showing the current window’s menu bar at the top of the screen.

Figure 1-2 StoryLines on Mac OS X

Finally, Figure 1-3 shows StoryLines as a GTK+ application running on Red Hat Linux.

Figure 1-3 StoryLines on Linux

Why not just use Java? While Java is great for web-based applications, it’s not always the best choice for the desktop. In general, C++-based applications using wxWidgets are faster, have a more native look and feel, and are easier to install because they don’t rely on the presence of the Java virtual machine. C++ also allows greater access to low-level functionality and is easier to integrate with existing C and C++ code. For all these reasons, very few of the popular desktop applications that you use today are built with Java. wxWidgets allows you to deliver the high-performance, native applications that your users expect.

wxWidgets is an open source project. Naturally, this means that it costs nothing to use wxWidgets (unless you feel like generously donating to the project!), but it also has important philosophical and strategic significance. Open source software has a habit of outlasting its proprietary equivalents. As a developer using wxWidgets, you know that the code you rely on will never disappear. You can always fix any problems yourself by changing the source code. It can also be a lot more fun to take part in an open source community than trying to get hold of corporate support staff. Participants in open source projects tend to be there because they love what they’re doing and can’t wait to share their knowledge, whereas corporate support staff members are not always so idealistically motivated. When you use wxWidgets, you tap into an astonishing talent pool, with contributors from a wide range of backgrounds. Many aspects of application development that you might otherwise have to laboriously code yourself have been encapsulated by these developers in easy-to-use classes that you can plug into your code. An active user community will assist you on the mailing lists, and you’ll enjoy discussions not only about wxWidgets but often other matters close to the hearts of both experienced and inexperienced developers as well. Perhaps one day you’ll join in the success of wxWidgets and become a contributor yourself!

wxWidgets has wide industry support, or to use a popular buzzword, mindshare. The list of users includes AOL, AMD, CALTECH, Lockheed Martin, NASA, the Open Source Applications Foundation, Xerox, and many others. wxWidgets encompasses the whole spectrum of users, from single developer software outfits to large corporations, from computer science departments to medical research groups, and from ecological research to the telecommunications industry. It’s also used by a myriad of open source projects, such as the Audacity audio editor and the pgAdmin III database design and management system.

People use wxWidgets for many different reasons, whether simply as an elegant MFC replacement on a single platform, or to allow them to move easily from (say) Microsoft Windows to Unix and Mac OS X. wxWidgets is addressing the challenges of mobile platforms, too, with ports for embedded Linux, Microsoft Pocket PC, and (soon) Palm OS.

The wxWidgets project started life in 1992 when Julian Smart was working at the University of Edinburgh on a diagramming tool called Hardy. He didn’t want to choose between deploying it either on Sun workstations or PCs, so he decided to use a cross-platform framework. Because the range of existing cross-platform frameworks was limited, and the department didn’t have a budget for it anyway, there was little choice but to write his own. The university gave him permission to upload wxWidgets 1.0 to the department’s FTP site in September 1992, and other developers began to use the code. Initially, wxWidgets targeted XView and MFC 1.0; Borland C++ users complained about the requirement for MFC, so it was rewritten to use pure Win32. Because XView was giving way to Motif, a Motif port quickly followed.

Over time, a small but enthusiastic community of wxWidgets users was established and a mailing list created. Contributions and fixes were sent in, including an Xt port by Markus Holzem. wxWidgets gradually picked up more and more users from all over the world: individuals, academics, government departments, and—most gratifying of all—corporate users who found that wxWidgets offered a better product and better support than the commercial products they had looked at or used.

In 1997, a new wxWidgets 2 API was designed with help from Markus Holzem. Wolfram Gloger suggested that wxWidgets should be ported to GTK+, the up-and-coming widget set being adopted for the GNOME desktop environment. Robert Roebling became the lead developer for wxGTK, which is now the main Unix/Linux port of wxWidgets. In 1998, the Windows and GTK+ ports were merged and put under CVS control. Vadim Zeitlin joined the project to contribute huge amounts of design and code, and Stefan Csomor started a Mac OS port, also in 1998.

1999 saw the addition of Vaclav Slavik’s impressive wxHTML classes and the HTML-based help viewer. In 2000, SciTech, Inc. sponsored initial development of wxUniversal, wxWidgets’s own set of widgets for use on platforms that have no widget set of their own. wxUniversal was first used in SciTech’s port to MGL, their low-level graphics layer.

In 2002, Julian Smart and Robert Roebling added the wxX11 port using the wxUniversal widgets. Requiring only Unix and X11, wxX11 is suitable for any Unix environment and can be used in fairly low-spec systems.

In July 2003, wxWidgets started running on Windows CE, and Robert Roebling demonstrated wxGTK applications running on the GPE embedded Linux platform.

In 2004, wxWidgets was renamed from the original moniker “wxWindows,” after objections from Microsoft based on its Windows trademark.

Also during 2004, Stefan Csomor and a host of other contributors completely revamped wxMac for OS X, significantly improving the appearance and functionality of OS X applications. A port using Cocoa was also steadily improved, led by David Elliot, and William Osborne won our challenge to deliver an embryonic Palm OS 6 port that supports the wxWidgets “minimal” sample. Version 2.6 was released in April 2005, incorporating major improvements to all ports.

Future plans for wxWidgets include

The wxWidgets community is a vibrant one, with two mailing lists: wx-users (for users) and wx-dev (for contributors). The web site has news, articles, and links to releases, and there is also the wxWidgets “Wiki,” a set of web pages where everyone can add information. A forum is also available for developers and users alike. Here’s a list of the web addresses for these resources:

As with most open source projects, wxWidgets is developed using a CVS repository, a source management system that keeps track of code history. In order to prevent a chaotic free-for-all, a small number of developers have write access to CVS, and others can contribute by posting bug reports and patches (currently handled by SourceForge’s trackers). Development occurs on two main branches: the “stable” branch, where only binary-compatible bug fixes are allowed, and the “development” branch (CVS head). So-called stable releases are even-numbered (for example, 2.4.x) and development releases are odd-numbered (for example, 2.5.x). Users can wait for new releases or download the source from the appropriate branch by anonymous CVS.

Decisions about API changes and other technical issues are made by consensus, usually by discussion on the wx-dev list. As well as the main wxWidgets community, many projects have spun off and enjoy their own communities—for example wxPython and wxPerl (see Appendix E, “Third-Party Tools for wxWidgets”).

Like all modern GUI frameworks, wxWidgets benefits from heavy use of object-oriented programming concepts. Each window is represented as a C++ object; these objects have well-defined behavior, and can receive and react to events. What the user sees is the visual manifestation of this interacting system of objects. Your job as a developer is to orchestrate these objects’ collective behavior, a task made easier by the default behaviors that wxWidgets implements for you.

Of course, it’s no coincidence that object-oriented programming and GUIs mesh well—they grew up together. The object-oriented language Smalltalk designed by Alan Kay and others in the 1970s was an important milestone in GUI history, making innovations in user interface technology as well as language design, and although wxWidgets uses a different language and API, the principles employed are broadly the same.

The wxWidgets license (officially, the “wxWindows License” for legal and historical reasons) is L-GPL with an exception clause. You can read the license files in detail on the web site or in the docs directory of the distribution, but in summary, you can use wxWidgets for commercial or free software with no royalty charge. You can link statically or dynamically to the wxWidgets library. If you make changes to the wxWidgets source code, you are obliged to make these freely available. You do not have to make your own source code or object files available. Please also consult the licenses for the optional subordinate libraries that are distributed with wxWidgets, such as the PNG and JPEG libraries.

The source code that accompanies this book is provided under the wxWindows License.

Table 1-1 shows the four conceptual layers: the wxWidgets public API, each major port, the platform API used by that port, and finally the underlying operating system.

The following are the main wxWidgets ports that exist at the time of writing.

wxGTK

wxWidgets for GTK+ can use versions 1.x or 2.x of the GTK+ widget set, on any Unix variant that supports X11 and GTK+ (for example, Linux, Solaris, HP-UX, IRIX, FreeBSD, OpenBSD, AIX, and others). It can also run on embedded platforms with sufficient resources—for example, under the GPE Palmtop Environment (see Figure 1-4). wxGTK is the recommended port for Unix-based systems.

Figure 1-4 The wxWidgets “Life!” demo under GPE on an iPAQ PDA

wxX11

wxWidgets for X11 uses the wxUniversal widget set and runs directly on Xlib with no native widget set. This makes the port suitable for embedded systems, but it can also be used for desktop applications where it is undesirable to link with GTK+. This is supported on any Unix system running X11. wxX11 is not as mature as the wxGTK port. Figure 1-5 shows the Life! demo compiled under wxX11 and running on Familiar Linux / TinyX on an iPAQ PDA.

Figure 1-5 The wxWidgets “Life!” demo running on embedded wxX11

wxWinCE

The Windows CE port encompasses various SDKs based on the Windows CE platform, including Pocket PC and Smartphone. The bulk of this port consists of the wxMSW Win32 port, with some omissions and additions for the smaller platform. Figure 1-6 shows the wxWidgets Life! demo running on the Pocket PC 2003 emulator. Figure 1-7 shows four screens from the wxWidgets dialog demo running on Smartphone 2003 with a 176 × 220 pixel display. User interface adaptations done by wxWidgets for this restricted platform include constructing a nested menu in place of the usual menu bar because Smartphone only supports two menu buttons. Some additional application hints are required, such as calling SetLeftMenu and SetRightMenu instead of adding conventional OK and Cancel buttons to a dialog.

Figure 1-6 The wxWidgets “Life!” demo on Pocket PC 2003

Figure 1-7 The wxWidgets “dialogs” demo on Smartphone 2003

wxPalmOS

This is a port to Palm OS 6 (Cobalt). At the time of writing, the port is in its infancy but can be used to compile and run a simple sample in the Palm OS 6 simulator (see Figure 1-8).

Figure 1-8 A wxWidgets sample under Palm OS 6

In this chapter, we’ve established what wxWidgets is, described a little of its history, summarized the available ports, and taken a brief look at how the library is organized internally.

In the next chapter, “Getting Started,” we will look at some sample code and get a feeling for what it’s like to write a wxWidgets application.