Easy and Cross-Platform GUI development FLOSS tools with Unix/Linux support

David A. Wheeler

2009-02-24

There are lots of different ways to build programs with graphical user interfaces (GUIs). Here are a few of the "more major" ways that are (1) Free-libre / Open Source Software (FLOSS), (2) have Unix/Linux support, and (3) are either (a) exceptionally easy and/or (b) cross-platform.

There's no way I can summarize all the info on the net, and there's much I've had to omit. But there's so much out there that I ended up writing notes on the options I found... and here they are. I've divided into the easy/trivial (single-question) case, the full cross-platform toolkits, and the "in between" options.

Easy/Trivial

Are your GUI needs are very simple/trivial, i.e., you just need to get a single question answered via a GUI? If so, there are some some simple dialog programs that simply ask the question using a GUI, get the answer, and return it. That makes them really easy to put into a script, though this approach can't support more complex approaches (which generally require event-driven development approaches). The two most common options on Unix/Linux are:

There are some other "dialog" programs too, including the text-only dialog. Zenity "works" in its non-native environment, but not as pretty in the "wrong" one. ( kdialog can "hang" in the "wrong" environment). There really should be a single dialog program, with a single interface, that calls out to the "right" program based on the active environment. Perhaps it should be added to XdgUtils, just like xdg-open and so on (call it "xdg-dialog"). This has been discussed by the Portland group in 2006, and by Dan Kegel in 2008 via the Linux Foundation mailing list. The Perl UI-Dialog does this, but it requires perl and perl programming (instead of a simple command-line interface).

easygui does the same kind of thing with Python.

Cross-Platform Toolkits

If those approaches are inadequate, you'll be doing more work, at which point you'll probably be interested in cross-platform GUI toolkits (so you don't have to re-do the work). There are many options, which can be grouped on the basic toolkit or language, as shown below. Once you pick a toolkit/language, there are often lots of choices related to it... with the result that choosing can get complicated.

Note: Many people recommend using GUI user interface designers (aka GUI builders/designer) that generate a bunch of data files; these files describe forms and what function/method to call given various events. Then, you create a very small program that loads and implements them. This makes it much easier to change the user interface, as well as being able to support more programming languages. (Glade does this for GTK+, for example).

Here are some of the options available, with the first few being especially relevant:

  1. wxWidgets: This is the cross-platform GUI library I hear the most about. This supports Unix/Linux (using GTK+), MS Windows, and MacOS X. wxWidgets maximally uses the "native" platform widgets, so the generated applications "look" right to end-users. You can also access platform-specific capabilities when you want to. It's implemented in C++, but there are bindings to other languages. In particular, the wxPython interface lets you use Python (which is much simpler to use); if you use wxPython, read the wxPython Style Guide. For wxWidgets UI building, there's wxFormBuilder; and wxGlade. Both can generate "XRC" files (an XML format that is a standard part of wxWidgets) that can be later loaded to generate a form. has some limitations on its XRC support. wxGlade was inspired by Glade, but doesn't share any code with Glade. This page provides "HelloWorld" for Python + wxFormBuilder + wxWidgets. Here's more about wxPython + XRC (XML Resource). Here's a simple sample Python program that loads the GUI defined using XML. Many people, after looking around, end up with wxWidgets + wxPython. If you want a full IDE that supports wxPython, PythonCard and spe do that (and there are yummable Fedora packages). PythonCard says that it is "for you if you want to develop graphical applications quickly and easily with a minimum of effort and coding." There's also Boa Constructor, which supports wxPython, but there's no Fedora package.
  2. GTK+: GTK+ is the basis of GNOME, so GTK+ applications look 100% at home on GNOME (the default UI of Fedora and Ubuntu). GTK+ applications work on KDE but can look odd. GTK+ applications also run on Windows and MacOS. Historically, GTK+ didn't use many native widgets, but that seems to have changed; also, MacOS X originally required X (making it very odd-looking), but again, this seems to have changed. It's built with C, but of course there are lots of GTK+ language bindings (including PyGTK for Python). In the GTK+ world, Libglade to GtkBuilder F.A.Q. explains that libglade is getting replaced by gtkbuilder. Basically, libglade's dynamic loading capability is getting moved into GTK+ itself as GtkBuilder, so GTK+ will have a standard format for loading GUI builder files... and some cleanup was done for the transition. Glade will eventually generate gtkbuilder XML directly, but in the meantime, you need to run a converter program (not a big deal). Here's a GTK+ and Glade tutorial. Gazpacho is an alternative to Glade. GTK-server offers a stream-oriented interface to the GTK+ libraries, which could be very useful (especially for shell scripts).
  3. Qt: Qt is a toolkit that works across many platforms, and is the basis of KDE. Qt has had licensing issues in the far past, and more recently was a dual license (GPL or proprietary, the latter for a fee). It's to be released under the LGPL, which I applaud. Qt is implemented in C++ with several non-standard extensions (so isn't really a standard language at all); I really dislike this implementation approach, but many others are fine with it. Historically, Qt emulated the native look (leading to discrepancies), but more recent versions of Qt tend to use native widgets. "Qt Jambi" is an interface to Qt for Java.
  4. Java: Java has some extra decisions. For Java-native interfaces you can choose Swing (reference GUI for J2SE) or Standard Widget Toolkit (SWT), developed by IBM as part of Eclipse. There's also the older AWT, though that's much less capable. Here is developer.com's comparison of SWT and Swing, and IBM developerWorks' article on SWT, Swing, and AWT. SWT tries to be close to the native platform; Swing tries to abstract away from it. AWT is much older; it's a simple toolkit with limited capabilities, but it does have the advantage of stability. Thinlet (GPLv3) is a GUI toolkit for J2SE.
  5. Mozilla's XULRunner, which is used by Firefox and Thunderbird (among others). XULRunner separates the run-time infrastructure of programs like Firefox and Thunderbird so you can build your own apps with them. Firefox and Thunderbird are clear demonstrations that this works; anyone who has Firefox already has XULRunner installed. Here's how to get started with XULRunner.
  6. Tk (often combined with the language Tcl). Many years ago, this is what you'd probably use to create a cross-platform GUI app. Tk still works, and it's a relatively easy toolkit to use. However, Tk hasn't gotten as much support recently. It doesn't use many native widgets, so resulting applications don't look "native" on any platform; indeed, they tend to look ugly and dated. There are bindings to Tk to lots of languages (including Python). Though it's not required, Tk is often used with Tcl. Tcl is a remarkably simple language (and thus its implementation is tiny), but that has its downsides; it parses each command at a time (so errors aren't noticed ahead of time), yet it re-parses them each time (making it slow). Richard Stallman famously wrote "Why you should not use Tcl", kicking off a Tcl war.
  7. Fast Light Toolkit (FLTK) is a small cross-platform C++ GUI toolkit for Unix/LInux, MS Windows, and MacOS X. It's small enough that the library is often included statically in an executable, so if that's important, that's a big plus. On the negative side, it is completely its own toolkit, so resulting applications don't look native on any platform (unless only FLTK is used).
  8. Fox toolkit (LGPL). This does not wrap native toolkits.
  9. GNUstep (LGPL). This is based on the Cocoa API (Formerly OpenStep) originally created by NeXT (now Apple), it has a large library of reusable components. GNUstep Renaissance is a development framework, emphasizing human-editable XML. Applications run on Linux, Unix, Windows, MacOS.
  10. HTML. Just a reminder - perhaps you should be writing a web application instead. Then you don't have to deal with this at all :-). XForms is a newer approach for HTML forms, which might be useful.

There are lots of data sources on the topic. Here's a painfully comprehensive list of GUI toolkits. Here's a GUI toolkit, framework page, emphasizing Free software. Choose your GUI toolkit has another list. Christopher Browne has a list of X development tools.

In-Between

For many circumstances, you'd like to create an input form that people can fill in, and then when they accept the form something happens. (all the values get returned, or a command line program is run with various option flags set). Ideally, you'd fill in the information or use a GUI form builder to create an XML form. Then, an "executor" would run the form, and when 'go' is pressed, run the command. The existing GUI desigers/builders already provide much of this functionality.

Surprisingly, I don't see much that does this exactly. A close one is Kommander, which appears to only work with KDE (corrections wanted) and thus not really cross-platform. It uses the Qt toolkit.

EveryGUI gets close to this too; it's based on the GTK+ toolkit. "EveryGui is an attempt at being a GTK+ Graphical User Interface for 'Everything' (involving command line programs) on UNIX systems. This goal is achieved by providing two powerful applications:

  1. Chameleon, which is a dynamic GUI for virtually any tool or OS command. It loads config files of tools which are chosen from a list, and dynamically creates widgets reperesenting the tools' options. Not only does it execute the commands, but it can save a batch of commands into a shell script for later/repeated use.
  2. And Designer, which is a visual environment for creating/editing config files that determine Chameleon's different behaviours for each tool/command. Designer feels like a cross between QT Designer and Glade, but requires no coding at all to get the functionality working (that's Chameleon's job to do it automagically)."

    Command line GUI project at complex may get there, though there's no release (since October 2006!) and it may be Windows-only if it ever is. "Before the Command Line Gui application can present you the input fields for a command line executable it needs to know all about that executable and its command line arguments. Details about the command line arguments of the executable in question are stored in an xml file. This file contains information about the location of the executable, the command line arguments that can be used and binding directions how to represent them in the Gui. You can put one or more executables in one xml file and have multiple xml files to choose from. For now the xml file has to be created by hand."

    EasyGui is a Python library built on top of Tk that lets you create a form, have the user fill it out, and then return. It support "quick and dirty GUI features (for) GUI capabilities that don't require any knowledge of Tkinter, frames, widgets, callbacks or lambda... all GUI interactions are invoked by simple function calls. EasyGUI is different from other GUIs in that EasyGUI is NOT event-driven. It allows you to program in a traditional linear fashion, and to put up dialogs for simple input and output when you need to." There are videos showing how to do this.

    In Perl, the perl-Getopt-GUI-Long uses an interesting approach - it's a getopt()-like library that automatically creates a (simple) GUI for setting options. Automatically creating a GUI from Python's getopt was also briefly discussed, and other people have had this idea too.

    Here's a discussion about making a GUI pipe.

    Such a tool could proabably built quickly from other tools, particularly by generating XML and then writing a simple standard "driver" program that ran the XML. Ideally, it'd use a really small/simple scripting language, and would work without a lot of bigger programs, so that you could quickly install the driver on many different systems.

    Estron (formerly DWI) is a platform for making GUI applications using SQL eaiser. Based on GTK+ and Glade. "Estron is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade."

    Other Stuff

    'Easy' GUI Toolkits by Peter Centgraf has a nice discussion about approaches for creating GUIs, pointing out major themes (edit visually, simplify the model, and use a high-level language).

    Hotwire is an "object-oriented hypershell", and tough to explain without using it. This Linux.com article explains Hotwire through examples. The Hotwire site explains that it is a (command) shell "designed for systems programming (files, processes), and thus it is in the same conceptual category of software as the Unix shell+terminal and Windows PowerShell.. The goal of the Hotwire project though is to create a better systems programming shell than both Unix and PowerShell. We call it a hyper-shell because Hotwire blends the concepts of a systems-oriented shell with a modern graphical user interface display. It takes advantage of your desktop environment rather than being a text box. It retains some advantageous attributes of a shell such as keyboard command orientation, interactivity, completion, and scripting."

    Appcelerator (Apache 2.0 license) lets you build native applications for both mobile apps and desktop apps.

    Hope that helps!