zentara I am taking a good look at Gtk2. At first glance it seems much more friendly to my learning style and project scoping needs than does Tk. The documentation coupled with the tutorial give me most of what I need for a quick assessment of capabilities.

Comparing Tk and Gtk2 really does make one aware of how much our approach to GUIs has changed in the last 20 years. One of the first APIs I ever designed and had to train programmers to use was an event driven TUI (text origined user interface) written in 1989 just before Windows 3.0 came out. Even on Microsoft systems, we were still using DOS back in those days. Since then I've worked intimately with an old, old version of Motif, both C and C++ versions of the Microsoft GUI API, the NeXT API, various Database GUIs (Access, Oracle, Progress), and most recently the Java Swing and AWT APIs. Until now I've never had a chance to step back and see the changes.

The biggest difference I see isn't the prettiness of the widgets but the way we work with them. Back in the late 80's and early 90's widget dynamics were, for the most part, a two way dialog between the user and the widget. For the programmer a widget was basically a pretty picture painter and data box. Programmable events were usually very very low level (mouse and key strokes) or very high level (respond to this command). The Tk documentation reflects this tradition. Documentation is very heavy on lists of properties, but light on events associated with each widget.

In the last 20 years widgets have developed a host of logical events somewhere between key strokes and commands. This was not easy to do. For example, many of the early APIs didn't always do a good job distinguishing between the different reasons for leaving a field. I seem to recall that the Progress database GUI had a bug where attempting to leave a field with an invalid value to press a help button caused a dialog box telling you to go back to the field and fix it. No matter what you did when you closed the dialog box, you were forced back into the field with the bad value. Hotel California in an edit box. (You can checkout any time you like, But you can never leave!)

Today, the situation is much improved. In a modern GUI API, a typical edit widget has well defined events to tell us when it gets keyboard focus, when it is about to set a value, when it has already set a value, when it is loosing focus. There are different events for leaving a widget and leaving the group that contains it, and leaving a dialog box as a whole. At each of these points we can stop the process, or do something special and continue it. If the widget is a list box, we will have events that tell us when an item is selected, deselected, moved up or down in the list box order, edited, moused-over on an icon, and so on and so forth.

The result is a three way dialog between user, widget, and programmer. The Gtk2 tutorial reflects this newer way of working with widgets. In addition to an over view of events as a whole, each widget article lists its main events along with the properties that can be set. It isn't just about pictures and data any more.

Pobucks that widget demo is awesome. It is about as close as anything to a survey of the capabilities. And yet... I still don't know what events I need to intercept to edit a list of items. Ah well... am I the only person on the planet that wants a widget where I can add items to a list rather than just pick items from a list? Grrr.

Limbic~Region thank-you so much for the empathy. Yours and my blood have mixed on that wall.

Best, beth