A very common complaint against C++ is the lack of a standard GUI library. While I agree that it would be great to have one portable, modern GUI library, I don’t think it will ever happen. Traditionally, in the Windows market, GUI frameworks are a strong selling point for tool suppliers, so everybody has their own. Under Unix not only are GUI libraries mostly C oriented, but the one that emerged at one point as the vendor backed standard, namely Motif, has since been obscured by more attractive open source alternatives.
Among the cross platform C++ specific solutions available today QT and WxWidgets are probably the most popular ones, but they don’t appear to be suitable for inclusion in the standard. QT is produced by one of the field players and uses some non standard syntax, handled by a precompiler. The fact that Trolltech, QT’s developer, is including in it just about everything and the kitchen sink is not likely to help, even assuming that Trolltech is interested in QT’s inclusion in the standard, which isn’t something I would take for granted. WxWidgets, being an open source project, appears to be in a better shape from a political point of view, but while effective it can hardly be considered a modern design.
Another factor that must be taken into account is the advent of the web browser as an alternative interface paradigm. While I’m not convinced that this is an all-round superior alternative to GUI’s, it is often a valid contender and a more “fashionable” one. This is one of the reasons why I don’t see a business case for a new commercial C++ GUI framework and I don’t expect an open source one to emerge, especially in the light of the non trivial effort that a similar endeavour would entail.
Yet another option that is mentioned every now and again is the development and adoption of a simple, bare bones library. I don’t think such an approach would be of much use. In my opinion C++ is still chosen to develop GUI based applications because it guarantees responsiveness and control over appearance and behaviour of the interface. Ease of development is important, but not enough to be traded against speed and access to detail. This makes also adopting a thin wrapper over an existing , portable framework not viable. The other reason being that requesting vendors to supply an external library in order to comply with the standard would be awkward. The fact that C++ is defined by a standardization committee rather than by the developers of a reference implementation limits the extent to which an approach such as Python‘s “batteries included” may be applied.
In my opinion, however, there is an alternative approach that might have better chances of succeeding: rather than aiming for a full fledged GUI library it might be more effective to concentrate on the interface between the GUI and the application logic and forsake everything that relates to the visual aspect of the interface. The resulting library would include a framework for event handling and callbacks, which might be based on the Boost/TR1 Signals and Function libraries; paradigms for input /output towards visual components, from toggle buttons, to text fields, to combo boxes; and possibly a validation framework.
I’m aware that such an approach would leave out a good deal of GUI programming, but a sound design would encourage a clean separation of GUI and program logic, and probably lead to more testable code. A similar library could be implemented as a set of add-ons for existing GUI frameworks, without requiring the implementation of a completely new one.
What the hell, what do I know? 
October 22, 2007 at 11:59 am |
I completely agree. Moreover, a *standard* GUI should follow concepts and paradigms found elsewhere in the STL/Boost world and the best practices that are described in the various Effective C++, Exceptional C++ etc.
In particular, GUI’s are often ‘pointer based’. A standard C++ GUI should be (in my opinion) strongly exception safe (or at least exception safe). Moreover, GUI’s have often non trivial problems related to ownership and references. None of the libraries I’m aware of have this property nor have a non trivial and effective way to deal with ownership: that would mean to develop a new GUI from scratch.
Open Source community is notorious for creating a whole lot of similar programs that do almost the same thing. However, the major GUI libraries are just a few. I feel this is a symptom of how expensive it is to develop such a library.
An another example is Python. In the Python community, we use the ‘standard’ libraries as well. Qt, wx, gtk, Cocoa. Writing a Python GUI library would be much less expensive than writing a C++ one. However, since the existing alternatives work quite well, there is no interest in developing another one. I feel this argument is even stronger if applied to the C++ community.