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.

This is a religious question

[aheitner]

but I'll attempt to justify myself anyhow. I'm choosing to skip the whole display driver architecture question and focus on application programming.

First of all, I don't believe XML/whateverML/Mozilla to be the answer. I don't want my application written in a scripting language. Running everything through your browser is a bad idea, and everyone except MicroSoft thinks so. Frankly, I haven't seen a browser that doesn't suck (except Lynx!) and I'm not convinced I ever will. I'm not that impressed (yet) by the Mozilla efforts, tho I support them.

I'm only going to consider compiled widget toolkits, no Java. I'm sorry. Java sucks. It involves way too much typing, and it's slow. I don't approve of anything that makes code slow. The whole point is to be fast.

What does that leave?

1. Motif I once sat thru a college lecture on Motif. In an hour, the lecturer had managed to cover use of the clipboard. No function name was less than 20 characters, and it took 15 calls to get the most basic thing done. No wonder Netscape under Motif was ~1million lines. 'Nuff said.

2. MFC MFC isn't really so bad as a design. It can be annoying, and it often lacks flexibility, but it's not completely unusable. However, I find that using MFC (specifically in VisualC++, which conveniently writes the hard/annoying parts for you) is a good way to kill a project. It forces you to use their class heirarchy and objects, and if the generated code gets screwed up you can be in real trouble. The usability is also heavily dependent on spotty MS documentation -- if the documentation is bad (eg. the MDI multimedia devices in VC5) figuring it out can be a chore. A mediocre choice at best. At least it has nice built in database drivers.

3. Visual Basic has got to be the quickest way of throwing together a UI I've ever seen. I really like it, especially for prototyping. I have no speed problems (since it's compiled now and officially in my OK book), but BASIC can be a dreadfully limiting language. Writing the interface in VB and all the hard code in a DLL isn't a half bad idea, tho. At the very least useful for trying out interface designs on people.
Some built in database drivers.

4. PowerSoft Power++, Borland CBuilder I've only ever used Power++. It's really just a wrapper around MFC classes, but it cleans a lot of stuff up and does all the hard stuff. It still pushes you to use MFC-type objects, but they're quite a bit less ugly to work with, and the docs are better. But if the rest of you're code's not in Watcom, Power++ might cause compiler issues (which is why I eventually dropped it). I've never use CBuilder, but it's more popular than Power++ so likely as good or better. Both of these are probably very good, fast ways of getting an application written. Mad build in DB drivers.

5. Gtk+ A very nicely written, madly flexible widget toolkit with the added benefit of almost no baggage. In other words, at no point do you subclass some dialog box to start writing code. It's C dammit, there's nothing to subclass! This has great advantages, even for a bigotted C++ coder like myself -- it means that my application's structure, instead of the widget toolkit's, determines the structure of the code. The result is a much more maintainably laid out project. I also find gtk+ quite fast to work with. You can pack the dialogs in code and know exactly how they will turn out, write your handlers and you're done. Unfortunately there is no built in DB support anywhere -- it's a pure widget set, and you're on your own. You could always use direct SQL, or pick up one of several DB libraries I've never used (any recommendations?). Also, the function names are kind of long...oh well. Another plus: Gtk+ has a bajillion language bindings.

I've never used Qt so I'm afraid I can't comment...

I'll choose Gtk+ as the preferred widgetset. Applications written with it (rather than around it like some others) end up far more maintainable IMHO, and that's the most important thing for app developers.