GUI Programming: Philosophy and Interfaces

CS 321 Lecture, Dr. Lawlor, 2006/04/17

Philosophy

So you need some input from a user. There are at least three ways to do it.

You can cout a little "Please enter your whatever" message, and then cin the data. This is two lines of code, which is nice. But you're also demanding the whatever at that moment--in other words, the program is in control of the interaction. If the user enters something, then the program goes on to demand something else. The user can't tell where they are in the process of running the program, can't go back to fix stuff; he's not in control.

Or you can bring up a dialog box with a text box, "OK" button, and "Cancel" button. This might be one line of code if you've set things up right. You're still demanding some input from the user at a particular time, but you're giving them an escape route with the "Cancel" button. What do you do if the user cancels? Hopefully something sensible, but you the programmer do have to think about this.

Finally, you can rethink the application--how about providing a big dialog box that includes everything the program will need to get something done. Then the user can enter the stuff in any order, not just the order you bring up the dialog boxes in. The user can see at a glance everything they'll need to run the program. This is actually way better, since the user feels like they're in control. The essence of the Graphical User Interface (GUI) philosophy is "The user is always in control."

Programming Interfaces

There are lots of programming interfaces that let you build GUIs. Here are some of the major ones.

Name	Language	Example	Good Things	Bad Things
HTML	Forms/CGI	Netrun	Super easy--browser does all the hard work	Tough to distribute. Limited interaction (e.g., no custom menus) since browser limits what is possible
XHTML	JavaScript	Google Maps	Interaction is possible	Hideous to write. JavaScript poorly implemented and nonportable.
Windows API	C	Notepad	Standard Windows look and feel	Code runs only on Windows. Simple things can require lots of code.
MacOS Carbon	C	Any Mac Program	Standard Mac look and feel	Code only runs on MacOS. Simple things can require lots of code.
MacOS Cocoa	Objective C	New MacOS X Programs	Interface builder lets you drag-and-drop a GUI	Code only runs on MacOS X. Must write in funky objective C.
X	C	xfig	Runs perfectly across a network.	No code builtin for menus, buttons, scrollbars--you've got to build everything yourself.
GTK	C	GIMP	Nice-looking. Runs (sort of) on all known machines: X, MacOS, Windows	Interface changes pretty fast. Need big library for Windows applications.
Qt	C++	KDE Apps	Nice-looking. Runs well on all known machines: X, MacOS, Windows. Excellent documentation.	Expensive for commercial use. Free version is only for noncommercial use on Linux.
AWT	Java	Applets	Real interaction, compiled language. Even compiled code is portable.	Need Java runtime. Tough to put on floppy disk. Can't call old C code. Simple things can require lots of code.
Swing	Java	??	Cool antialiased rendering.	Need latest Java runtime. Tough to mix with AWT.
Win32.NET	.NET	??	Double-clickable .exe file. Easy on Windows.	GUI calls are Windows-specific.
Tk	Tcl	??	Very terse--dialogs are really easy to write.	Tied to Tcl scripting language, which changes pretty quickly. Need to embed Tcl in application.