From: www.itworld.com
March 29, 2001 —
Since last summer, our series on GUI toolkits has applauded Qt's polish, Tk's portability, Motif's rich third-party support, and GTK+'s ambition. wxWindows is a competitor that possesses all of those characteristics and more.
Free GUI framework
Is that news to you? Is this the first you've heard of wxWindows? It's certainly not a newcomer to the development marketplace. Julian Smart created wxWindows in 1992 while doing research with the Artificial Intelligence Applications Institute in Edinburgh, Scotland. wxWindows is a "free C++ framework to make cross-platform programming child's play (almost)," according to its official Website. Its cross-platform capabilities already extend to Mac OS, Unix, and Windows.
It's a bit unfair of us to present wxWindows exclusively as a GUI library, even though that is what Smart first released it as. Of course, we've set this series up as a comparison of different GUI toolkits, but each subject is not just a different toolkit, but a different kind of toolkit. Motif, the senior member of the group, is a GUI library and also a style guide and windowing manager, which bundles a user interface language (UIL). The others also have individual biographies. To keep the series manageable and coherent, though, our profiles focus primarily on the GUI-toolkit aspect.
Even with that restriction, the wxWindows architecture demands some explanation. It is indeed a GUI toolkit, and developers use it as such without knowing more about it. Bundled with its GUI functionality, though, are several distinct elements that are powerful advantages for certain projects: standard drag-and-drop functionality, an online help system, special-purpose persistence, printing, portable threading, and a higher-level networking layer that supports FTP and HTTP.
Another complication in explaining wxWindows is its reliance on native toolkits for low-level GUI functionality. This simplifies the daily work of programmers who use wxWindows; however, it's sufficiently different from the design of competing toolkits to confuse wxWindows novices. Current versions of wxWindows support two flavors of Unix implementation: GTK+ and Motif. That means that if you like the GNOME look, you'll get it -- almost down to the last pixel -- with wxWindows for GTK+. wxWindows also has good performance; its applications occasionally even outperform native codings, because in certain instances, the library's quality is higher than a C++ coder would likely achieve on his or her own.
This toolkit layering makes wxWindows admirably portable, which occasionally surprises newcomers. The same source code works under different operating systems; however, applications look different, depending on their flavor. The Windows executable has a standard Microsoft Foundation Classes (MFC) appearance, because both use Win32 widgets. This is what most organizations want, although many don't know it when they begin to specify projects.
Industrial strength
Developers seem to like wxWindows. It's quite rich, with its help system, sophisticated HTML and image viewers, and other specialized widgets, extensive documentation, and printing capabilities. Active mailing lists discuss a variety of wxWindows-related subjects. The project sports an impressive number of applications that rely on wxWindows libraries for their GUIs, including:
Engineering teams seem to decide on wxWindows quite deliberately: several project leaders mentioned that they'd examined other GUI toolkits, but found them too slow or a poor match for other software tools.
With so many strengths -- a proven track record, good performance, a liberal license, superior portability, and mature code -- why has wxWindows remained what one industry observer dismissed as "a niche product"?
First, its widget model is slightly different from GNOME's, which several Unix vendors adopted as a standard this year. While GTK+ and wxWindows handle the same general tasks, a few GTK+ widgets have no exact wxWindows equivalent, and vice versa.
Second, wxWindows's longevity is a bit deceptive. Vadim Zeitlin, a doctoral candidate at Ecole Normale Supérieure de Cachan who maintains drag-and-drop, string classes, and other aspects of wxWindows, emphasizes the significance of the first major rewrite, done in the mid-1990s: "wxWin 2 is very different from wxWin 1, and wxWin 2 is only 3 to 4 years old." Its focus on C++ may have been a mistake, in the decade of Java's emergence, and for several years, US development organizations were skeptical of a product given away by British academics. Its portability was a liability for programming groups who believed in the wisdom of coding to native facilities.
Move to the center
The feeling that wxWindows lives only on the periphery of the computing universe has evaporated somewhat. Java hasn't taken over yet: Java GUI programming is still more frustrating and less satisfying than its advertised image. Articles on wxWindows are popping up in more magazines, with several scheduled for spring 2001. Linux's success has refocused attention on portability. Robin Dunn of Total Control Software has produced an excellent Python binding for wxWindows, introducing the framework's virtues to a whole new audience.
Perhaps most importantly, wxWindows now has venture-capital backing -- in a sense -- and it's attracting attention in embedded-computing circles. A few years ago, wxWindows might have seemed too anarchic or unrealistic to enterprise managers. While wxWindows's core of maintainers is highly talented, it's been hard to explain to corporations. Even now, Smart has yet to "meet any of my main colleagues on wxWindows." However, he has joined publicity master Red Hat as a full-time software engineer, based in Cambridge, England. He's now attached to the embedded configurable operating system (eCos) group. Red Hat enhances, customizes, and supports eCos on a commercial basis. Smart's current responsibility is to port Windows-based eCos tools to Linux, substituting wxWindows for MFC. On his own time, he's already looking into running wxWindows on eCos and the Psion operating system (EPOC).
Near-term prospects
That's not the only excitement in the wxWindows world. Although the official wxWindows Website is adequate for many wxWindows learners, Smart has decided, "Yes, we really do need a wxBook!" Therefore, the core team of about a dozen developers is also collaborating on an authoritative wxWindows book. Without waiting for the book's publication, work has begun on wxStudio, a sophisticated integrated development environment (IDE) targeted at wxWindows. And, Mattia Barbon has just released the first version of a Perl wrapper for wxWindows.
Like other toolkits, wxWindows has an XML connection. wxWindows should support XML resources by this winter; that advance will be greeted warmly by those who face the arduous task of coding portable dialogues against native Windows and X resource files.
In addition, Zeitlin is refactoring the internals of wxWindows, in what he calls the wxUniv port. This universal port will greatly enhance portability "because it implements all its own widgets," said Smart. Zeitlin said wxBeOS and wxQNX are already on the horizon, and should be completed in a few weeks. The old code design would have required a year.
Getting started
How do you make your own start with wxWindows? wxWindows.org is the place to begin. It's easy to find descriptions, downloads, mailing lists, class library references, and tutorials there. Installable binary libraries for popular platforms are also handy.
Robert Roebling offers a fully commented expansion of this "Hello, World" at his Website:
#include "wx/wx.h"
class MyApp: public wxApp
{
virtual bool OnInit();
};
class MyFrame: public wxFrame
{
public:
MyFrame(const wxString& title,
const wxPoint& pos,
const wxSize& size);
void OnQuit(wxCommandEvent& event);
void OnAbout(wxCommandEvent& event);
private:
DECLARE_EVENT_TABLE()
};
enum
{
ID_Quit = 1,
ID_About,
};
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU(ID_Quit, MyFrame::OnQuit)
EVT_MENU(ID_About, MyFrame::OnAbout)
END_EVENT_TABLE()
IMPLEMENT_APP(MyApp)
bool MyApp::OnInit()
{
MyFrame *frame = new MyFrame( "Hello World",
wxPoint(50,50),
wxSize(450,340) );
frame->Show( TRUE );
SetTopWindow( frame );
return TRUE;
}
MyFrame::MyFrame(const wxString& title,
const wxPoint& pos,
const wxSize& size)
: wxFrame((wxFrame *)NULL, -1, title, pos, size)
{
wxMenu *menuFile = new wxMenu;
menuFile->Append( ID_About, "&About..." );
menuFile->AppendSeparator();
menuFile->Append( ID_Quit, "E&xit" );
wxMenuBar *menuBar = new wxMenuBar;
menuBar->Append( menuFile, "&File" );
SetMenuBar( menuBar );
CreateStatusBar();
SetStatusText( "Welcome to wxWindows!" );
}
void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event))
{
Close( TRUE );
}
void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
{
wxMessageBox(
"This is a wxWindows's Hello world sample",
"About Hello World",
wxOK | wxICON_INFORMATION );
}
wxWindows supports two different styles of callback definition. This example shows the more popular one, which relies on event tables. They implement a small frame with two menu choices, "About" and "Quit." You can begin to see how much easier wxWindows is to use than the other popular toolkits bound to C++.
Resources
Unix Insider