interviews [3]

According to the official web site [4], wxWindows is a free framework ``to make cross-platform programming child's play. Well, almost''.

Early 2002 marks wxWindows 10th birthday, and to mark this occasion, Codingstyle has interviewed several of the project's key developers, who discussed in great detail a wide variety of topics, including what wxWindows is, where it is going; project management, cross-platform issues, and much more. For more, read on.
Codingstyle interviewed several key developers of the wxWindows framework and
related projects. Their names and general areas of responsibility are as follows:

• Julian Smart [5] (started wxWindows; Windows and Motif ports, project lead)
  
• Robert Roebling [6] (GTK port; wxDesigner RAD tool)
  
• Vadim Zeitlin [7] (many non-GUI portions of wxWindows; co-maintainer of Windows port)
  
• Vaclav Slavik [8] (wxHTML, wxMGL, XML-based resources)
  
• George Tasker [9] (wxODBC classes)

The interviews were conducted via e-mail over the span of a couple of weeks. Participants were free to answer those questions which were applicable to their area of responsibility. Some answers have been edited for clarity and brevity. There are several others who should probably have included in this interview, but in the interests of space and time they were unfortunately not.

Codingstyle: Could you please provide a summary about what wxWindows is, what platforms are supported, etc.?

Julian: wxWindows is a multi-platform programming toolkit, principally for GUI applications. Of course, most desktop applications these days are GUI applications, so the value of wxWindows is perhaps more the overall experience it gives the programmer in terms of making it relatively easy to write complex applications on a variety of platforms. wxWindows supports all 32-bit desktop variants of Windows, with limited 16-bit; both GTK+ and Motif on Unix; MacOS (beta); and soon, a range of further platforms using the 'wxUniversal' port that implements its own widgets.

Vadim: wxWindows aims to provide a comprehensive framework for writing cross-platform - but natively looking - GUI applications. The main part of it deals with the GUI support as this is arguably the most difficult problem with writing portable applications. It aims to include the classes implementing all the standard (whatever it means at the given moment - this evolves with time) attributes of a modern GUI program, in particular it explicitly doesn't limit itself to the lowest common denominator (which is a common accusation against cross-platform toolkits). Currently wxWindows has 2 production-quality ports: wxMSW (Win32, although Win16 is still supported - with some limitations) and wxGTK (Unix/X11 + GTK+). wxMac port is in [or slightly past] the beta stage and progresses rapidly. There is also wxMotif port but which is not being actively developed any longer due to the lack of use and wxOS2 port which is still in alpha. Finally, an exciting new development is the so-called wxUniv port which implements all the GUI controls in wxWindows itself (similar to the approach taken by Qt) and which can be used to port wxWindows to many other platforms, such as Linux framebuffer (using GDK - but *not* GTK+), DOS (using the SciTech Software MGL toolkit - this one is actually working!) or wxMicroWindows port.

Finally, wxWindows wouldn't be complete without a rich set of classes covering the non-GUI aspects: it has classes which encapsulate the low level OS objects such as files, threads, sockets, IPC and so on. There are also are many other useful classes such as wxODBC, wxImage (supporting all of the common image formats), wxDateTime and so on.

Vaclav: wxWindows is a complete solution for writing cross-platform applications. It is mainly about the GUI, but not limited to it, virtually all x-platform issues are covered. Among the supported platforms are all flavors of Unix you could imagine (in both GTK+ and Motif version), Mac (both X and classic), Windows and OS/2 and MS-DOS are in alpha. wxWindows supports virtually all C++ compilers, is free and under a very liberal license and gives your apps native look & feel on all platforms.

Codingstyle: Could you tell us a bit about your background, your involvement with wxWindows, and what wxWindows components you have worked on so far?

Julian: I have computer science degrees from the Universities of St Andrews and Dundee. After I joined the Edinburgh University's Artificial Intelligence Applications Institute in 1991, I wanted to ensure that the diagramming/KBS tool I was writing would run on both Windows and Unix systems -- and since funds wouldn't stretch to a commercial toolkit such as the now-defunct CommonView, I wrote my own. It ran under Windows 3.1 and XView initially (hence the W and X), using MFC for the Windows port, but I soon rewrote the Windows port in pure WIN32 and followed it up with a first stab at a Motif port.

wxWindows was first released in late 1992 and I was gratified to find that it attracted a fair number of users, and increasingly, some very talented developers. Their contributions and suggestions helped transform wxWindows from a promise into a full-blown toolkit that really could compete with the likes of MFC, XVT and, later, Qt.

I've worked on design, documentation, and implementation of many classes across Windows and Unix platforms but with a bias towards Windows. Amongst the components I had initial responsibility for (beyond the whole basic framework in the first few releases) are the document/view system, the print/preview mechanism, the now-defunct WXR resource system, the Windows tree and list controls, validation classes, splitter window, image dragging classes, the limited OLE automation support, and the Tex2RTF documentation system that's still used to churn out the manual (now 1700 pages long) in various formats. I'm the principal maintainer of the web site.

Robert: I started ``work'' with computers when my older brother got a Commodore C64 which had a Basic interpreter or something similar. During the last year of my school, I have written a GUI toolkit on top of the Borland graphics engine written in Pascal. Later on, I was looking for an alternative for modern GUIs, i.e. Windows and possibly Linux. I found wxWindows after a short while and joined the project as a user and later on began work on some classes on the (now defunct) wxXt port - at that point of time Linux was still in search of a GUI. Around that time, it was decided to rewrite large portions of wxWindows (wxWindows 2.0) athough it was still unclear what the major toolkit for Linux would be. Luckily, the GTK toolkit became popular around that time, so I decided after some hesitation to port wxWindows to the GTK toolkit.

Vaclav: I'm still a CG student at Faculty of Maths & Physics, Charles University in Prague (for 4 years now). I'm using Linux as my primary OS and since I need to develop Windows apps (be it for my classes or for my living), wxWindows is naturally a project of great interest for me.

When I got involved with it? That's a tough question :) I don't remember, it must have been 2 or 3 years ago. It was somewhere around the 2.0 release when I found wxWindows. It was exactly what I was looking for back then: cross-platform, free and natively-looking. I downloaded wxGTK and since I needed to learn how to program with wxWindows and I needed a simple help browser, I wrote the first version of wxHTML. It somehow happened that wxHTML was merged into wxWindows and I kept maintaining it. Later I fixed some bugs here and there, and added a minor feature or two. These days I'm working on two relatively large components. One of them is a new, XML-based resources system called XRC that supports sizers and i18n - all these things that you'd expect from resources but that are missing in the old WXR system or Windows .rc files. The other is a completely new port of wxWindows, wxMGL. It takes advantage of the wxUniversal widgets set and will bring wxWindows to all platforms supported by the SciTech MGL library, including MS-DOS and embedded systems. This port is sponsored by SciTech, they use wxWindows in their development and are very supportive.

Vadim: I first learned about wxWindows in 1996 when I was looking for a toolkit which would allow me to write a small Win32/Linux program I needed at the time. The choice was quickly limited to Qt, V and wxWindows. Qt wasn't available under GPL back then and I hadn't any intention to pay (a lot of) money to develop a free program - besides the usage of moc was a real shock. V was too limited. wxWindows wasn't perfect neither but it had good documentation (the only one of free toolkits which did!) and this was the deciding factor.

Of course, I quickly encountered some problems while working on wxWindows and realized that it could be improved with some work. :-) With encouragement from Julian, I started working on wxWindows 2.0 which was being developed just then (and which was a total departure of wxWindows 1.x series) and I still continue to do so.

Since that time, I've worked on most parts of the non-GUI wxWindows classes, large parts of wxMSW port which I now co-maintain with Julian, and also break some things in wxGTK from time to time. ;-)

George: Remstar International (the software group of Remstar is now our own company called FastPic Systems) was looking to totally re-write our MS-DOS based inventory management software. Our initial requirements based on customer and marketing feedback pointed out three major problems with our DOS-based product. 1) Required DOS, 2) Required old Btrieve database technology, and 3) One of our largest customers highly desired a version of the software to run under Unix.

In 1995, we began looking at compilers and toolkits that could solve problems #1 and #3. We looked at Zinc and QT. We were on a limited budget, still not having the full go ahead to start development. Then one of our four programmers found wxWindows (version 1.6x was the current branch at that time). wxWindows met the requirements for #1 and #3, and did not require the US$8000 per seat per platform cost that we would have needed for QT.

My involvement with wxWindows other than as a user came about from our #2 requirement. Our design decision to remove our product's dependence on Btrieve for our database needs, and wxWindows ability to run on various non-DOS platforms, resulted in the choice of us using an ODBC interface in our new inventory management package. wxWindows at the time had wxDatabase, which provided a wrapper around some of the more generic SQL functions of ODBC, but would not meet the needs we had for our application. Internally at Remstar, one of our programmers that was assigned to the database interface wrote the original core version of what is now the wxDb/wxDbTable classes. Our programming staff felt that since wxWindows contributors had given us so much for free through their work on wxWindows, we wanted to give something back also.

Though I did not write the core of the ODBC code myself, I became the ``caretaker'' of them for wxWindows. Julian handled the initial port of the classes and sample program from 1.6x to 2.0.x. Then I started the overhaul of the classes, first modifying them to meet the coding styles set for wxWindows sources, and then working on the cross-platform aspect of the classes. Bart Jourquin helped immensely with getting the Unix kinks worked out. Then started the new feature additions, new database support, and the full documentation, overview, and ``how-to''. Documentation is much harder to write than source code! :-)

Codingstyle: How much of your time are you able to spend working on wxWindows?

George: Not nearly enough. Working on actual code goes in spurts. I take a couple days or a week off from work, and that is when I get the most coding done. Otherwise its very scattered with some weeks no time, and some weeks 8-10 hours. Most of my contributions during the week are made answering questions on the mailing lists.

Julian: Just a few hours a week at present, largely on the train commuting between Stamford (home) and Cambridge (Red Hat, UK).

Vadim: Way too much. My family isn't happy about it! :-/

Robert: Lots of time.

Vaclav: Since I was hired by SciTech to write wxMGL, wxWindows took almost all my programming time lately.

Codingstyle: wxWindows appears to be a rather large project with lots of subprojects. Is there anybody who is considered to be the main project leader? What do you do in cases of disagreements on the direction something is going?

Vadim: Julian is the wxFather so he is the closest one to the main project leader we have. But the project is not very centralised, rather there is a (small) group of core developers which are all more or less free to do what they think is best. Of course, when they err their mistakes are gently pointed at by their peers. ;-)

In cases of disagreements, we argue. A lot. This takes a lot of time but the truth is only born in the discussions (Robert can surely give the original Latin citation).

Robert: I don't know how you got to know that I know Latin, but: ``Discutando solo nascitur veritas.'' should be right.

Julian: As Vadim says, we argue :-) We don't have a clear project leader who can lay down the law but we do normally find a way to resolve issues. Sometimes that will be simply a majority verdict. When a decision is resolved other than by a majority or unanimous agreement, it's because one or (usually) more of the team put up a very emphatic argument for not diverging from current practice, and therefore the cost of implementing the change becomes too great. Although egos undoubtedly get ruffled -- and open source is often about the nurturing of egos -- we always find a way through, because ultimately we're reasonable people :-)

George: There is no ``project leader'' per se. In general, Robert handles the wxGTK project management, Vadim the wxMSW project management, and Julian manages everything else as a whole. Vaclav, Guillermo, myself and other contributors concentrate just mostly on the pieces we've contributed, and then answer as many of the generic questions as we can.

When disagreements happen, sometimes the mailing list does heat up, but in the end, everyone's ideas get out on the table, and usually a functioning compromise is found that please everyone.

Robert: There is no assigned project leader who decides what to do. New things get added in very different ways nowadays. Sometimes, someone just takes the initiative and adds a class or a new build system waiting for others to complain or agree, sometimes a long discussion took place before. Sometimes we just get patches from the outside, submitted to our patch database hosted at SourceForge. Disagreements? We never disagree on anything.

Codingstyle: Writing cross-platform code is no simple matter; writing a cross-platform framework must be a nightmare! How do you manage portability while maintaining code readability? Is the wxWindows framework code a mess of platform-specific conditional compiles? Are there language features or other things you have had to avoid to keep things portable? (For example, thread support and exceptions seem to be widely different in implementation across platforms.)

Vadim: Yes, I agree. Writing a library is more difficult than writing a program, and writing a framework is more difficult than writing a library. wxWindows is not a very constraining framework but still, it's not easy to design an API flexible enough to not lock the users into our ideas of how they should program, but high-level enough to be able to implement it for all platforms.

With rare (and unfortunate) exceptions, the code for different platforms lives in different files, i.e. we have {msw|gtk|motif|mac}/window.cpp. So there are not [that] many #ifdef's in the code and the readability doesn't suffer.

In general, if there is some non-portable code we always try to extract it into a class or a function which can be just used when needed, instead of putting the code directly there, inside ugly #ifdef's.

With regard to avoiding language/compiler features, unfortunately yes. We are basically forced to use C++ as it was 10 years ago because this is the only language correctly (and efficiently) implemented by all the compilers we target. We hope that we'll be able to abandon the draconian rules preventing us from using the modern C++ features in the code in the future - but when only the compiler vendors know.

Julian: wxWindows components (and, often, applications that use them) tend to be conservative in their use of C++ features. The restrictions on C++ usage <u>within</u> wxWindows hasn't been a show-stopper so far, and programmers are free to use more adventurous C++ features in their applications if they wish.

As per Vadim's response, we try to keep #ifdefs down to a minimum by separating out platform-specific code into separate files, but admittedly there are a few areas of wxWindows code that could be easier to read. Applications, on the other hand, are isolated from much of the platform-specific mess that wxWindows is there to hide.

Vaclav: Avoiding conditional compiles is actually the easier part. Of course we have them here and there, but majority of the code is well-separated. We put the code that is common to all platforms into one directory and files related to a particular platform into their respective directories (msw, gtk, motif, ...). The makefiles take care of choosing the right files. The same thing is done at classes level: there is a private wxFooBase class with commond code and public wxFoo class with several independent implementations for supported platforms.

Supporting as wide spectrum of compilers as we do is much harder. And we support almost all compilers that are in the wild! Especially the old Unix or 16bit Windows ones are sources of endless troubles. We can't use nested classes, exceptions or templates, because these compilers don't support them and we don't want to force people into using gcc or whatever. Fortunately I didn't have to discover these things myself (not all of them, anyway) - at the time I joined wxWindows the team have already written a cookbook for the ``simplified C++'' we use. An interesting document for everybody who writes portable software.

George: In the case of the ODBC classes, its not just the cross-platform, but cross-database issues that come in to play. For the most part, a database which runs on multiple OS platforms will behave the same regardless of which platform it is running on. But when the databases from different vendors, using ODBC is not as straight forward as it should be. SQL syntax varies slightly from vendor to vendor. The ODBC classes have code in them that check which database the current instance of the class is connected to, and handles program flow based on the data source when necessary.

For a trivial example of the differences, Oracle and Interbase both require user names to be in all capitals. The wxODBC classes hide this from the programmer, so the programmer just passes the user name, and it is converted under the hood if necessary.

Also, not all data types are supported in all data sources. So when the wxODBC classes connect to the data source for the first time in applications startup code, the classes query the data source to find the ``best'' supported data type to represent one of the basic data types utilized by the classes.

Codingstyle: What do you do if you want to provide things in wxWindows which those features would easily address? Do you develop your own solutions to them, or do you use the features and separate them into platform dependent code?

Vaclav: Platform dependent code is usually not an option, since the problematic language features are specific to certain compilers, not platforms. We'd have to use Borland-specific code and HP-UX's cc code and so on. Most issues of this kind fall into two categories: one that we can easily deal with by simple modifications of the code, with no loss of functionality (e.g. Borland C++ doesn't like temporary objects created during expression evaluation, so we have to use temporary variables here and there) and the problematic one. C++ templates are a perfect example of the latter: they are ideal for containers implementation, but we can't use them (for two reasons: first, some older compilers can't handle them and second, even modern C++ compilers still compile templates slowly, produce bloated code for them and give cryptic error messages). The only thing we can do is to find another solution that doesn't depend on the particular feature, which is usually possible (in this case, wxWindows uses preprocessor macros instead of templates).

Vadim: So far we work around the missing language features. It doesn't make sense to use these features somewhere but not everywhere - for example, instead of using the templates for our own container classes it would be much better to use the STL containers. The main advantage of our container classes is exactly that they're implemented using macros and not templates and so any compiler, no matter how dumb, can compile them (and quickly!).

But, again, one day in the bright yet hopefully not very far future, we should switch to the STL.

Codingstyle: There are currently no published books on wxWindows. A book would likely help bring many more developers to wxWindows. What is the status of the wxBook project, and do you think anything concrete would be available soon? Do you know of any other book projects in the works?

George: wxBook would be great. The issue with producing such a work is the amount of work it will take. The people best suited to writing the book are already working their own full time jobs (or going to school full time), coding more wxCode, trying to find time to spend with their families, and occasionally grabbing a few hours of sleep. Without any more incentive than to become more famous in the WX community for writing the book, it is unlikely that without a sponsor that wxBook will ever be fully complete.

That said, the reference manual has gotten much better over the last couple years. Nearly everything is documented now (very few replies to questions on the mailing list require an answer of ``Sorry, you'll have to look in the source headers''). The WX reference manual is much better than most professional/commericial product reference materials in my opinion.

Julian: The lack of a wxBook has always been a source of pain to me and many others. wxWindows' detractors have been able to point to a Tcl/Tk book, for example, and ask where the corresponding wxWindows book is. Many attempts have been made to breathe life into the wxBook project, but a programmer's main focus is inevitably on the code, and so we're still wxBook-less. wxWindows has thrived nevertheless, and the good news is that on the wxWindows web site you can find several links to very informative tutorials written by users. And of course, the reference manual plus 70 or so samples allows most people to get started pretty quickly.

Robert: We have not found a publisher and without one, no one will risk the tremendous amount of time to write a book. There have been several tutorials written for wxWindows and these should probably be combined into a larger project, but this is still a TODO. We do have a huge online reference including in-depth topic overviews and lots of sample code.

Vadim: The problem with a book is that it's a lot of work and I, personally, am only prepared to participate in wxBook project if it's really going to end in a paper book published by an editor. Unfortunately, in spite of the tentative contacts we have had with the different OpenSource-friendly publishers we couldn't arise enough interest in them. So I'm a bit pessimistic about wxBook in the near future. I think an expanded tutorial is surely needed and possible to write though. I hope we'll have it for 2.4.0.

I also believe Robin had some wxPython book plans.

Vaclav: wxBook is pretty much dead now, everybody's busy coding :(

Codingstyle: How mature/featureful is wxWindows compared to other cross-platform development frameworks such as V, Coral, Fox, TWIN, etc? Why would a developer want to choose wxWindows over the others?

Julian: Without going into a detailed analysis -- for which to be honest I probably wouldn't have all the background anyway -- the simple answer is that wxWindows is at least as complete as the competitors, and in most cases, much more complete. Developers tend to choose wxWindows for the native look and feel, the maturity of wxWindows (10 in 2002), the door-stopping solidity of the reference manual, and the sheer number of useful classes that allow a programmer to produce good-looking results quickly. The polite and helpful user community, and openness to suggestions and bug fixes, are very compelling advantages when comparing wxWindows with tools that are still dominated by a single developer or company.

Plus we have wxWindows bindings to Perl, Python and even a dialect of Basic, so you can enjoy wxWindows without using C++.

There are also philosophical (some might say religious) reasons including the fact that we're <u>not</u> Microsoft or some other faceless corporation.

Robert: There are several smaller cross-platform toolkits that cover only the basics, but seem to work quite well. As far as cross-platform application frameworks of the size of wxWindows is concerned, I only know of Qt as a serious competitor which will cost you money on platforms other than Unix or on any platform if you want to write commercial programs.

Vaclav: For its completness and native look & feel. wxWindows uses native GUI libraries of the target platform, it doesn't emulate their look (or, what would be even worse, doesn't come with its own alien look). There was a nice demonstration of this advantage very recently: Microsoft released Windows XP and voila, it came with a look completely different from previous versions of Windows. wxWindows applications can have native XP look instantly, all it takes is to install a small XML file called ``manifest'', which is the very same thing that all Windows 9x/NT/2000 apps have to do. Compare it with Qt, our most serious competitor: they render all the controls themselves, carefully emulating Windows look (or one of others) pixel by pixel. It means that you can have perfect Windows look on your Linux desktop (if you are perverse enough to want it), but it also means that your Qt app won't look right on Windows XP until they release a new version of Qt with XP theme and you relink your app against it.

Another consideration is that wxWindows isn't only a GUI toolkit, it is a complete cross-platform solution. It handles threads, i18n, configuration files, sockets, printing, files manipulation, all these platforms differences you have to face when developing a cross-platform product. I think there's only one library comparable in features to wxWindows. You guessed it, Qt. But Qt is not free on the most widespread platform, Windows. wxWindows is free everywhere, tt's even more free than GNU LGPL. You can do whatever you want with your app's binaries, unlike in the case of GNU LGPL - and that makes a big difference for commercial developers.

Vadim: Here is a quote of my recent post to comp.soft-sys.wxwindows:

1. has native look and feel (don't know of any others which do)
   
2. actively developed and supported (as few of the others are)
   
3. has good documentation (even fewer free libraries have good docs)
   
4. free for any use (unlike Qt)
   
5. supports many platforms, i.e. Win16/Win32/Unix/MacOS X (beta)/OS2 (alpha)/DOS (beta/alpha?)
   
6. has Python, Perl, Basic and Lua bindings
   
7. is a real framework, i.e. provides tons of other useful stuff and not only pure GUI classes (Qt does also, others in general don't)
   
8. has many advanced controls (tree, list, grid, html, ...) and not just buttons and checkboxes

Codingstyle: With regards to maturity, which platforms are the most mature at this time? Which are the least? When is it expected to have most/all platforms brought in line with each other?

Julian: The ports to Windows and GTK+ are the most mature, and those for Motif and OS/2 are the least mature. It's not possible to give precise dates for port completion, because (a) the ports often leap-frog each other in terms of API advances, and (b) progress depends on available time. But the progress of the Mac and Universal ports is quite rapid.

Robert: Since a long time ago, wxMSW and wxGTK the most stable ones. The Mac port has caught up tremendously in the last year with several key developers actively contributing to it. We are very confident that both wxOS/2 and wxUniversal will be ready to run in the course of or even the beginning of next year.

Vaclav: wxMSW and wxGTK are equally mature, wxUniversal is nearly feature complete as far as I can tell. There was a lot of work on wxMac (both MacOS X and ``classic'' Mac) lately, I think it no longer lacks behind wxMSW & wxGTK. OS/2 port is still in alpha stage, but making progress. There's one port that stagnates, sadly: wxMotif. None of the core developers uses Motif, so we keep the code compilable but nobody actively maintains it. We could definitely use a Motif developer or two!

Vadim: I am almost sure that wxMac 2.4.0 will be at the level of wxMSW and wxGTK (I don't risk anything by saying this, I don't work on it :-). I hope that 2.4.0 will also include a useful wxUniv port or two, such as wxGDK, wxDOS (+MGL) or wxQNX.

Codingstyle: What language bindings are available for wxWindows at this time? Are the APIs portable across languages? Any other bindings planned for the future?

Vadim: Python, Perl, Basic and Lua. Semantically, the APIs are portable, as they all mirror C++ API quite closely AFAIK. But the Python and Perl syntax are a bit different ;-)

Ada and Pascal bindings have been mentioned in the past but I haven't heard of any progress on them.

Julian: See Vadim's response. CLIPS used to be supported by a subset of the wxWindows 1.x API and the wrappers for wxBasic could be adapted quite easily to wxWindows 2.

Vaclav: There's the C++ one, to begin with. ;) Python binding, wxPython, is extremely popular in the Python community and I can definitely recommend it as an ideal tool for rapid GUI prototyping. And there's Perl binding, however being Perl illiterate, I haven't tried that one. The API of wxPython is almost identical to that of C++ version of wxWindows. That ``almost'' word accounts for language constructs that are impossible in Python and a thing or two that are already part of standard Python and thus not needed (e.g. string arrays).

Codingstyle: Could you describe wxUniversal?

Vadim: All the other wxWindows ports use the native GUI API of their platform. wxUniversal departs from this and draws all the controls/widgets itself, using low-level wxWindows classes (which, in turn, use the native API, of course, but only for drawing lines, pixels, bitmaps, not the entire GUI objects). This has some advantages such as additional flexibility and theme support as well as the possibility to have exactly the same look and feel on all platforms. However, we still believe that native ports are better suited to the platforms which have the native GUI API to use and wxUniversal is not meant in any way to replace the existing ports.

But it is perfectly suited for the platforms without native API (DOS, framebuffer, ``raw'' X11...) and it also makes writing new wxWindows ports much simpler as you can start by implementing a few low level classes and in a few months you get a fully functional port - for comparison, creating a new native port takes a few man-years.

Julian: Vadim's already described it -- I'm excited about the possibility it brings for embedded platforms. I've started a port of wxUniversal/wxMSW to MicroWindows, the open source WIN32/NanoX API. Use in 'tiny computers' could be the next big area for wxWindows to make an impact on.

Vaclav: I'll also mention that wxMGL is built on top of wxUniversal, it's the core component of the (now alpha) MS-DOS port.

Codingstyle: Is wxWindows an appropriate framework for the development of Multi-lingual applications? Any big show stoppers?

Robert: wxGTK does not yet support Unicode, but for European languages, wxWindows offers everything you need.

Vaclav: Developing multilingual applications is child's play with wxWindows! We use the same system as GNU gettext, but in our own independent implementation. This is a big advantage when compared to native Windows applications or other toolkits that roll their own i18n system (no names :), because you can use existing tools to edit translations (like (a shameless plug follows) my poEdit [10] utility). wxWindows supports locales, font encodings and charset conversions and if you want to be truly multi-lingual, you can build wxWindows in Unicode mode. This is currently only supported on Windows but there will be Unicode support in wxGTK as well, when the GTK+ team finally releases version 2.0 of their library.

Vadim: It is appropriate for the European languages, less so for Far Eastern ones. The big obvious problem is the lack of bi-di support. It could change in the future, especially with the advent of GTK+ 2.0 but we badly need outside help for this.

Codingstyle: What RAD tools are available for wxWindows, and how do they compare with regard to price, feature set, maturity, etc. What are the pros and cons of each choice?

Vadim: There are at least three tools currently available.

Dialog Editor: the old dialog design tool for the old (non XML based) resource format. This one is free, but obsolete and, IMHO, useless.

wxDesigner: a very powerful program but a commercial one. People who bought it seem to think that it was well worth the money (it is not very expensive).

wxWorkshop: a very, very promising project which aims to be the best of both worlds: as (or more) powerful as wxDesigner but free. It is still in development though - George can probably give more precisions about this one.

Julian: wxDesigner has some RAD features, and wxWorkshop will have some -- I'm looking forward to finding out what they'll be :-) There are also a couple of VC++ project/skeleton application generators available.

Robert: I can only speak for the one I have written myself, wxDesigner. I sell this to keep my own interest in it alive and because it is funny to get email from NASA :-) wxDesigner is used in hundreds of projects and and I can count the number of unhappy users with one hand (German proverb, people here still use fingers for counting).

Vaclav: wxDesigner is by far the most advanced tool for sizers-based dialogs design. It's commercial, but it speeds the task significantly, especially if you develop in C++. And you can learn sizers in no time with wxDesigner! wxWorkshop is another, very RADish, project, but they haven't yet released anything, so it's hard to tell anything more. wxWorkshop will use the new XRC resources.

I personally don't like RAD tools and only use the dialog editor part of them. Right now, I design dialogs either with my wxrcedit tool or with XRCed that is part of wxPython. The former is very alpha quality and I think it's going to be deprecated in favor of XRCed.

George: Dialog Editor comes with wxWindows. It is a port of the old 1.6x Dialog Editor. It allows users to layout fixed position widgets on a dialog, and load the created resource at runtime (or it can be compiled in as strings in the source). Very rudimentary but usable as long as resizeable dialogs are not required, in which case it is useless.

wxDesigner is by far the most stable and encompassing at this time. It is a commercial product written by Robert, and has been very well received from feedback on the mailing lists for WX.

wxWorkshop (hosted on SourceForge at http://wxWorkshop.sourceforge.net/ [11]) is a full RAD tool for wxWindows. It has a built in source editor, dialog generator (with compilable source code generation), widget editor, workplace and multi-project settings, compiler integration, etc, etc. The project is currently still pre-alpha, but getting close to the first alpha now. wxWorkshop finds its original roots from the wxStudio project which is now defunct or on long term hold from what I understand. Bil Simser of the wxBuilder project has recently joined the wxWorkshop project to see whether we can combine efforts from his RAD tool with that of wxWorkshop. Being a contributor to wxWorkshop, I may be a bit biased, but I think that when finished, wxWorkshop will be awesome.

Codingstyle: When is wxWorkshop's first beta release expected to be released?

George: No idea, but likely still months. Alpha in 6 weeks (big guess) if those of us actively working on it have enough free time to reach where we feel Alpha state has been reached. Vaclav has now merged most (all) the XRC additions from wxWorkshop into standard wxWindows XRC, and that was a big stopping point to reaching Alpha.

Codingstyle: What is on the horizon for wxDesigner?

Robert: Improvements as my time permits.

Codingstyle: Any plans to make resource files readable across RAD tools? For example, I might prefer wxDesigner, but somebody else might prefer wxWorkshop. Unless we can share our resource files generated by these tools, collaboration becomes difficult.

Vaclav: They already are, at least partially. AFAIK wxWorkshop uses XRC as its native format and wxDesigner can export and import XRC.

Robert: I never tried wxWorkshop, but wxDesigner stores a lot more than just the XML data in its own files. Neither project wants to limit itself what the other does.

Codingstyle: It seems sizers are the generally accepted way of doing things in the wxWindows with regard to GUI design. Sizers appear to hit newcomers, as there is often no direct counterpart in other popular APIs (eg. MFC), as they do not seem to be very intuitive. How can a new developer best get his/her mind around the concept? Are any alternatives to sizers taking shape for the future?

Julian: In principle, the concept of sizers is the best bet for portability -- differently sized controls on different platforms defeat an absolute-position based system -- but they really do need a tool such as wxDesigner to make them easy to use. Hopefully more tools (such as wxWorkshop) will become available soon to take some of the hard work out of using sizers. Meanwhile, wxDesigner is an efficient and easy-to-use solution -- it's allowed me to knock up loads of complex, resizeable and portable dialogs at Red Hat, and anyone serious about wxWindows development should consider it.

Vaclav:Some people who came from the Windows world and worked with MFC have some trouble with the concept, but those without prior knowledge of GUI programming or those who used GTK+ accept the sizers immediately. Once you get used to the idea, you'll find it the most natural way of designing cross-platfrom dialogs!

There is one alternative to sizers that I know about: wxMatrix class from wxWorkshop project. It takes a ``traditional'' dialog on input and modifies it a bit, adding a wider space here and moving some controls by a few pixel there, so that it looks more natural on the platform you run it on. It gives surprisingly good results, but sizers are still more powerful than that.

Vadim: Experience shows that sizers are the best (and almost the only) way to create the dialogs which look attractively under all platforms. Although MFC does not have sizers, [Gtk does], as does Java (it calls them layout managers though).

Sizers are just boxes. Think about them as such, i.e. try to represent your dialog as a set of [embedded] boxes. Then decide how should these boxes resize when the dialog size changes. And then just mechanically translate the boxes into C++ or, better, XML. Or use a GUI designer.

As far as alternatives go, personally I'm quite happy with sizers. It is a big step forward compared to the layout constraints we had to use before. The syntax of the sizer creation could definitely be improved though. But using XML resources you can bypass this problem.

George: Sizers are definitely the ``preferred'' choice with wxWindows. One alternative is the Frame Layout contribution from Aleksandras Gluchovas. Several developers are using this class, and the wxWorkshop RAD tool (still pre-alpha) is written using the FL library.

Codingstyle: Using wxBase it is possible to build non-GUI wxWindows apps, which is useful for building things like application servers where a GUI would be inappropriate. Do the wxWindows libraries need to be compiled separately for non-GUI and GUI based applications?

Vadim: Yes (although they're compiled from the same sources).

Codingstyle: Are there any plans to address this in the future to allow one library to be used for building both?

Vadim: It's one of the ``would be nice to have'' things for me but not really critical. So if someone comes up with a good way to implement this, I'd be glad to do it but otherwise it risks staying in the current state for now.

Codingstyle: Are there any fundamental differences between how one would code a GUI-based application as opposed to a non-GUI based one?

Vadim: Yes. There is no event loop in the console (wxBase) applications. We might add the possibility to have one to wxBase though, this would be nice to be able to do asynchronous I/O.

Codingstyle: How can a prospective applications developer get up to speed with wxWindows?

Julian: Try the various tutorials available, get to know your way around the reference manual, and take a look at the samples. Don't be shy about looking in the headers where necessary, and the source code isn't too scary either. The important thing is to get stuck in and start hacking a sample or two. Remember that the mailing lists are always available if you get stuck.

George: Samples, samples, samples. The sample apps with wxWindows are the best way to start. Compile the samples, see how they work, then start playing around with the samples. When a new developer starts, copy one of the sample's makefiles (and even source if it is applicable) and dive in. Then reference the manual whenever you think ``Gee, there should be a way to do...'', and generally you will find it is already there. And then fall back to the mailing list when all else fails. Response time on the mailing list is sometimes so fast you receive the response at the same time your initial post arrives in your mailbox. Now that's service!

Vadim: Read the docs, read the headers, read the code. Asking the questions on wx-dev won't hurt at either stage.

Vaclav: The way I did it was that I simply started programming with it. Of course, I didn't know anything about the API, so I had to look at the samples (there are 73 of them!) and read parts of the manual (more than 1000 pages of overviews and classes descriptions). The overviews are very helpful and relatively small, you can dig through them in only little time. Oh, I'd almost forgot: you definitely want to subscribe to the wx-users mailing list, it is an invaluable source of information.

Codingstyle: Are you looking for more contributors to the wxWindows project? What kinds of things are most urgently required right now?

Vadim: Definitely! wxWindows is, and has always been, a community project. We depend on the library users for testing, feedback and contributions. There are some areas where it seems the product of skills and available time of the existing developpers is not enough. These are, for example:

• Writing documentation (including tutorials, overviews, books, etc.)
  
• Far eastern (and other ``exotic'') languages support - many people ask for this, but we can't do it without help
  
• Porting to the new platforms - this has never been easier than now, thanks to wxUniversal. I'd love to see wxX, wxQNX, wxGDK ports available (I also hoped to write wxBeOS myself but, sadly, this is not really possible any more). Maintaining wxMotif port is another alternative: it hurts me to see that it crumbles from lack of use but there is nothing I can do about it.
  
• Writing free programs using wxWindows! We really need a wxKillerApp to show the outside world what wxWindows is really capable of. Just don't start writing another word processor/email client, please, there are already enough of them :-)

People can contribute in many different ways. Code contributions (patches) implementing new features or fixing bugs are, of course, the most welcome. But documentation contributions (again, this includes tutorials) would be equally very important. Testing wxWindows is a huge task so do subscribe to wx-testers list and help us ensure that wxWindows works for your platform (architecture/compiler) combination. Ah, and answering the user questions on wx-users mailing list is a valuable help as well as it frees the time of the ``more core'' developers for working on the code (or the docs :-) ).

The most important wxWindows tasks now are, IMHO, the completion of wxMac port and porting wxGTK to GTK+ 2.0. The next priority is finalizing wxUniv and porting it to the other platforms.

Ah, and my personal favourite: I'd really love to have a rich text editor widget in wxWindows. Unfortunately, although many people have tried implementing it few (== none) have succeeded.

Finally, there is yet another way to help wxWindows development: it is donating resources/hiring wxWindows developers to work on it. For example, I'm really grateful for SciTech Software which allowed me to write (big part of) wxUniversal!

Julian: Yes, contributors are always welcomed! There's always plenty to do. In addition to Vadim's points, I'd encourage effort to be put into wxWorkshop, since this tool could really accelerate acceptance of wxWindows. Personally, I'd also like a bit of help on the MicroWindows port, and also on publicity, since this is something we've not been brilliant on in the past.

Robert: People should contribute with something they like to do. If you enjoy your work you will do it well.

George: Contributions and enhancements are always welcome. Whether these contributions make it in the core of wxWindows, or are added as a contribution, or become part of the gizmos hierarchy, many users are happy to find that some cool feature they thought they were going to need to write from scratch is already available in wxWindows.

From the general discussions on the lists right now, the area we need to most knowledgeable help on is the multi-lingual integration. My head spins just reading all the feedback on the different UTF/DBCS/MBCS discussions. Making everyone happy with the implementation of all the possible encodings would be monumental. Much progress has been made, but it will be nice when the day comes when someone asks on the list if they can write an application that can run using language A and language B natively, and see the answer be just a simple ``Yes, just use setting wxUSE_MBCS'' or something similar.

Vaclav: Of course! We're always looking for contributions. In fact lots of new features mentioned in the changelog are due to contributed patches. There are lots of ways people can help us, from bug reports to patches, documentation or even answering at our mailing list. For example, the single most requested thing is a wxWindows tutorial, so anybody who could write one would be most welcome!

Codingstyle: Any closing thoughts/comments?

George: Although none of us have actually met in person, or gathered in one place, I find it amazing how the wxCommunity has grown, strengthened, and evolved over the last six years. wxWindows is an excellent example of an Open Source software success. All of the volunteers and contributors have created a great toolkit. Long live wxWindows!

Vadim: I hope wxWindows (which will celebrate its 10th birthday soon) will finally come out of the shadow of Qt as it really merits it. I think that the cross-platform development has many bright days before it as both Windows and Unix (including Linux) and, now, Mac, are here to stay and it looks increasinly short sighted to consciously limit the potential program market to only one of these platform. And so I think wxWindows has bright perspectives as well. What is really needed to fulfill its potential is a really successful program written in wxWindows - although there are many existing ones, they're mostly for the niche markets. A generic purpose and really useful program in wxWindows would undoubtedly attract more people to it which in turn will make it possible to gain enough momentum to publish a book about it which will undoubtedly make it even more popular.

I hope, not only for wxWindows, but for the programmers interested in cross-platform development, that this initial impulse is coming soon as it's a shame that wxWindows is so underused (well, 1000 visitors each day at www.wxwindows.org is quite a lot, but it could be more!)

Julian: I'd like to pontificate briefly about why wxWindows has succeeded for so long, because this may hold some clues for its future success. One key point is that the abstract wxWindows API itself is the 'soul' and core asset of the project, which survives even when individual ports have become obsolete (as have wxXView and wxXt, for example).

By its nature the project (and applications using it) can migrate to different platforms as they become popular. There's also a paradox in that wxWindows survives both because of the differences between platforms, and because of their basic underlying similarity (all GUIs have a large common subset of features). The diversity of GUI systems seems to be accelerating rather than slowing. In the early 1990s, it seemed that Unix was on its last legs and the Mac wasn't long for this world either. But Unix (in the guise of Linux) revived, as did the Mac, and the assumption that WIN32 would become universal was reversed. The area of embedded systems is now driving further diversity, and wxWindows should shine here when wxUniversal-based ports mature. The longevity of C++ itself has been good for wxWindows, and will continue to be important, but having bindings to a variety of different languages we can tap into resources from several projects, such as the dynamic Python community.

wxWindows' user base has grown steadily over the years despite very little marketing effort. We know that wxWindows has helped a lot of companies and organisations (as the feedback on the website shows); now we need the message to be more generally known. Perhaps Vadim's proposed 'wxKillerApp', as well as the enormous potential for wxWindows to thrive in the embedded space, will tip the scales.

Finally, I'd like to say thank you to all the talented people who've been involved in wxWindows, and to welcome all future participants! And thanks to Codingstyle.com for giving us a chance to talk about our pet project.

Codingstyle: Thank you!

Useful wxWindows resources:

• http://wxWindows.org [12] - The wxWindows project main site
  
• http://www.roebling.de [13] - wxDesigner RAD tool
  
• http://wxworkshop.sourceforge.net [14] - wxWorkshop RAD tool
  
• http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin.htm [15] - latest wxWindows documentation

About the interviewer: The interview was conducted by Steve Frampton, the owner of codingstyle who runs it in his spare time. Steve is Canadian but is currently living in Japan, employed for a dot-com in Tokyo as a Unix software engineer, working primarily with C++ and PostgreSQL.