Fog Creek Software
Discussion Board




Lord Palmerston: Cross Platform GUI Libraries

I just read the Spolsky article on cross platform GUI libraries and was relieved to learn that I am not the only one to worry about this issue.

As a TrollTech Qt programmer since the Summer of 2000, I've constantly wondered if I made the wrong choice about GUI toolkits.

If you're not familiar with Qt, it was originally designed as a C++ replacement for Motif that was cross platform compatible/compilable for Unix flavours and Microsoft Windows flavours.  In it's third major release, TrollTech added Macintosh OS X compatibility.  A single source base can be recompiled in a few minutes on a different platform.  A cross platform make tool is included to overcome many of the expected build issues.  Beyond a GUI framework, many helper classes allow users to have guaranteed cross platform container classes and such (there's still much to be done with STL and it's cross platform compatibility issues, although the new C++ ISO standard has helped a great deal).

On Linux alone, which is where I program, there are many GUI toolkits.  Athena from MIT (I think) was for the old schoolers, then Netscape brought Motif into the limelight with Navigator.  Finally, in response to the general [y/s]uckiness of Motif, two different teams produced GTK (which eventually lead to GTK+) and Qt.

A team from the now-famed GNU, wrote a Photoshop lookalike and wrote a new GUI toolkit with it called the Gimp Toolkit (GTK for short).  At the same time, TrollTech from Oslo (Norway) was releasing Qt.  While GTK wasn't cross platform, it was completely free; GPL'd, that is.  Qt was hampered by less-than-free licensing until very recently.

GTK was also backed by the world largest and most recognized free sotware organization: GNU.

Starting a new application from the ground-up, I decided not to learn Motif because I was pretty sure that it was going to be outdated /soon/.  And, fortunately, in the free software world, it's fading fast.  (Of course, in the commercial world, especially back-end systems, many still use legacy Motif apps.)

When I went to the library (I didn't have an Internet connection at home at the time) to research GUI toolkits, I was innundated with choices.  Was Linux the wrong place to be developing?  Should I learn the hardcore internals of Win32 from Microsoft?

In the end -- or rather the beginning of the project -- I chose Qt because it was backed by a commercial venture (GTK wasn't at the time).  Also, it's documentation had a loud fanclub on-line in the GUI newsgroups.  As I would be programming by myself, I couldn't turn to a teammate and ask for help easily.  I didn't think I would have the patience to wait for GTK help through newsgroups all the time.  Qt came with entensive documentation.

Where am I going with all of this: Mr. Spolsky makes an excellent point when he says that in order to truly evaluate a GUI toolkit, you have to bang around on it for at /least/ a year.  For me, it's been more like two years and still counting.  Only this last fall quarter, did I feel comfortable enough with the toolkit (Qt) to begin using the painter device to paint my own widgets (and customize a few).  I'm not even going to pretend for a moment that I'm an amazing programmer either.  I just have the ability to sit at the computer for hours on end reading documentation, hunting through the original source of Qt, and employing trial-and-error techniques to perfect the look-and-feel of my custom widgets.

Even after months of work, I still sometimes stumble across better solutions.  The product, Qt, is so huge -- the documentation must be many thousands of pages now -- it's impossible to know if you're doing it the best way.  Many of the best tricks, like all great GUI programming doo-dads, are, of course, undocumented.  Sifting through the source base of Qt, I have discovered more than my fair share.

I still don't know if I chose the right toolkit, even for my task at hand.  I can barely evaluate Qt, let alone Motif, Win32, GTK, or wxWindows.  How about native Carbon for Mac OS X?  But I can say this: my view of GUI programming has changed radically.  I'm sure Mr. Spolsky could pick up a new set of libraries quicker than most because he has such a history with Win32.  Understanding the paradigm of "event-driven programming" (a gigantic for loop around an even bigger switch statement) and "messaging" (calling the right function/method for the right event) is critical.

If I were to take a job today programming Win32, I'd have an idea on the "black magic" of widget geometry management.  (That's like getting the doo-dads on a dialog to scale correctly and fit together well, regardless of the size of the dialog.)  Perhaps the Microsoft library routines are slightly different.  An adjustment would be made mentally for new function calls, but the high level ideas would remain.

In closing, I couldn't agree with Mr. Spolsky enough regarding flamewars concerning GUI toolkits.  Invariably, each side has only used their respective product extensively and can only make blanket statements about the "other" side.  Each library system will have their our merits and pitfalls.  Learning what they are is far more important than trying to find the perfect GUI framework.  With each new API learned, programmers learn /how to learn/ new APIs better.

Kevin Connor Arpe
Monday, January 13, 2003

Slightly off-topic but has anyone seen any rumblings of a *nix or Windows port of Apple's new MacOS browser, Safari? Or an extraction of Konqueror out of KDE as a standalone?

pb
Monday, January 13, 2003

great post Kevin... i'd like to be an interface designer in the future too so it's a source of inspiration for me... =)

I first learnt graphics programming in Allegro, then I switched to AWT and then Swing... so I've a long way to go!

The good thing is that I like it... =)

Wei
Monday, January 13, 2003

offtopic: I don't think Safari will ever come to *nix or Windows.

Wei
Monday, January 13, 2003

I regularly switch toolkits; it is a bit of a hobby of mine.

I have to say my favourite environment is/was delphi.  I am just disappointed that I have to adjust things when recompiling with kylix.  But anyway, delphi will have you writing custom components in no time at all - the profusion on the web proves the ease of it I think.

My experience of java toolkits (awt & swing) is that swing is nice.  The event model is a bit constricted by the language however; no 'procedures of objects' to assign as event callbacks means everything has to implement listeners etc.  And it would so help java if the default l&f was the native one, instead of metal.

I have written my own gui toolkits (one of the first things I did on my 286, in assembler).  Very basic though, mostly rendering nice window borders in good old 13h mode.  I have more recently written ones in opengl - but they just did what I needed, not exactly general-purpose.

Having found that kylix didin't give me the freedom I had hoped for in cross-compiles, I have recently turned to c++ toolkits.  FLTK was nice, except the layout and the fact that it was moving to a new revision, and some things would not survive.  wxWindows is big.  FOX seems nice, especially they way event IDs are assigned.

But basically the ease-of-use of the toolkit definitely comes from two things for me:
*procedures of objects can be used as event callbacks
*you don't mess around with layout managers, you just use the 'align' property on things
So basically, the reason that delphi is so easy to use is the language!  I am usually an apathist, but the first point above definitely adds a lot of housekeeping to c++ event-driven tools.

Sorry for the coredump

Nice
Tuesday, January 14, 2003

Once again, wxWindows.

And if you are fortunate enough to work in python, wxPython.

fool for python
Tuesday, January 14, 2003

I second the nomination of wxWindows and especially wxPython.

That said, in my experience all UI toolkits of corresponding levels of abstraction are roughly equivalent. My belief is that the problem with GUI toolkits is that they are too general -- the level of abstraction is too low. I think you need to build toolkits specific to your domain and encapsulate the low-level GUI toolkits with them to yield any significant productivity and consistency benefits.

Jeff Kotula
Tuesday, January 14, 2003

Just curious, any reason why Ilog Views never comes up in these discussions? I've used it for years with good success.

D Diggler
Tuesday, January 14, 2003

I should note that a problem that I have run into time and time again with GUI development is that lurking "black magic" issue of widget geometry -- getting stuff to stay where it's supposed to when windows are resized.  When people who know that I program GUIs in my spare time/as a hobby ask me about different toolkits, obviously seeking the one with the lowest learning curve and simplest tecniques, I tell them that GUI programming is inherently very complicated.  Good GUI programming, that is.

Think about any windowing environment for a moment:  Consider what a user can do with just a simple window.  Resizing, minimize, maximizing, closing.  Not to mention that these tasks must have "multiple entry points" (different ways to do the same thing), be it keyboard navigator, short-cut key-combinations, or the mouse.

Even trying to handle the mouse and at the same time considering keyboard input can be difficult.  It's all got to flow -- excellent GUIs just work because they're intuitive.  Hence, it's a difficult development process.

I've heard extensive complaints everywhere regarding layout managers.  I couldn't agree enough, but I debate their death (internally) near daily.  Organizing widgets on a canvas/dialog is an incredibly complex process.  Ensuring that each widget uses only their allotted space and the same proportion when the dialog expands can be a hairy task to program.  People want an easy solution to a difficult task.  Mr. Spolsky once said (paraphrasing a bit here) that complex programs are difficult to learn, no matter what.  Their interfaces can be improved, but a certain amount of learning is still required.  The same applies with GUI toolkits.

Finally, those who have never programmed GUIs haven't a clue how difficult it really is, regardless of how complicated they think GUI programming should be.  They forget when they use KDE/GNOME/OS X/Microsoft Windows how intiuitive and simple the interface is.  It just works.

Kevin Connor Arpe
Tuesday, January 14, 2003

If you want to keep up with Safari's development, then Hyatt's blog is one of the best places to do it.  He's involved in the open source end of Safari development and was the original main architect of XUL.

http://www.mozillazine.org/weblogs/hyatt

Simon Lucy
Wednesday, January 15, 2003

i am betting the farm on swt - mostly because i trust Erich Gamma.

Karel
Wednesday, January 15, 2003

Ilog views doesn't come up often because it's horribly expensive. You don't use it unless you have an extremely good reason because it costs so much.

And the extremely good reasons usually involve huge maps or charting applications, which are common in some industries, but not in general.

My vote goes to FLTK. Clean, simple, looks native on every platform even though it isn't using native widgets. Insanely fast.

Warning: Actually using it will get your project done better and faster but will disillusion you about modern OO. If you like to be away from your senses, stay away from FLTK.  It is NOT OO politically correct.

Ori Berger
Friday, January 17, 2003

*  Recent Topics

*  Fog Creek Home