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

what no TK?

[Anonymous Coward]

what no TK?

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.

Re:what no TK?

[andrewl6097]

Exactly. The coolest part about TK (well, at least tkinter for python) is that you can "connect" a widget and a variable - someone edits the widget, and the variable changes value, automatically. Saves a LOT of code that would otherwise listen for event -> get widget value -> set variable value.

Re:what no TK?

[lunenburg]

Have you ever tried to program using the perl bindings? I have done it in the past and was extremely annoyed by the fact that it is a non-stop moving target. It also broke quite often. I ended up abandoning the entire stuff.

Yup, sure have. I've been working with this app for going on three years, producing useful releases every 4-5 months or so, and haven't run across a "moving target" in Perl/Tk. Aside from bugfixes, I haven't had to go back and change any of my code or work around any brokenness in new Perl/Tk releases.

Granted, my app doesn't tax the outer limits of the Tk bindings, but for what I do, I've found Perl/Tk to be a stable and adequate cross-platform toolkit.

Re:what no TK?

[__aavhli5779]

More importantly... What, no GNUstep?

It's amazing how much GNUstep is overlooked given that it is the only toolkit whose featureset can compete with qt. Just like qt, GNUstep is a full framework covering much more than simply building a GUI, and can thus be the foundation of an entire application/environment. The OpenStep frameworks (of which GNUstep is an open-source rewrite) address everything from low-level primitives (collection classes, advanced memory management with garbage collection) to networking, file operations, GUI operations (with a graphical IDE and GUI builder modeled after NeXT, now Apple's Project Builder/Interface Builder) and more.

If more attention were paid to GNUstep, it would get the usage that it deserves. I find it superior to almost every toolkit except for qt (with which it competes neck-to-neck in terms of featureset and consistency), and any Mac OS X or OpenStep/NeXTStep programmer will give a glowing recommendation. Plus, it uses Objective-C :)

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

[Doesn't_Comment_Code]

No, I think this is different than most libraries. In general, commonly used libraries are already in the proper directory, ready to be used. But windowing toolkits aren't generally installed by default. Specifically, if you are compiling code that uses one of the more obscure windowing toolkits, you have very little chance of already having the proper libraries in place. In which case you will have to go hunt them down.

Re:One thing missed

[Sean Starkey]

This is a strange comment. It is like saying, "The one thing I don't like about C++ is that if you distribute the source code, whoever is compiling needs to have the compiler."

Of course you need the toolkit library if source code uses it.

Re:One thing missed

[mce]

No, he's not trolling. He's simply observing that there are a lot of GUI toolkits around and that most of them are not pre-installed on "your" standard off-the-shelf Linux box.

Before you misunderstand me: apart from the X server, my own box was built by me from the source and nothing but the source. Which is to say: I fully understand how libraries work and I don't mind looking for a bit of extra source if it looks like it might be useful. But for the very same reason, I also know from experience that some apps require a lot of effort to first collect all the dependencies and to then succesfully build them. And in my experience quite a few are not worth it if they require me to spend a few hours on tracking YAT (Yet Another Toolkit) first, especially if chances are slim that I will want to install another app that can live with (the same version of) the same toolkit.

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.

Re:One thing missed

[mark_lybarger]

normally you know that going into the effort. and i would guess that there's typically an easy way to get those things installed properly (apt-get, install shield, emerge, rpm, etc, etc). yes, if you're developing a kde/qt app, or a gtk+ app or a wxWindows app your user base will be slightly diminished. if someone wants the app, they'll get it. hell, the postgresql has a database management utility that's based on the wxWindows toolkit and has a nice and easy windows installer.

Re:One thing missed

[cheezit]

I've done this multiple times. It's easy to do when you write from scratch with this approach, much harder to retrofit, but it comes down to the same issue....CLI apps tend to have a scriptlike UI, whereas decent GUI apps *demand* that multiple actions be available to the user at any time.

This requires that the application logic be converted into an event-driven state-machine model. Some CLI apps just can't make the transition without a rewrite.

Once the transition is done, though, you are right...you can make an app support almost any UI, including supporting a CGI interface for the web (assuming that's appropriate).

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).

Re:X Programming In C

[Mandrake]

I highly recommend the X Programming manuals by ORA - particularly volumes 0 and 1. the rest are fluff, imnsho.

volume 1 does contain some documentation about writing a window manager, but it is really insufficient. if you're looking for appropriate documentation on what it should do, you can find the icccm documentation online somewhere (most modern window managers are NOT icccm compliant however)

Re:X Programming In C

[Anonymous Coward]

http://tronche.com/gui/x

has a good X api reference

Re:X Programming In C

[thames]

I have the following links (I'm trying to write a window manager myself... :-)
I hope these are the ones you lost:

http://www.xfree86.org//4.3.0/manindex3.html
ht tp://tronche.com/gui/x/icccm/
http://tronche.com/ gui/x/xlib/
http://x.holovko.ru/Xlib/contents.htm l

Hope someone finds them usefull...
Creating a window manager, is actually quiet fun, as long as you have others code to look at...

Re:X Programming In C

[AJWM]

the rest are fluff, imnsho.

Hardly. If you're doing Xlib programming (Vol 1), then you'll also want Vol 2 (Xlib Reference Manual). Granted, Vol 3 (X Users Guide) probably won't tell X programmers much they don't know, and if you're using one of the non- Xt-derived toolkits (GTK, Qt, etc) then the later volumes (4 & 5, Xt Programming and Reference Manuals respectively, and 6, Motif) aren't necessary -- unless you ever hope to figure out how some of the older code out there works.

Nobody uses XView (Vol 7) any more (do they?) and the X Window SysAdmin's Guide (Vol 8) is useful only to sysadmins of large X-based thin client installations (such as Largo City FL, perhaps?), but I wouldn't exactly call them "fluff".

(And yeah, I've got the whole set, including both "regular" and "Motif" editions of some, plus the R6 supplement, and the "Nutshell" volume -- which is actually pretty handy as a desk reference over the thicker volumes. But then I've been doing X Windows programming since late X10 days circa 1987.)

Why would you want to use anything but Swing?

[Anonymous Coward]

It's far more easily cross platform than the competitors. It's a rich GUI toolkit, not limited by least-common-denominator weirdnesses, and backed by a world class rendering layer (java 2D).

Todays Java is not at all what old Java was. It's far faster, and only getting faster with each release, than in the past, far more reliable, far more complete, etc.

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.

This Guy is heavily biased against QT

[Anonymous Coward]

This made the article useless. I wonder if he has ever tried QT. It just works! No futzing around. He is biased because you have to pay for the windows port.

-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

Re:-1 Troll(tech)

[Des Herriott]

Yep, the author obviously has some kind of beef with Qt.

"Commercial" and "proprietary" are not at all the same thing, but the author believes you need to pay to sell Qt applications. Wrong - you are permitted to sell GPL-licenced software.

The fact that the toolkit is large and takes a long time to compile (a few hours on a moderate-spec PC) is irrelevant. You don't need to recompile your toolkit every day, and you get binary Qt packages with most Linux distributions anyway.

"Business-oriented main website" is a non-argument, as you say.

"Main branch depending on one company" is a non-argument, since even if Trolltech folded tomorrow, a GPL-licenced Qt can be picked up by volunteers, just like any other free toolkit.

The namespace concern is the only minus point with any merit - on the other hand, I don't see Gtk+ using namespaces either, and that wasn't mentioned as a minus point, was it? (Yes, I know Gtk+ is written in C - but that doesn't alter the fact that it too does not use namespaces)

This article wasn't a summary, it was a soapbox rant.

Re:-1 Troll(tech)

[Xerithane]

I don't see how Qt's "business like homepage" should have anything to do with how good a toolkit Qt is.

Considering that Trolltech is a business, I think it does reflect the quality of Qt. If Trolltech was a business, and their website looked like half the other OSS projects out there, nobody would take them seriously.

The "free for linux not for w32" is of course a valid point, but it's the only one.

That isn't even a valid point. Qt 2.3 for Win32, free.

Re:-1 Troll(tech)

[n3bulous]

Bah. Not sure how that space got in there...

KDE MYTHS

Re:-1 Troll(tech)

[Pr0xY]

also, the author misses a another buig point. I spoke to trolltech support about having to release code under GPL using the free liscense, and they agreed to only have it apply to code that actually included QT code.

For example, I have written an emulator which I havent open sourced yet, and 95% of the code is ANSI C++. Why should i need to open source the whole thing? I found them very accomidating in the fact that I would only have to open source the the parts that actually used the QT classes.

All in all QT is the best object oriented toolkit out there, they are a very professional company and a previsouly noted this should be a moot point when anylizing the toolkit itself.

proxy

Re:-1 Troll(tech)

[i_really_dont_care]

"Commercial" and "proprietary" are not at all the same thing, but the author believes you need to pay to sell Qt applications. Wrong - you are permitted to sell GPL-licenced software.

Yeah right, good luck...So then why do you think QT sells you the right to use another license than the GPL?

Seriously, GUI toolkits are quite trivial things nowadays. There are alot of them, and most of them are just fine for usual tasks. Even if QT may have some slight advantages in one place or another, I seriously doubt this difference is worth thousands of dollars. Heck, even Lesstif is LGPL. Also, with GTK+ and wxWin finally catching up, I doubt that Trolltech would have that many customers if it weren't for KDE. And I dare to predict that the more popular Linux gets, the more apparent this problem will get, because people will be running KDE, but all commercial software will be based on GTK etc., destroying all the potential for this superior desktop...

Re:-1 Troll(tech)

[mnmn]

We have been evaluating GUI APIs for two projects we will be starting, and it came to QT, GTK+ and FLTK. It seems like we will go with QT despite the cost because theyre really a professional company with a complete API thats well documented and well used by large apps, uses win32 API very efficiently (see how fast opera the browser is) and comes in embedded versions too, which was one of our requirements. GTK+ for win32 is not mature enough although it competes with QT on unix quite well. It also has shortfalls with embedded systems whereas QT's qtopia has been used on many PDAs and theres a software base there.

I'm not worried about the UIC and tmake from QT, I just throw them into a makefile and it all works from a single 'make'. The plan is to distribute binaries alone.

The author in the summary tries to hide his beef with QT for a good reason. QT is the only one in the list thats not truly opensource compared to the rest, yet KDE has been competing with GNOME for a while. I think GNOME was started to counter KDE because it was based on a non-GPL API.

writing graphics software

[dollargonzo]

one of the biggest problems in writing a RAD graphics software is that lots of users want it to interface with a lot of different toolkits, such as motif, qt, gtk, tk, xt, etc. obviously, it would be nice if they all just chose one, but that will not happen anytime soon. now, we[the company in mind] are thinking of writing our own low level toolkit (since the software currently doesn't have its own widgets). this is basically how new toolkits come into existence and the user base is forced to choose at yet another fork in the road. *sigh*

Re:writing graphics software

[Christianfreak]

Use wxWindows. It uses GTK on Linux/Unix or Motif if it isn't availiable, and it uses the Win32 API on Windows. The only place it wouldn't look normal is if someone was using it in a KDE environment but most people using KDE are using Gnome apps as well and most distros use themes to make them look the same there.

Either that or build on top of Mozilla and use XUL.

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.

Re:Exactly

[RevAaron]

I too need to write GUI apps that just work on a number of platforms- Mac OS X, Mac OS Classic, Windows, Linux, IRIX and Solaris, and have it work with a simple ./configure; make.

Luckily, I don't have to use Xlib, although the display system for X11 probably uses Xlib. I use Squeak Smalltalk, and can distribute my application with the virtual machine for the specific platform, or as Unix source for somebody to compile if they're on a more obscure platform. This can be easily included with my tarball- no need to download stuff seperately. It is also a small addition to my own code, so it's not like you're adding a big download or hassle.

GTK+, Qt and the desktop libraries that accompany them, on the otherhand, *are* a big hassle. Most Linux systems have a version (or two!) of one or both of those libraries, but often enough when deploying, you still have to have them install the version you wrote your app against- and you better believe it's not quick and easy!

Re:Exactly

[AvitarX]

Why don't you do what normal software distributers do?

Include GTK 1.2 and then have your instal check if it is needed, if it is install it.

Like when I buy a game I get DirectX with it. I guess installing that library is gonna kill me.

There is no reason you can't include GTK 1.2 since it is Open source.

Of course the bugginess is another issue, and obviously if that is the case you cannot use it, but I see no reason you can't make it easy to install by modifying your make script.

Even the Gimp was an easy install in Windows once I found all the packages, but someone could have bundled them together easy enough.

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.

Re:Why the Qt bashing?

[Stele]

The author doesn't even go into the respective DESIGNS of the toolkits either.

I've used several toolkits on several platforms in shipping, commercial software over the past 10 years, and taken a look at many of the "free" toolkits out there, and ended up going with Qt just because it has a superior (in my opinion) design.

I've spent more than a few hours trying to get these so-called cross-platform toolkits to build on Windows and Mac, and usually, they are half-finished implementations - just like you would expect from people not getting paid for their work. I'd rather not fiddle endlessly with code that doesn't quite compile, different build environments per platform, or just plain poorly-designed APIs. I was almost on the verge of writing my own GUI toolkit when I came across Qt - never looked back, blah blah.

wxWindows, in my opinion, has a design too similar to MFC - reliance on resource files, enumerated control IDs, message maps, etc just seems like a blatant rip-off of MFC, which is one of the worst toolkits out there.

Qt's built-in Motif-like layout, signals/slots, unreliance on resource files, great cross-platform build environment, and great documentation is amazing, and makes it well worth the cost for commercial development.

wxwindows - wxpython

[nuggz]

Cross platform, native widgets.

Combined with python it is very simple and easy.
I wouldn't make commercial apps, but for small development, it's my choice.

Toolkits do sacrifice flexibility

[r6144]

If you are developing a cross-platform high-level GUI application, just use toolkits. You don't need the flexibility of Xlib.

However, for those developing low-level X programs such as window managers and XIM servers that need to meddle with (say) ICCCM details, you are probably better off just using Xlib --- just like programs doing low-level I/O are better off using low-level functions instead of stdio.

Note that even in some cross-platform applications some non-portable stuff is needed in order to tune user experience, for example you may find a cool new feature of recent window managers accessible via ICCCM beneficial (albeit not essential) to your application, but toolkits haven't integrated such things yet. Therefore, it is very important that toolkits give access to low-level things like Window/Atom/Pixmap IDs so that bypassing it occasionally is possible. I don't know about others, but GTK does well in this regard.

Need monolithic executables

[Anonymous Coward]

I'd be nice to be able to static link into
one giant executable. I hate having the
incompatible libraries problem. It's like
DLL hell in windows. It'd be nice to have
a full featured GUI library (and other tools)
that can create one big executable file.
GTK programs require a DLL in windows.
WxWindows programs require GTK libraries on
Linux.

Re:Need monolithic executables

[suchenwi]

If you can live with a non-giant executable too, maybe a Starpack could interest you: a complete Tcl/Tk runtime system, plus your own app, all in one executable file, starting from under 1 MB. Zero installation.
See http://www.equi4.com/starkit/

Documentation

[lunenburg]

For me, it came down to documentation. I have a moderately complicated GUI Perl app (Perl because it was the language I was most familiar with). I looked into various toolkits, like wxPerl, GTK/Perl, QT/Perl, but ended up using good ol' reliable Perl/Tk.

The big advantage with picking up Perl/Tk was that the O'Reilly books were extremely informative - good examples on each widget, how they interoperate, how to use them, and larger program examples. The documentation for the other toolkits I considered basically consisted of "look at the arguments this C++ function takes, and use it," which didn't make for an easy time picking things up (wxPerl was the worst in that regard). While an experienced C++ programmer might not have a hard time with that, it was way over my head.

As a result, though, I have a decent app that runs on X11 and Win32. With the great PAR archiver, I can even package the app up in a nice bundle.

Good times.

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/

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

[roard]

I should also add that it will be *really* great if more people sign the petition to ask Sun to release the LighHouse Design applications ! the petition is here : http://www.petitiononline.com/laafs/petition.html Sun doesn't use thoses software at all, yet some are really great (for example, Quantrix, a multidimensionnal spreadshit, or VarioBuilder, a tool to create small database-based applications like MSAccess).

If Sun choose to release some of theses apps, it would be possible to port them on GNUstep and MacOSX !

So please, sign the petition !

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.

FLTK licensing is *incorrect*

[Junks Jerzey]

The author claims it is not free software. The FLTK site claims otherwise:

FLTK comes with complete free source code. FLTK is available under the terms of the GNU Library General Public License.

We have ammended the LGPL to explicitly allow static linking of FLTK (or any modified version of FLTK) to your software. The LGPL is not clear on this and we definately want to allow it.

Program in what you like

[ChiefArcher]

Program in what you like...
Although programming in QT won't get it included into gnome and programming in GTK won't get it included in KDE.

A lot of apps people develop never see the light of day... I've programmed hundreds of little apps for the various companies I've worked for.. I programmed in what I liked.. and what I was used to...

Just because you need to create a little app with a textbox and a button doesn't mean you need to include the HEAVY libraries of gtk/qt/gnome/kde.

Just my thought.

ChiefArcher

What, no {Mo,Less}tif?

[AJWM]

Yeah, I RTFA and know he disses them with "too hard, too much like Xlib" (actually they're built on Xt, which is built on top of Xlib).

But anybody who thinks Xt is "too hard" probably is out of their depth programming GUIs anyway. (Now, if you think it's ugly, that's a whole 'nother discussion...) And nothing else gives you that level of flexibility and control. (Well, nothing else sane -- if you want to code direct to the X protocol, go right ahead...)

Re:What, no {Mo,Less}tif?

[muonzoo]

Took the words right out of my mouth. I've be writting GUIs and graphics applications for X since X11R3. Xlib has a bit of a curve to it, but if you have any background at all in computer science and graphics, it isn't too hard to understand the abstractions. The X Window System has a long and interesting history.

Xlib still has a lot going for it, espcially in terms of availability on the various UNIX variants out there and one of it's often overlooked features, especially by younger less experienced developers: network portability. This feature is absolutely wonderful inside a corporate or research environment where your workstation isn't necessarily where you run your code and/or do your work.

Xlib + Xt + Motif + MotifTools (or whatever they are called today) is still a viable, useful toolchain for developing applications. Canada's latest civilian Air Traffic Control Enroute system (CAATS) uses Xlib + Xt + Motif for it's extremely customized UI. (It's not for the faint of heart -- no help ballons there). The Canadian Military also adopted a system based on the same underlying technology (from the same vendor) for it's ATC enroute and local control.

As always, the right tool for the right job, but also, the right developer for the right job helps a lot too. You wouldn't let a kid loose with a jackhammer, so why let an inexperienced software developer loose with Xlib + Xt + Motif? :-)

Missed the most promising one: Java/SWT

[Anonymous Coward]

I can't believe this author missed the one toolkit that's been making so much wave in the last year, namely Java/SWT.

It's the toolkit used to create the Eclipse IDE from IBM, similar in approach to wxWindows...i.e. renders using native widgets on each platfrom (win32 APIs on Windows, GTK+ 2.0 on Linux, Aqua on Mac OS X), but with the same common API on all platforms.

Did I mention coding in Java is much easier than fighting with ancient macros in C or C++?

Plus, SWT apps start up real fast and consume much less resources than the infamous default Java SWING toolkit. Just look at the difference in responsiveness between Eclipse and NetBeans (I call it the Molasses IDE in tribute to its speed).

SWT is the future of Java GUI and because it renders with native widgets it's the way to go for the future.

Did I mention it's open-source and 100% free on all platforms, including windows (unlike Qt).

Plus...you get access to all the standard Java libs (db access, xml processing, web services, threasing, etc...)

Re:Missed the most promising one: Java/SWT

[javatips]

The fact that Netbean is very slow is not due to Swing.

Just look at JBuilder, it load as fast and is as responseive as Eclipse. JBuilder is using Swing.

You should never compare two different toolkit by just comparing just one application for each toolkit.

Also SWT as some portability problems. They get addressed pretty fast, but is not as portable as Swing is.

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:Making Money == Evil?

[WNight]

What's is it with all of the "Poor Trolltech" sentiment in this thread? If their GUI library isn't available on Windows without paying money for a development kit and a license it's not as useful as free cross-platform libraries.

If I write some neat program for myself and friends in Linux, it'd be nice to do it with a GUI library that'd let me, with a minimum of porting hassles, release it for friends in Windows as well. Not worth the $1500 dev kit, but still handy.

Or perhaps if I was starting as a shareware developer. $1500 isn't much when the money starts coming in, but it's a lot up front.

Being that portability to Windows is a handy thing, I think the issue of QT being a business and charging for that ability is directly on topic.

Yes, we know, for the trillionth time, that the job of a company is to make money, yada, yada, yada... That doesn't mean that our job is to supply a company with money.

Re:Making Money == Evil?

[denshi]

Hi.

Qt was around years before KDE. And Trolltech was a smaller, but still successful, company back then. I was programming Qt back in 1997? 98? It was rock-solid even then. GTK+, which, I might add, was being developed for political reasons, was kind of a permanent, bloody migrane to work in. And let's focus in on the reasons again. Qt was there. Then KDE happened. Then Miguel and co pitched a fit that this well-designed app was becoming a new Linux standard, and screamed bloody hell that it was based on a non-GPLed toolkit. Qt was free on Linux, but That Wasn't Good Enough. They borrowed the toolkit from GIMP, called GTK internally, renamed it as GTK+, decided to keep it in C, and started work on it and GNOME in order to preserve GPL sanctity on the Linux desktop. Scroll forward two years. You find that KDE has continued lightyears ahead of GNOME, and that in response to the GNOMEitistas, Trolltech has first created the QPL, which the OSI rated as open-source, but since That Wasn't Good Enough, Trolltech then released Qt under the GPL, but somehow that STILL Wasn't Good Enough for the GNOMEitistas, and so the silly war continued...

I don't know if you've been around that long. But there's the background on the FUD. There's a bit of a tendency in the slashdot crowd to just accept the years old FUD and not think about it too much.

"The community at large" I guess kind of means whatever you want it to mean. If you mean "GUI developers", then, no, C is not the standard, C++ has been the standard for years. Passing C++ references and calling object methods is the way most GUI programming is done, not writing preprocessor macros to magically objectify sickeninly complex C structs and chasing function pointers around the app. If you mean, "open source programmers", then no, C is still not the standard, C++ and Java compete with all the scripting toolkits out there now. If you mean "slashdot bigots with poor grasp of history", then yes, you could say that C is the standard.

PHP-GTK

[mcrbids]

Officially, PHP-GTK is at version 0.5.2 - "alpha".

I've written a 20,000 line software package in PHP-GTK and I can say that while GTK 1.2 is a bit funky, it's quite powerful and very stable.

Binding Gtk with the power and rapid development speed of PHP, using an IDE such as Dev-PHP results in an environment that's blissful, stable, and cross-platform.

The aforementioned application is currently in the midst of a very successful Beta on Windows, and once released, will be shortly released for Linux and Macintosh. To "compile" the software we used the Ioncube Encoder.

Gotta love it, eh?

Been there, done that...

[syrja]

Well, how many of you have really tested all mentioned GUI toolkits? I did that some time ago and ended up using FLTK, basically because of reasons mentioned in article: standard C++, free, light and stable Win32 support.

QT != evil

[scharkalvin]

"What you get when you download Qt 2/3 is the free X11 version ("Qt Free Edition") which enables you to write non-commercial applications for The X Window System. When you want to create commercial, proprietary, or non-free software, or want to compile your program for Windows or embedded systems, you'll have to pay for the Qt Professional or Enterprise version (both are quite expensive). Qt tried to specify this in their own license (the "QPL") because they felt the GPL could cause them some problems (please see freshmeat article #180 for more information). From Qt 2.2 and upwards, you can now freely choose between the QPL and GPL before building the libraries. That's the whole story; if you feel I missed an important point, feel free to correct me (Qt flames go straight to /dev/null, though). You can read more about Trolltech's licensing issues in freshmeat articles #170, #172, and the one mentioned above."

The author probably doesn't understand the GPL. All of the other tool kits distributed under the GPL can be used in commerical applications and SO CAN THE GPL'ed version of QT. You just have to accept the terms of the GPL to do so, IE: your application must be open sourced! In this sense QT has an avantage! If you buy their commerical license you may then close source your application. What they have done is allow you to pay extra to by-pass the GPL. How is this an evil thing? The other kits do NOT give you a choice, it's the GPL or nothing! Choice is good. QED.
QT != evil.

Re:QT != evil

[mrroach]

I'm afraid your premise is incorrect as all the toolkits besides QT are under the lgpl or even less restrictive licenses (wxWindows, X11). This means your application does not have to be licensed under the gpl to link with it.

This means that GTK not only gives you the same choice, but doesn't require any money for choosing non-gpl.

(this post to be followed by umpteen rants on how the cost of QT is "worth it" in every single scenario)

-Mark

Fonts!

[r6144]

On linux the best looking fonts are anti-aliased TrueType, which Swing doesn't support. Bitmap fonts also look good when not scaled, but it is also very non-obvious (if not impossible) to make them the default in Swing apps. So we are left with ugly non-antialiased TrueType fonts. Ugh!

(Well, maybe it is the fonts that are not as good as Windows fonts... But if you want to work with international text, even Window's unantialiased non-bitmap Chinese fonts look VERY ugly.)

Agreed. And that's not all... (rant)

[Balinares]

I have to agree. Sounds like someone with an axe to pick and yet trying to come across as an "oh look at me I'm knowledgeable and unbiased!" kind of writer. Feh.

So, let's see.

First of all, isn't it funny how the author omits to mention how a clean and thoroughly engineered class hierarchy can help you design more modular software that will be much easier to maintain and refactor? Or do people really think that the KDE project has been improving at the pace it has by mere luck?

> Very business-oriented main Web site

That's a problem how? Do you really MIND that the site provides info for people other than geeks, along with, you know, a completely up to date documentation for each version?

> Main branch depending on one company

This is either pure ignorance or a lie. Typical underhanded FUD. The main branch is GPL'ed, and the KDE Foundation was established to keep the main branch GPL'ed no matter what happens to Trolltech.
http://www.kde.org/whatiskde/kdefreeqt foundation.p hp

> Commercial developers and people wanting portability have to pay

Commercial developpers *ARE* allowed to sell GPL apps, dammit. THIS is the way of Free Software business.
And Qt 2 is available under for GPL on all the main platforms. That's for portability. Only Qt 3 for Windows requires a commercial license (this wasn't always the case, but according to interviews I read some Windows developpers would routinely use the GPL version in closed source apps, so Trolltech had to discontinue the GPL license on Windows. Thank you, guys. Thank you so much.)

> Huge sources and binaries, library itself takes ages to compile

That's C++ for you, dude. Install a binary package next time.
Additionally, and just because I'm pissed and am most willing to nitpick the bullshit out of existence, 1) Qt ships will ALL the major distribs, and a majority of minor ones -- no need to recompile it, and 2) You don't need to recompile it either for use with older software, as the API is backwards compatible -- which is not the case of all the APIs out there, which he blissfully omitted.

> Objects not referred by namespace but simple literal prefix "Q"

And that's a problem how?

> Dominant Microsoft Windows look

This is either pure ignorance or a lie. I won't even enumerate the number of looks Qt comes with *natively*.

In fact, this is so close to the usual Qt FUD you can hear from certain people that I strongly suspect that the whole purpose of the article was a clumsy attempt at slowing the growing popularity of Qt. Well, sorry, but such retarded FUD won't last three minutes on Slashdot. We may be a bunch of bickering nerds at times, but we know our shit.

If you don't like Qt and are concerned about its growing supremacy, which is your absolute right, then contribute to competing projects to help them improve. Trying to smear shit on competitors will only make your side look desperate. Is this what you want?

Rant other. Let the moderation begin, I have karma to burn.

Re:(OT) Good online GUI standard documentation?

[arkanes]

here is a link to the offical Windows XP visual style guidelines. I know theres some earlier versions as well, just do some searching on MSDN. Be aware that MS often violates these guidelines, so your developers may dismiss them.

Re:Please avoid GTK

[samhalliday]

yes, and the gtk/gnome developers would agree with you. thats is because gtk-1.2 has been pretty much deprecated for about 3 years now. please use gtk-2.2. it is far from ugly and has much greater cross-platform and cross-nationality support than any other GUI lib i have ever encountered.

Making Money == Good for Free Software

[conradp]

What the author claims as a weakness is actually a strength. Qt/UNIX is distributed under the GPL, which means that it can be used for free software development with the same freedom and same restrictions as any other GPL'd software library. However, if you can't comply with the terms of the GPL (because you are doing proprietary, closed software development) then with a normal GPL'd library you'd be SOL, but TrollTech gives you the option to pay them some money and obtain Qt under a commercial license.

This gives Qt a huge *advantage* over over the other libaries. By having its "business-oriented web site", it suckers thousands of large corporations into paying $2000 each for a Qt license. TrollTech uses this money to support the further development and improvement of Qt, which benefits both the commercial licensees and the free software, GPL users. Sure, they probably line their own pockets with some of the money, but no more than owners of RedHat, Debian, etc. Other libraries depend on volunteers performing intermittent maintenance and development, while Qt has an ever-increasing staff of paid developers.
+
My small company uses Qt for both free software development and proprietary software development, and we consider the $20K or so that we've sent to TrollTech to be money well spent!

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

What about XVT?

[Xentax]

I thought XVT was "out there" along with these other tools. Is it too small to show up on the radar, or is something else going on? (www.xvt.com for the curious)

Xentax

Stop spreading lies

[Anonymous Coward]

If you had the decency to give correct numbers,
your post would be much more relevant.
- the JRE download is 14,153,852 bytes for the latest version. And you download it once for all
java applications. How big is Qt?

- there is no Java version hell. Java is much more mature when it comes to different versions. You can still run Java classes compiled with version 1.0.

- 40meg memory? Speaking of Java 1.2, you might be right. Nowadays memory usage has been greatly reduced. Futher work is on the way

- latest hardware? Java runs sufficiently fast on my 700Mhz Duron box.

So, get your facts straight before posting.

Namespaces vs. name munging

[Chalst]

The author seems to have a bee in his bonnet about using name munging. While it is inelegant, there is the virtue of simplicity in the arrangement, and the important issue is what sort of risks name munging creates for programmers. The Common LISP module&macro system has shown that name munging need not be problematic in practice.

On the other hand, the interface to namespaces can be a liability in terms of complexity and hurdles to learning.

In either case I'd like to see more analysis.

Re:Why another QT license?

[Xerithane]

My question is, why another license? I actually like QT. I use KDE every day and I write for QT for my private purpose. And I don't care if they charge billion dollars for Windows version. But why did they HAVE TO create yet another license that pose such a strong restriction like "you cannot earn even 1 cent using this software" when it seems (at least to me) that the GPL would have sufficed (and less restrictive)? Would somebody please enlighten?

It's their lifeblood. They are trying very hard to create a commercial quality toolkit for cross-platform development. Their big threat to profits is not gaining compensation for Windows applications. Since Windows is the dominant desktop platform, that is why they want money for Windows development.

I think that it is a touch silly, but I do understand where they are coming from. If you want to do Windows development, you have to pay. Windows is a proprietary/commercial platform so they are just staying with the paradigm.

This toolkit blows the rest away!!!

[Admiral Akbar]

EiffelVision 2 that is available for free download here It is definitely the easiest GUI toolkit to use I've ever encountered, no nasty callbacks here :)

Re:Xlib API still K&R

[penguin7of9]

The article says the Xlib API function prototypes are still K&R.

The Xlib API still has support for K&R, but it also has prototypes.

In fact *any* improvement to Xlib be great for everyone. This suggest it would be a great area for somebody like IBM to fund.

Xlib is just a C library for accessing the X11 protocol. There are several libraries and toolkits that don't go through Xlib at all (e.g., CLX, Escher). But Xlib is pretty good at what it does; it's complicated because X11 has a lot of features.

There has been some work on a new low-level C library for accessing X11 servers, but the community just doesn't seem to have that much interest.

annoying perl

[axxackall]

Programming on Perl is annoying in general, by itself, no matter with TK or something else.

Just try Tcl/Tk or Python/Tkinter and enjoy.

The GUI Toolkit, Framework Page

[Andy Tai]

This may be of interest: a web page that lists almost all GUI toolkits out there, for virtually all platforms (Windows, X Windows, MacOS, etc.) and all major languages (C, C++, Java, Perl, Python, etc.)

The GUI Toolkit, Framework Page
at http://www.atai.org/guitool/

Never let programmers design GUI's

[Ilan Volow]

You made the fatal mistake of letting programmers design user interfaces. Always let programmers design algorithms, and let them design precious little else.

Honestly, it won't really matter what kind of information you show those guys. They'll heel drag even if Bill Gates walks into their office and tells them they're completely wrong.

What you need to do first is design the UI at the start of the project, before any code is written. Once major code is written, most programmers are going to be obstinant as hell about going back and changing something just because someone with far less computing knowledge than themselves has trouble with it. When you do this preliminary design, do it on paper and pencil. Paper by its nature is extremely non-modal, which means whatever design you do will probably result in fewer annoying dialogs and will feel more natural to the end-user. Also, if you do a design on paper, you'll have less reservation about changing the design (as opposed to if you did a mock-up in photoshop, visual c++, Glade, etc) because you put less work into it.

The next project you work on, you might actually want to go ahead and hire a usability specialist who will do much of this annoying stuff for you and might do some testing of the proposed UI on Normal People(tm). If you do this, again make sure you bring the guy in at the start of the project; too often usability specialists are brought in to play damage control after way too much significant code is written, and there's not much they can do because too much code has already been written.

Finally, buy this book and show it to some of your programmers. Most of them will probably not come around to your side, but at least you can say you tried.

Totally missed the point of Qt

[frostfreek]

Qt has THE BEST object-oriented design that I have seen, by far. The widget hierarchy, methods, etc... have a very clean and consistent implementation. Also, the documentation is fantastic! It is always current wrt. the library.

- The ease of code integration into Designer by OO derivation is fantastic.
- The speed at which GUI apps can be developed, using TT's Designer is great!
- The qmake program, while not as capable as automake etc..., is still simple and easy to use. Plus, it takes care of his whining about extra steps.
The 'strengths' section on Qt is hopelessly lacking.

I know that Gtk+ is also OO, but to me it seems they bend over backwards to use C++ features from C, creating a bit of a mess. It is not as clean or consistent, either.

As well, while I H8 Motif, the fact that it was overlooked in this review is pretty bad.

A BIG FAN of Qt,
Jamie.

ZooLib Cross_Platform Application Toolkit

[MichaelCrawford]

The ZooLib cross-platform application toolkit has been around for thirteen years, making it even more mature than wxWindows. Yet it is still in active development.

It's just not very well known yet because it's only been in open source since the fall of 2000. Prior to that it was a proprietary API for the use of Andy Green and his clients Learning in Motion, who used it for such products as the client-server educational database Knowledge Forum.

ZooLib is written in C++, and can produce native executables for Linux/X11, Windows, BeOS, and Mac OS (classic and carbon) with very little need for platform-specific client code.

It makes only very basic use of platform-specific code internally, which is kept encapsulated, so it wouldn't be very hard to port it to a completely new platform. Porting to a new Unix platform that uses X11 shouldn't be more than a day's work, for example. Porting to a platform that had a completely alien GUI API would be a few weeks of work for someone familiar with both the platform and ZooLib.

ZooLib's website has a piece I wrote about why cross-platform frameworks are good for developers:

• Freeing the Developer from OS Vendor Shackles

Re:(OT) Good online GUI standard documentation?

[__past__]

Here are some more UI guidelines:

• GNOME Human Interface Guidelines
• KDE User Interface Guidelines
• From Apple, the Aqua Human Interface Guidelines and the pre-Aqua HIG

"The nice thing about standards is that there are so many to choose from"...

XUL

[hackrobat]

XUL (pronounced "zool").

• Cross-platform
• Based on open standards (XML)
• Extremely easy to customise and play around with
• One major project as a proof of concept: Mozilla (Firebird and Thunderbird)

Ouch

[wrinkledshirt]

Quantrix, a multidimensionnal spreadshit

<sound of jokes writing themselves>