Ask Slashdot: What is the Best GUI Framework?

After asking you all to share your thougths on what really makes a GUI. I figure it might be interesting to see what you all thought about the implementation side of things. What kind of framework do you think a modern GUI should have? So when exa slid this piece my way, I just had to post it. Click below to read his question.

The following is from Slashdot Reader, exa.

I wonder which GUI frameworks are the cheesiest to code with and what makes a GUI framework good. Previously, I've been involved with GUI programming on GNU/Linux, Solaris, Amiga and Windoze 9x/NT platforms. It is then not so surprising that I ask /. about GUI programming ;)

In particular, I'm pursuing GUI programming for X11. To give interested hackers a boost, I present the following remarks on how a framework should look like (in no particular order):

• In general, a robust and scalable GUI framework, in C++ or a prominent OO language like Ada9x, is very desirable.
• XFree86 is all pretty good. But times can change, so a framework with platform independence has its pros. (And multi-language capabilities count as well)
• Many libs don't have a good design. A great GUI framework must attain design goals such as uniformity, modularity and comprehensibility.
• For a good design, it should make use of certain design methodologies. For instance it might adhere to a design pattern like MVC.
• The license does matter.
• The framework, where applicable, must support standard stuff. At least it should not disallow use of them. For instance, you'd want threads, you'd really want TCP/IP, you'd like reading in JPEG files.

I also wish to make some comments on a few of the popular GUI frameworks:

• Motif based stuff such as BXPro: I use free software, and on my system Motif progs just look antique. What's more, they are lightning-crash-and-slow-motion. I don't possess a Motif 2.1 product and I don't plan to. How perfect they might be, I am skeptical about them. (I did write with pure Motif, and I'm outta the game)
• QT: This lib forces you to write in a certain style. The keywords introduced by means of moc are not a proper C++ extension. CPP macros, thus signal/slot mechanism is ad hoc. A fatal error is in their failure to recognize standard C++ library. And the license is boring.
• Java swing: The successor to awt has several advantages over the previous. Although I basically dislike Java language, the GUI subsystem features a somewhat nice design.
• GTK+: A framework that has a well defined run-time system. The types give a formal way of handling a general OO design. Multiple language bindings. (C++ bindings are cool)
• JX: After seeing how Code Crusader performed, I abandoned work on it. But still, something that works.
• Other Stuff: freshmeat lists other "widget sets" too, like the FLTK and TOAD which are LGPL'ed. By the way, don't even think of MFC. It is the worst GUI lib that has ever seen the light of sun. It is *not* designed. (I worked with it over a year... :-

Note that I'm not concerned with the user interface, docs, distribtion, etc. of the applications written with a particular lib. Thus, I'm not suggesting a GNOME/KDE flame war. The only purpose is to assess the quality and performance of the software that underlies graphical applications. In this sense, I don't ask how a user interface should be designed. In addition to this, I don't ask what tools are available for the software (like GUI builder). The two chunks of comments above determine my primary questions:

1. What are the aspects of the ideal GUI framework?
2. Among the available software, which GUI frameworks for X11 are preferable and why do we pick them?

Ed: This is a heavy topic, so I'm hoping for some good discussion. If you feel the need to discuss GUI systems available on other platforms (X11 is rather limiting, other platforms may do it better!) feel free. I don't want to stray too far from the original question, but I would like to know what you all think the best GUI framework in existance is. I got quite a few submissions similar to this one so to those of you that them in, I hope this topic covers what you were asking. If it doesn't, you can always send those burning questions back to me by re-submitting them.

Comments

MFC vs QT

[Midnight Coder]

I think this article is baiting us, nevertheless here is my honest response.

Firstly let me say I have nothing against GTK, I have little experience with it, but I constantly hear good things about it, and I've used some very nice GTK based apps.

Personally I choose to use a C++ based library over a C library, (and I'm unimpressed with bindings in general). To give you some idea of where I coming from I have experience with QT and MFC, I use both on a daily basis at the moment, have about a years experience with MFC (spread over 3 years) and about 6 months experience with QT. (I also have about 3 months experience with each of Java AWT, raw WIN32 & WIN16 api programming, and the Harlequin Lisp GUI toolkit).

QT is vastly superior to MFC. By coincidence the free software QT based development I have been doing is similar to (just from a GUI point of view) to the MFC development I have been doing, and this has given me the opportunity to compare the two.

Here are some observations.

Layouts
QT has good support for layouts, MFC has none. This means it is much easier to create resizeable dialogs in QT than it is in MFC. This means i18n support is easier in QT than MFC (no need to tweak your dialog for each language you support).
I especially like the QT grid layout that supports mutli-cell entries.

Tooltips.
Tooltips in MFC are a bit screwed, the MFC CToolTipCtrl isn't useful as is and you have to derive a class from CToolTipCtrl in order to use tooltips. This derivation isn't application specific exactly the same code is need in each app. Why? Quoting programming windows 95 with MFC "Late in the beta cycle, the Windows 95 designers recognized this problem and added some intellignece to tooltip controls so that the designers could do their own subclassing. Unfortunately, this feature was added too late to be incorporated into CToolTipCtrl". MFC programming tends to be like this, every simple little things requires a dozen lines of work before you start doing anything application specific. (There is a very good open source web site www.codeguru.com that has a collection of such code). QT doesn't suffer nearly as severely from this problem, QToolTip::maybetip lets you decide when to show a tooltip, where to put it, and what to put in it, just hook one up to a widget.

Documentation.
The documentation that comes (free) with QT is excellent, better than the MFC documentation I have. The 12 stage QT tutorial is excellent compared to say the MFC Scribble tutorial, I get the feeling that QT really is a toolkit whereas MFC is a framework. The QT class documentation has decent see also links (very useful!), and inline example code. Basically it is just of a higher quality than the MFC documentation. The QT source code itself is very readable and is a great source of documentation. (The MFC source code is not so useful)

Signals/Slots
The QT toolkit pioneered this concept and it is a good one. Basically they can be used to reduce code coupling and make it easier to create independent components. For high level stuff you don't have to derive a class and override a virtual method with a one line implementation, just connect a signal to slot. People hassle QT for extending the C++ language and this is a valid criticism, however in actual practice this has no drawbacks (you can still debug your programs with gdb and run make to compile all your source). MFC has a signal/slot equivalent "message maps", syntactically they are much uglier.

QTL vs STL
I'm all for standards, I really am. Neither MFC nor QT support the STL as a first class citizen. Unforunately there are compelling reasons for this when using (e)gcs. The egcs STL implementation is bloated and slow compared to the QTL. Syntactically the QTL is much simpler (eg container classes expose begin() and end() methods as well as providing external iterator classes). Still if you already know the STL this is an extra thing to learn.

High quality widgets
QListView is an awesome control unifying the TreeCtrl and ListCtrl concepts. In general QT widgets are done right.

Basically using QT has helped me understand why people complain so bitterly about MFC, and proven to me that there is a better way.

GNUstep

[Chris Hanson]

You'd have to code in Objective-C, but that's not exactly a detriment. The designers of the Standard C++ Library could learn a thing or two from the OpenStep FoundationKit, and the designers of the Java AWT probably should've followed the Netscape IFC team's lead and just reimplemented the OpenStep ApplicationKit.

I strongly encourage you to take a look at the Mac OS X Server programming tutorials on Apple's developer web site (in particular the Discovering OPENSTEP tutorial), and then at the state of GNUstep. GNUstep is really picking up steam, and is an implementation of probably the most elegant object-oriented framework that ever made it into wide distribution.

From a technical standpoint, the OpenStep frameworks really leverage the dynamic nature of Objective-C. People have written interfaces for other languages (Perl, Tcl, Python, Apple even did Java) to the OpenStep frameworks but by and large the best way to write OpenStep programs is to just use Objective-C. Since it's a strict superset of ANSI C, that's not so bad; you can even interface it with C++ code (though mixing C++ and Objective-C in the same file isn't generally supported yet; Apple's gcc supports it, but the changes haven't been merged).

One of the best things about OpenStep is that your interfaces can be completely data-driven; you nevever have to write code saying "Put a window here, put a button in it, make the button send this message to this object..." You can code that way, but it's discouraged. NeXT's InterfaceBuilder generated "nib" files which could be read in with one line to create complete networks of interdependent objects that would just do the right thing. Work on an equivalent InterfaceModeller (which generates "gmodels" since Apple never specified the nib file format) for GNUstep progresses, and gmodels aren't too difficult to generate by hand.

I think the best way to succinctly describe OpenStep is to say it is to software developers what the Macintosh is to normal users.