GUI Toolkits for the X Window System

TeachingMachines writes "Leslie Polzer has written a nice summary of the current state of GUI Toolkits for the X Windows System (article title of the same name). Those of you who are planning to spend hours and hours scouring the Internet for a mature cross-platform GUI toolkit may save some time and trouble by reading this summary. Leslie's review covers the pros and cons of using GTK+, Trolltech QT, FLTK, wxWindows, and the FOX Toolkit."

Comments

One thing missed

[Doesn't_Comment_Code]

The one thing I don't like about toolkits (not mentioned in her list of cons) is that if you distribute the source code, whoever is compiling needs to have the toolkit.

I've tried to compile and install programs before and spent a lot of time trying to track down the toolkit libraries.

This is not a good reason to abondon using toolkits, but it is one negative aspect to take into consideration.

Re:One thing missed

[Telex4]

One way to avoid this problem of dependencies, and also to really boost the useability of your app, is to try hard to separate the GUI from the "guts" of the application, so it is reasonably easy to write multiple UIs (GUI or CLI) for the same application. Then you, or others, can come and develop new UIs for themselves. For example, when I started developing QuickRip, I began with a (Py)Qt interface. Someone requested a CLI interface, so I made the separation, and gave QuickRip two interfaces. Now some (Py)Gtk developers are adding a Gtk interface, because they don't want to use Qt. Lovely.

Of course this approach is only usually worth it when most of the hard work is done in the guts, and when the UI itself isn't that much work to redo in a different toolkit. Nor does it work when you need a feature than is only available in a specific toolkit. But in many instances, it works fine.

So often there's no need to choose between toolkits... just choose them all! :)

When wxWindows gets decent support for toolkits other than Gtk+, it will make this even more trivial.

X Programming In C

[dodell]

It still takes a really long time to find documentation on writing stuff for X in the first place. For instance, I was getting into creating a window manager at one point and found it extremely difficult to find documents about how to acutally program for X. Widget toolkits are not enough in some cases. Some books about low-level X programming are at:

http://www.pconline.com/~erc/xwind2nd.htm
http: //www.pconline.com/~erc/advxwnd.htm

Unfortunately, I've lost the URLs for the X API docs and containing really good example documentation on X Windows programming in C. If anybody has these URLs, I'd appreciate it, since it took me several days of searching to dig them up and I can't find them anymore (harddrive crashes suck).

-1 Troll(tech)

[CausticWindow]

This article reads like a Qt flamefest.

I don't see how Qt's "business like homepage" should have anything to do with how good a toolkit Qt is. The "free for linux not for w32" is of course a valid point, but it's the only one.

Re:-1 Troll(tech)

[LizardKing]

This article reads like a Qt flamefest.

Certainly does. He also dislikes C, yet he programs using GTK+. I guess he must be a fan of gtkmm. Frankly, I get the impression that the articles author is a little bit inexperienced, and would be better off learning Java and its Swing API. That will give him a decent grounding in MVC architecture, while keeping him otherwise occupied so that he doesn't write any more articles :)

Chris

Exactly

[Anonymous Coward]

I need to write GUI code that works on all Linux, all HP-UX, all SUN Solaris, all SGI platforms without requiring more than a simple "make".

Our customers would not like it if I told them to find and install version 1.2 of GTK and stuff like that, because in all honestly, on any platform other than Linux most of these toolkit libraries have no simple install mechanism and tend to be buggy.

So Xlib all the way... Simple and it runs on even a 10 year old version of Linux.

Why the Qt bashing?

[arvindn]

Look at the last paragraph of the article:

I personally think Qt is made irrelevant by both of the others because they are not missing anything Qt offers. The tools that come with Qt may not be bundled with them, but comparable tools do exist and can be used free of charge, and most often as Free Software. Qt's biggest weaknesses are its relic called "MOC" and its business orientation. Yes, it's GPL, but not for MS Windows, so you're not really free. FOX and (especially) wxWindows offer similarly advanced sets of widgets and techniques, so you might as well throw Qt away. In terms of portability, it's the same, and wxWindows even adds OS/2 portability. Believe me, I don't want to be unfair to Trolltech or upset dedicated Qt developers. I tried to be objective, and that's my objective conclusion. Maybe we can discuss this point in the comments for this article.

There is a disturbing trend of recent articles that engage in Qt/KDE bashing. Can't help wondering whether it is really a coincidence or not. For instance, here's another freshmeat editorial from a few months back.

Missed the best

[norwoodites]

He missed the best: GNUStep.
GNUStep uses Objective-C and is a clone of the OpenStep API's and is pretty stable.
To write a simple Application you do not have to write that much code any more.

Re:Missed the best

[roard]

I agree, it's quite shameful that he didn't even dared to mention it.

GNUstep is a true object oriented framework, running on Linux and other Unices, and there is even a port for Windows in early stage. It's an OpenStep implementation, as MacOS X's Cocoa, thus you could port GNUstep applications on MacOS X and MacOS X application on GNUstep very easily. GNUstep also has great RAD tools like Gorm, modeled after NeXT's InterfaceBuilder.

GNUstep supports distributed objects out of the box, has a great database library (you just deal with objects, define a link between thoses objects and your database's model, and hop, no need to SQL), support scripting very easily, uses the PostScript imaging model (no need to maintain two versions of your code for display and printing), etc.

A good example of a GNUstep application compiling both on MacOSX and GNUstep is GNUMail, available on http://www.collaboration-world.com/gnumail ...

I urge people to check http://www.gnustep.org website :-)

You could find informations and articles about GNUstep on http://www.roard.com/docs , there is also the gnustep's wiki (http://wiki.gnustep.org), a good GNUstep's site for news on http://www.gnustep.us and a great guide for installing GNUstep (http://gnustep.made-it.com)

It's really a shame that so few people contribute to this great project...

Re:Missed the best

[UnuMondo]

I agree. I came across GNUstep two months ago and was amazed by its incredibly simple API. I quickly made my first app, Charmap, a character map which uses Unicode.org's standards files to provide a wealth of information about any character. This was easy and fast because GNUstep provided solid Unicode/UTF-8 support from the start. While for example GTK was a pain to use until 2.0 with regards to non-Latin scripts, GNUstep at the same time had one of the most advanced string classes.

Not only is GNUstep concise and simple, but because Apple's Cocoa is also an implementation of the OPENSTEP standard, one can use Cocoa docs in GNUstep programming. This allows the programmer to tap into abundant resources online and in print.

If you're interested in what's going on in the GNUstep world, my favourite resource is www.gnustep.us, which lists the latest news and updates. I hope I don't sound like a karma whore, I'm just super-enthused about a fantastic API that doesn't get the attention it deserves.

Re:what no TK?

[DavidNWelton]

1) Tk is very fast to develop with. You can get good gui's out quickly.

2) So now you want to do a complex, involved gui? You can do that too. Don't like stuff that was thrown together quickly by people who don't know anything about GUI design fool you. It's hard work, and it takes a different set of skills. Just because Tk made GUI programming available to just about everyone, don't judge it on the results of everyone trying to do GUI's!

3) Tk has been around for a while, is well tested, well known, and well built. It is the toolkit of choice for Tcl, Python, and lots of other languages.

4) Of course, it is open source, and lots of people use it and know it. If you want to improve it, you can.

Making Money == Evil?

[avdi]

The article's biggest strike against Qt is "Very business-oriented main Web site". What the hell is that about? "I'm shocked, shocked! to find marketing going on in this business!". Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web. That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow. If you object to their business model, just say so. But objecting to the fact that their corporate website is "very business oriented" is like objecting to the fact that Slashdot is "very geek oriented".

Re:Why would you want to use anything but Swing?

[truth_revealed]

Why a native C/C++ GUI toolkit?

- can distribute a statically linked 2 meg executable - quick to install
- typically only 2 megs of resident RAM used by running program
- virtually zero startup time
- much more responsive GUI
- still runs well on hardware more than 4 years old

Why not Swing?

- don't want the 40 meg downloadable JRE footprint
- don't want Java version hell for your users/customers
- don't want the 40 Meg of resident RAM required by the smallest running Swing program
- requires the latest hardware for decent speed.

Re:Documentation

[DavidNWelton]

Many have enjoyed how easy Tk is to use and how x-platform (and
x-language) compatible it is, much easier and more stable than other
toolkits mentioned.

A common complaint has been the default Motif look and feel on unix
(this is easy to change, but many don't bother changing the
defaults). This is about to change. Tk 8.5, currently in development,
is going to represent a major revamp of Tk. Basic things like updated
default look and feel as well as enhancing the core widget base (there
are 100s of widgets for Tk, but only 15 in the "core").

This is also meant to target all Tk users (not just Tcl users). There
are lots of widgets out there only available to Tcl/Tk users that
could be made available to Perl/Python/Ruby/R/Lua/etc if a better
framework were used so widget authors understood the basics of having
their widgets used by multiple languages. Numerous other enhancements
are planned, all to be done on a tight schedule (we don't like waiting
for software). You can see the a wiki for this work being built at
http://tcl.projectforum.com/tk/

My 2 cents

[truth_revealed]

Qt:
- most polished GUI of the bunch, great documentation, great portability, looks great.
- typesafe callbacks
- smallest learning curve - very easy to use.
- downside: price, MOC preprocessor, very long compiles.
- recommendation: if you have the money - go buy it.

FLTK:
- perhaps the fastest and has the smallest memory footprint of the bunch.
- small size comes with a price - the look and feel is noticably "off" and often you get non-standard widget behavior.
- void* based event callbacks
- fastest compiles

FOX:
- programs look quite professional
- non typesafe events void* pointers that are a royal pain in the butt to use, and are very poorly documented.
- lack of virtual functions for most GUI classes - must use table dispatch for each new class to override behavior.
- only supports UNIX (X11) and Windows
- only has Windows 2000 look on any platform, but looks quite good nonetheless with minimal flicker
- small user base
- no CVS access - maintained by one individual

WxWindows:
- supports the most platforms, has native look.
- large community of support
- many interpreted language bindings
- different behavior on different platforms
- widgets flicker like crazy
- not very stable in my experience