I got some good replies to my last post. Unfortunately, the somewhat archaic software hosting this site doesn't have any way of tracking replies and responses, so for the most part I have to work from memory. I think I need to give the author of the software a kick in the pants...

The answer to the question "what is the best approach to writing GUI apps?" depends a lot on a few basic assumptions. I didn't state those at all clearly in my last post, so I'll try to do that now.

The first big question is whether you're trying for something adequate and usable, or for a world-class app that is in no important ways inferior to professional apps designed natively for the platform. This question is especially important when trying to target multiple platforms from the same codebase.

There are lots of good approaches to "adequate" apps, including the venerable Tk (especially with the Tile improvements), wx, qt, or either of the two viable Java toolkits. But it is difficult or impossible to achieve the fit and polish of a real native app. Examples:

• Seamless integration with the platform's input methods for non-English text.
• Screen reading and other accessibility items.
• On Mac, having the dock work as expected (drop items to it, badging).
• Cut and paste with rich content.

It's not just about being able to draw widgets that look just like native; that's important, but the tip of the iceberg.

If my goal was an "adequate" app, the generic cross-platform frameworks would be appealing. But for the moment, that's not mostly what I'm thinking about.

Another very important axis is the choice of programming language for the app. If your language rocks at strings but sucks at everything else (like Tcl), then obviously having the GUI toolkit treat everything as strings is a good thing (hence Tk). But if your language has really good dynamic dispatch for objects (like Objective-C), then you clearly want your UI events to map directly to object methods, rather than having to filter through big switch statements on split strings. What you really want is Cocoa (or maybe GnuStep).

And for me, the valid assumption is that I'm writing primarily in C, but am also very interested in prototyping in Python. Unfortunately, C is neither really good at dealing with strings (you have to do handstands to get the memory management right) or objects. Other things, like exceptions, are also painful. So the constraints of trying for a reasonably good API for C is likely to warp the design to be not very good in other languages.

So I don't hold out all that much hope for the convergence of GUI toolkits, at least any time soon. Different frameworks for different goals.

A funny, well-written review

Tor found this. It made me laugh hard enough not to be considered appropriate in the presence of royalty.