What's new in GTK+ 3 dialogs

The GTK+ toolkit is in a constant state of development, although the pace of the changes has slowed quite a bit since the release of GNOME 3.0, when big changes were introduced. Today, each new GTK+ and GNOME release cycle tends to bring smaller, more incremental updates—some of which are subtle enough that they might go unnoticed by users and application developers alike. At GUADEC 2014 in Strasbourg, France, Matthias Clasen presented an update on the most recent improvements to GTK+, most of which can be found in the appearance and behavior of dialog boxes.

GNOME includes a suite of "built-in" dialogs that provide application developers with pre-made dialog boxes for several common tasks. Clasen showed off the improvements to four of them: the color selection dialog, the font chooser, the file chooser, and the "about" dialog. In general, these dialogs now put more content directly in front of the user as active, selectable elements, rather than requiring widgets and controls. For example, the color picker is no longer dominated by a set of slider controls for red, green, and blue channel values; instead the main element is a grid of selectable color swatches. Similarly, the font chooser presents a scrollable list of sample text, rather than a triptych of separate list boxes for font-family names, sizes, and styles.

The "about" dialog was perhaps the worst offender of usability principles in the old incarnation; it included stock buttons that popped up "sub-dialogs." These have been replaced with simple tabs, so application authors can include (for example) a list of contributor names as credits. The print dialog is the only built-in dialog that was not part of Clasen's presentation; he said that mock-ups were available on the GNOME wiki showing the changes, but that they were not yet implemented.

For developers, the more important dialog changes to learn about are the updates to how custom dialog boxes are constructed. The GNOME Human Interface Guidelines (HIG) book breaks dialogs down into three categories based on their function, Clasen said. There are message dialogs, which present information (such as an error report) or ask a question, there are action dialogs, which ask the user to make a choice, and there are presentation dialogs, which are more free-form and are generally used to present information that does not fit into the application's static context. Action dialogs are recognizable because they have two or more buttons on them, one of which is highlighted as the default choice. Presentation dialogs are recognizable for having the same controls (close, minimize, etc.) as a "normal" window.

The most consistent change in the custom dialogs, he said, is that they have been migrated to use GTK+ headerbars: window title bars that include not just the window name, but also buttons. Headerbars are intended to save vertical space and make buttons easier to find, but they are only supported in GNOME Shell at the moment. The standard GNOME applications have migrated to headerbars already; when the dialog boxes started migrating during the last release cycle, Clasen said he heard a lot of "rumbling" from developers who use GTK+ in other desktop environments. The trouble is that in those other environments, the desktop's window manager might also draw its own title bar, thus making the dialog doubly decorated.

The good news is that GTK+ now automatically detects which window manager it is running under, and adapts appropriately. In GNOME Shell, he said, the headerbars are used, but in other environments, no title bar is not drawn by GTK+ and all included buttons are automatically moved to their correct locations. He demonstrated this by switching to Xfce and back to GNOME Shell with a demo application running. The work is not entirely finished, he reported; the elementary desktop has special requirements of its own, wanting the rounded shape's on GNOME Shell's headerbars, but with the buttons moved to the bottom of the dialog box.

Other changes to the custom dialogs include the removal of stock images for "error," "message," "question," and similar generic categories. These images did not really serve any function except to tell you that there was a stock dialog on screen, he said. Additionally, he said, the action dialog is a new category introduced with GTK+3. In GTK+2, developers just put buttons on a dialog if they wanted to. The action dialog allows a simple way to present choices and verification dialogs in a consistent manner.

Migration

With his discussion of the basic changes to dialogs completed, Clasen then looked at some case studies for how an application developer might port their code from GTK+2 to GTK+3. For example, there is a way to restore the stock icons that were removed from message dialogs—for the benefit of developers who are concerned about introducing UI changes to their applications. The gtk-message-dialog-set-image() function can be used to put the stock image back in its old location, although eventually the function will be removed.

A more complex problem is how to create a dialog that presents a lot of text to the user—where "a lot" roughly means enough that multiple lines are required, even in a full-width window. In GTK+2, fitting such multi-line text into a dialog without causing it to stretch out over the entire screen was handled automatically because there was a hardcoded 640-by-480 default dialog size in the toolkit. GTK+3 does away with that default, to be more flexible. But developers can recreate it by defining a default dialog size in their own application code, Clasen said. They must take care to also set the dialog's minimum line length, though, using gtk-label-set-width-chars. Ultimately the easiest solution is to use a GTK+3 message dialog, he added, but this upgrade path was available, too.

Finally, Clasen looked at how to try out GTK+ headerbars. There is, of course, a flag to set (GTK_DIALOG_USE_HEADERBAR), but that alone is not quite the entire story. At the moment, the Glade UI builder for GNOME does not support headerbars, so some manual editing is required on the .ui file that is Glade's output. Developers need to add an element that sets the use-header-var property to one in their GtkDialog objects. Fortunately, this manual editing of the .ui file works in Glade templates, so not too much additional work should be required.

One audience member asked why there was a lag between a feature landing in GTK+ and support for it landing in Glade. Clasen responded that it is difficult to implement support for the new feature in Glade while the feature is still undergoing development. Emanuelle Bassi also commented that Glade, unfortunately, has just two part-time contributors at the moment. Clasen agreed, and told the audience that if anyone wanted to make a big impact on GTK+, volunteering to help out with Glade development would be an excellent choice—perhaps even more effective than contributing to GTK+ itself.

Last but not least, even though it was not the subject of his talk, Clasen's presentation made heavy use of another recent GTK+ addition: GTKInspector. Adapted from an earlier standalone tool, GTKInspector is a built-in GTK+ application explorer; users can open it with a keystroke or by passing an environment variable on the command line. It mimics the "web console" feature in Firefox, Clasen said: any GTK+ element can be investigated along with all of its properties, and the entire application's GTK+ widget tree can be seen. If the usage of the tool in Clasen's talk was not evidence of its power on its own, eagle-eyed GUADEC attendees probably noticed it on display in a number of other sessions, most notably Benjamin Otte's presentation on CSS support in GTK+. As with many of the other incremental updates to GTK+, the inspector tool is arguably a small change, but one that will have a positive impact for quite some time.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2014.]