GTK++, stability, and the uncluttered future

The GTK+ application toolkit is most closely associated with the GNOME desktop, but it is used by a variety of non-GNOME environments and applications as well. It even runs on non-Linux operating systems. That level of diversity has at times fostered an unease about the nature and direction of GTK+: is it a GNOME-only technology, or it is a system-neutral tool with GNOME as its largest consumer? The subject came up in several talks at GUADEC 2013, mingled in with other discussions of the toolkit's immediate and long-term direction.

GTK+ 3.10

Matthias Clasen delivered a talk on the new features that are set to debut in GTK+ 3.10 later this year, and he did so with an unusual approach. Rather than build a deck of slides outlining the new widgets and properties of the 3.10 release—slides which would live in isolation from the canonical developer's documentation—he wrote a tutorial in the GNOME documentation and provided code samples in the GTK+ source repository.

The tutorial walked through the process of creating a "GNOME 3–style" application using several of the newer classes, widgets, and support frameworks. Clasen's example application was a straightforward text-file viewer (essentially it could open files and count the number of lines in each), but it integrates with GNOME 3's session bus, newer APIs (such as the global "App Menu"), GSettings settings framework, animated transition effects, and more.

Many of the widgets shown in the tutorial are new for 3.10, and up until now have only been seen by users in previews of the new "core" GNOME applications, like Clocks, Maps, or Web. These new applications tend to be design-driven utilities, focusing on presenting information (usually just one type of information) simply, without much use for the hierarchical menus and grids of buttons one might see in a complex editor.

But the stripped-down design approach has given rise to several new user interface widgets, such as GtkHeaderBar, the tall menubar featuring centered items that is visible in all of the new core applications. Also new is the strip of toggle-buttons that lets the user switch between documents and views. These toggle-buttons are a GtkStackSwitcher, which is akin to the document tabs common in older applications. The switcher is bound to a GtkStack, which is a container widget that can hold multiple child widgets, but shows only one at a time. In his example, Clasen showed how to open multiple files, each as a child of the GtkStack. The GtkStack–GtkStackSwitcher pair is not all that different than the tabbed GtkNotebook of earlier GTK+ releases, but it has far fewer properties to manage, and it can take advantage of new animated transitions when switching between children. Clasen showed sliding and crossfading transitions, and commented that they were made possible by Owen Taylor's work on frame synchronization.

He also showed the new GtkSearchBar widget, which implements a pre-fabricated search tool that drops out of the GtkHeaderBar, thus making adding search functionality to an application simpler (and more unified across the spectrum of GTK+ applications). He also added a sidebar to his example, essentially just to show off the other two new widgets, GtkRevealer and GtkListBox. GtkRevealer is the animated container that slides (or fades) in to show the sidebar, while GtkListBox is the sortable list container widget.

The talk was not all widgets, though; Clasen also demonstrated how the GSettings preferences system works, setting font parameters for his example application, then illustrating how they could be changed from within the UI of the application itself, or with the gsettings command-line tool. He also showed how glib-compile-resources can be used to bundle application resources (such as icons and auxiliary files) into the binary, and how GtkBuilder templates can simplify the creation of user interfaces. All in all, the application he created from scratch was a simple one, but it was well-integrated with GNOME's latest features and, he said, only about 500 lines of C in total, with an additional 200 lines (of XML) describing the user interface.

What about Bob?

Clasen's talk brought application developers up to speed on the latest additions to GTK+ itself, while two other sessions looked further out, to the 3.12 development cycle and beyond. Emmanuele Bassi is the maintainer of the Clutter toolkit, which is used in conjunction with GTK+ by a few key projects, most notably GNOME Shell and the Totem video player. His session dealt with the recurring suggestions he hears from users and developers: either what "Clutter 2.0" should do, or that Clutter should be merged into GTK+. "This talk is less of a presentation, and more of an intervention" he said.

Clutter uses OpenGL or OpenGL ES to render a scene graph; interface elements are "actors" on the application's ClutterStage. Actors can be easily (even implicitly) animated, with full hardware acceleration. Clutter has been able to embed GTK+ widgets, and GTK+ applications have been able to embed Clutter stages, for several years. Nevertheless, as Bassi explained, Clutter was never meant to be a generic toolkit, and he is not even sure there should ever be a Clutter 2.0.

Originally, he said, Clutter was designed as the toolkit for a full-screen media center application; it got adapted for other purposes over its seven-year history, but most people who have used it have ended up writing their own widget toolkit on top of Clutter itself. That should tell you that it isn't done right, he said.

Today Clutter is really only used by GNOME Shell, he said. But being "the Shell toolkit" is not a great position to be in, since GNOME Shell moves so quickly and "plays fast and loose with the APIs." There are two other Clutter users in GNOME, he added, but they use it for specific reasons. Totem uses Clutter to display GStreamer videos only "because putting a video on screen with GStreamer is such a pain"—but that really just means that GStreamer needs to get its act together. The virtual machine manager Boxes also uses Clutter, to do animation of widgets.

So when it comes to Clutter's future, Bassi is not too interested in creating a Clutter 2.0, because the current series already implements all of the scene graph and animation features he wants it to (and the things it doesn't do yet would require breaking the API). But the most common alternative proposal—merging Clutter into GTK+—is not all that appealing to him either. As he pointed out, other applications have implemented their own widget toolkits on top of Clutter with little in the way of widespread success, using libraries to "paper over" Clutter's problems. If you want to do another, he said, "be my guest." At the same time, compositors like GNOME Shell's Mutter have to "strip out a bunch of stuff" like the layout engine. In addition, GTK+ already has its own layout, event handling, and several other pieces that are duplicated in Clutter. Offering both systems to developers would send a decidedly mixed message.

Ultimately, though, Bassi does think that GTK+ needs to start adding a scene graph library, which is the piece of Clutter that everyone seems to want. But, he said, there is no reason he needs to call it Clutter. "We can call it Bob," he suggested. But Bob needs design work before it can be implemented, and he had several suggestions to make. It should have some constraints, such as being confined to GDK ("which sucks, but is still better than Qt" he commented) as the backend. It should avoid input and event handling, which do not belong in the scene graph. It should be 2D offscreen surfaces blended in 3D space—using OpenGL "since that's all we've got." It should not have a top-level actor (the ClutterStage), since that was an implementation decision made for purely historical reasons. And it must not introduce API breaks.

Considering those constraints separately, Bassi said, the scene graph in Clutter is actually okay. Porting it over would require some changes, but is possible. He has already started laying the groundwork, he said, since the April 2013 GTK+ hackfest. He implemented a GtkSceneGraph-3.0 library in GTK+, which passed its initial tests but was not really doing anything. He also implemented the first steps of adding OpenGL support to GDK: creating a GLContext and passing it down to Cairo. There is much more to come, of course; several other core GNOME developers had questions about Bassi's proposal, including how it would impact scrolling, input events, custom widgets, and GTK+ support on older GPU hardware. Bassi explains a bit more on the GNOME wiki, but the project is certain to remain a hot topic for some time to come.

Whose toolkit is it anyway?

Last but definitely not least, Benjamin Otte presented a session on the long-term direction of GTK+, in particular the technical features it needs to add and the all-important question of how it defines its scope. That is, what kind of toolkit is GTK+ going to be? How will it differ from Qt, HTML5, and all of the other toolkits?

On the technical front, he cited two features which are repeatedly requested by developers: the Clutter-based scene graph based on Bassi's work mentioned above, and gesture support. The scene graph is important because GTK+'s current drawing functions make it difficult to tell what element the cursor is over at any moment. Making each GTK+ widget a Clutter-based actor would make that determination trivial, and provide other features like making widgets CSS-themable. Gesture support involves touch detection and gesture recognition itself (i.e., defining a directional "swipe" that can be bound to an action); Otte noted that GTK+'s existing input support is essentially just XInput.

The bigger part of the talk was spent examining what Otte called the "practical" questions: defining what GTK+ is meant to be and what it is not. His points, he stated at the outset, do not represent what he personally likes, but are the result of many conversations with others. They already form the de-facto guidance for GTK+ development, he said; he was simply putting them out there.

The first point is OS and backend support: which OSes will GTK+ support, and how well? The answer is that GTK+ is primarily intended to be used on the GNOME desktop, using X11 as the backend. Obviously it is transitioning to Wayland while supporting X11, which has forced developers to work in a more abstract manner than they might have otherwise. That makes this a good time for any interested parties to write their own backends (say, for Android or for something experimental). But the fact remains that in the absence of new developers, the project will make sure that features work right on X11 and Wayland, and will do its best to support them on other platforms. For example, Taylor's frame synchronization is written native to X11, and the timer mechanism can only be approximated on Mac OS X, but it should work well enough.

Similarly, he continued, GTK+ is targeting laptops as the device form factor, with other form factors (such as phones, or development boards without FPUs) often requiring some level of compromise. Desktops are "laptop-like," he said, particularly when it comes to CPU power and screen size. Laptops also dictate that "keyboard and mouse" are the target input devices. Touchscreen support will hopefully arrive in the future, he said, but that is as touchscreens become more common on laptops.

These decisions lead into the bigger question of whether GTK+ seeks to be its own platform or to be a neutral, "integrated" toolkit. For example, he said, should a GTK+ app running on KDE be expected to look like a native KDE app? His answer was that GTK+ must focus on being the toolkit of the GNOME platform first, and tackle integration second. The project has tried to keep cross-platform compatibility, he said. For example, the same menus will work in GNOME, Unity, and KDE, but the primary target platform is GNOME.

Finally, he said, people ask whether GTK+ is focused on creating "small apps" or "large applications," and his answer is "small apps." In other words, GTK+ widgets are designed to make it easy and fast to write small apps for GNOME: apps like Clocks, rather than GIMP or Inkscape. The reality of it is, he said, that large applications like GIMP, Inkscape, Firefox, and LibreOffice typically write large amounts of custom widgets to suit their particular needs. If GTK+ tried to write a "docking toolbar" widget, the odds are that GIMP developers would complain that it did not meet their needs, Inkscape developers would complain that it did not meet their needs either, and no one else would use it at all.

An audience member asked what Otte's definitions of "small" and "large" are, to which he replied that it is obviously a spectrum and not a bright line. As a general rule, he said, if the most time-consuming part of porting an application to a different platform is porting all of the dialog boxes, then it probably qualifies as "large." Then again, he added, this is primarily a matter of developer time: if a bunch of new volunteers showed up this year wanting to extend GTK+ to improve the PiTiVi video editor, then a year from now GTK+ would probably have all sorts of timeline widgets.

People often ask why they should port an application from GTK2 to GTK3, Otte said. His answer historically was that GTK3 is awesome and everyone should port, but he said he has begun to doubt that. The truth is that GTK2 is stable and unchanging, even boring—but that is what some projects need. He cited one project that targets RHEL5 as its platform, which ships a very old version of GTK2. Creating a GTK3 port would just cost them time, he said. The real reason someone should port to GTK3 today, he concluded, is to take advantage of the new features that integrate the application with GNOME 3—but doing so means committing to keeping up with GNOME 3's pace of change, which is intentionally bold in introducing new features.

Eventually, he said, he hopes that GTK+ will reach a point where the bold experiments are done. This will be after the scene graph and gesture support, but it is hard to say when it will be. Afterward, however, Otte hopes to make a GTK4 major release, removing all of the deprecated APIs, and settling on a GTK2-like stable and unchanging platform. The project is not there yet, he said, and notably it will keep trying to be bold and add new things until application developers "throw enough rocks" to convince them to stop. The rapidly-changing nature of GTK3 is a headache for many developers, he said, but it has to be balanced with those same developers' requests for new features like gesture recognition and Clutter integration.

Otte's statements that GTK+ was a "GNOME first" project were frequently a topic for debate at the rest of GUADEC. One audience member even asked him during his talk whether this stance left out other major GTK+-based projects like LXDE and Xfce. Otte replied that he was not trying to keep those projects out; rather, since GNOME developers do the majority of the GTK+ coding, their decisions push GTK+ in their direction. If other projects want to influence GTK+, he said, they need to "participate in GTK+ somehow," at the very least by engaging with the development team to communicate what the projects want.

"What is GTK+" is an ongoing question, which is true of most free software projects (particularly of libraries). There is no simple answer, of course, but the frank discussion has benefits of its own, for the project and for GTK+ developers. As the 3.10 releases of GTK+ and GNOME approach, at least both projects are still assessing how what they do can prove useful to other application developers.

[The author wishes to thank the GNOME Foundation for assistance with travel to GUADEC 2013.]