Development
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.
![[Matthias Clasen]](https://static.lwn.net/images/2014/07-guadec-clasen-sm.jpg "Matthias Clasen")
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.]
Brief items
Quotes of the week
LibreOffice 4.3 released
The LibreOffice 4.3 release is available. New features include improved document interoperability, better comment management, "intuitive spreadsheet handling," 3D models in Impress, and more. See the release notes for details. "LibreOffice 4.3 also supports 'monster' paragraphs exceeding 65,000 characters (an example of an 11 years old bug solved thanks to the modernization of the OOo source code, which is an exclusive function of LibreOffice)."
GDB 7.8 released
Version 7.8 of the GDB debugger is out. New features include support for scripting in the Guile language, better Python scripting, support for debugging on little-endian PowerPC64 systems, handling of C99 variable-length arrays, and more.
Newsletters and articles
Development newsletters from the past week
- What's cooking in git.git (July 24)
- What's cooking in git.git (July 29)
- LLVM Weekly (July 29)
- OCaml Weekly News (July 28)
- OpenStack Community Weekly Newsletter (July 25)
- Perl Weekly (July 28)
- PostgreSQL Weekly News (July 27)
- Python Weekly (July 24)
- The R Journal (June)
- Ruby Weekly (July 24)
- Tor Weekly News (July 30)
- Wikimedia Tech News (July 28)
Kügler: Plasma’s Road to Wayland
On his blog, Sebastian Kügler looks at what's left to be done for KDE's Plasma desktop to support Wayland. He discusses why the project cares about Wayland, what it means to support Wayland, the current status, the strategy for further work, and how interested folks can get involved. "One of the important topics which we have (kind of) excluded from Plasma’s recent 5.0 release is support for Wayland. The reason is that much of the work that has gone into renovating our graphics stack was also needed in preparation for Wayland support in Plasma. In order to support Wayland systems properly, we needed to lift the software stack to Qt5, make X11 dependencies in our underlying libraries, Frameworks 5 optional. This part is pretty much done. We now need to ready support for non-X11 systems in our workspace components, the window manager and compositor, and the workspace shell."
Interview with Nathan Willis, GUADEC Keynote Speaker (GNOME News)
LWN editor Nathan Willis is giving a keynote talk at the upcoming GUADEC (GNOME Users and Developers European Conference) and was interviewed by GNOME News. Willis's talk is titled "Should We Teach The Robot To Kill" and will look at free software and the automotive industry. "And, finally, my ultimate goal would be to persuade some people that the free-software community can — and should — take up the challenge and view the car as a first-rate environment where free software belongs. Because there will naturally be lots of little gaps where the different corporate projects don’t quite have every angle covered. But we don’t have to wait for other giant companies to come along and finish the job. We can get involved now, and if we do, then the next generation of automotive software will be stronger for it, both in terms of features and in terms of free-software ideals." GUADEC is being held in Strasbourg, France July 26–August 1.
Akademy 2014 Keynotes: Sascha Meinrath and Cornelius Schumacher
KDE.News looks at Akademy keynote speakers Sascha Meinrath and Cornelius Schumacher. "Akademy 2014 will kick off on September 6 in Brno, Czech Republic; our keynote speakers will be opening the first two days. Continuing a tradition, the first keynote speaker is from outside the KDE community, while the second is somebody you all know. On Saturday, Sascha Meinrath will speak about the dangerous waters he sees our society sailing into, and what is being done to help us steer clear of the cliffs. Outgoing KDE e.V. Board President, Cornelius Schumacher, will open Sunday's sessions with a talk about what it is to be KDE and why it matters."
Page editor: Nathan Willis
Next page:
Announcements>>