The Importance of the GUI in Cross Platform Development

The fragmentation of development energy into too many GUI toolkits is one of the most serious problems facing the Linux community today.

Tcl/Tk is a popular solution for GUI programs on X, and it has been ported to Windows and Macintosh. Tcl is a simple scripting language, and Tk is a widget set that can be used with Tcl to create interfaces. I do not find the Tcl language particularly appealing, and Tk is tied fairly closely to Tcl, although some effort is being made to more cleanly separate the two. There are bindings for other languages such as Scheme, Python and Perl. However, using Tk from C or C++ is reportedly somewhat awkward. I have noticed that Tk applications tend to be rather sluggish, but I don't know if this is because of Tcl or the Tk widgets themselves.

One other disadvantage of Tk is that the look and feel (sort of like Motif) is the same across all platforms, so the interface may look out of place to Windows and Macintosh users, although I have heard attempts to remedy this are underway.

Despite the disadvantages, Tk does have a lot of full featured widgets. I understand it is possible to create interfaces relatively quickly. It is certainly worth considering.


A programming language and portable virtual machine and a collection of libraries (called packages), these three technologies together are now apparently called “Java”. Java has received a lot of hype in the past couple of years. While the virtual machine and the rigidly specified language provide some minor portability features, the most interesting part of Java to me is the cross-platform GUI API. The original GUI API, known as the AWT, is a simple wrapper library that has nothing in particular going for it. However, Sun is now creating a new set of pure Java widgets, known as “Swing”, which seems to be well designed and fully featured. With all the hype and momentum behind Java, Swing has the potential to become one of the best GUI libraries available.

The disadvantage, of course, is that Swing (part of the JFC, Java Foundation Classes) is about as far from language neutral as possible. If you want to use Swing, you must take the Java language and the other Java libraries with it, generally abandoning your perfectly good existing libraries.

My biggest complaint about Java is just that I feel like I'm not really developing for Linux anymore; instead I'm developing for the “Java platform”. I get fatigued wading through all the hype and nonsense that the trendiness of Java engenders, and I miss the refreshing honesty of the Linux world. I'm also not totally comfortable with the fact that Sun controls the direction of Java. If we in the free software world don't like something about it, there's ultimately nothing we can do, despite Sun's assurances of openness. There are free implementations of the Java language and virtual machine, but at the rate Sun is creating APIs, free implementations of the libraries trail far behind.

I would like to see the ability to use the high quality Java JFC library and still integrate with the direction of the free software world. Perhaps some cooperation with the GNOME project to allow Java applications using Swing to comply with the GNOME application policies would be helpful. Then people could write GNOME applications in Java, even if they used JFC instead of GTK.


Qt is a commercial C++ toolkit available for X and Windows. It is not free in the monetary sense, costing about $2200 for both the X and Windows version. There is a special exception: if you write a free program for X you can use it for free. However, this free program is not really free in the GNU sense, or in the Debian Free Software Guidelines sense, which causes many people (including me) to be wary of basing projects on Qt.

Technically, Qt is reasonably well designed. Particularly notable is its flexible “signals and slots” method of event handling. Qt is being used in the KDE desktop project.


Win32 is the API for Windows NT and Windows 95. Because of its popularity, it is also being used as a cross-platform API. Microsoft sells an expensive package that will allow you to compile Win32 programs for Macintosh. There are also expensive Win32 libraries available for various flavors of UNIX. The Wine (windows emulator) project is attempting to create a free implementation of Win32 on top of X, along with a binary emulator to run Windows executables directly.

The problem with using Win32 for Wine is that Wine is not mature enough yet, and because the API is controlled by Microsoft, the free implementation will always lag behind Microsoft's own. Win32 is, obviously, a Windows-centric API, and it is not a particularly good API, so the prospect of using it to develop Linux GUI programs is not very exciting. However, if you already have a lot of Win32 code written, or are already very experienced with the API, it may be worth considering investigating one of the implementations.