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.
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.
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:
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.
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:
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."
'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!