New features and new widgets in GTK+

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Improved widgets and controls

Clasen styled his talk ("GTK+ can do this?") as a walkthrough of little-known options and tricks available in the toolkit. Many of the examples involve recent additions to the toolkit, though some of them predate the current GTK+ development cycle. There were enough tips and secrets, he said, that he hoped everyone in the audience would be able to say that they had learned of something new.

First, he addressed scrollbar widgets. Recent changes to GTK+ scrollbars include support for kinetic scrolling and GTK+'s frame-synchronization protocol (which ensures that scrolling appears smooth). But there are little-known features available as well. Some users and developers have grumbled that GTK3 scrollbars lacked the up/down "stepper" buttons of earlier versions; Clasen explained that these steppers can now be added with a simple CSS rule:

    .scrollbar {
      -GtkScrollbar-has-forward-stepper: true;
      -GtkScrollbar-has-secondary-backward-stepper: true
      }

Similarly, GTK3 scrollbars now support moving through a window by page-length increments with shift-clicks, and enabling smooth scrolling via right click.

Clasen's second topic was output-only windows. Previously, input events that happened to land in a GTK+ overlay (say, a tooltip or transient popover) would get passed to the application's top-level parent window, which is not always what the developer desired. In many instances, the correct behavior is to pass the event to a window (say, a toolbar) somewhere in the middle of the hierarchy, and GTK3 now supports this with a GtkOverlay::pass-through property. He also noted that the pass-through functionality can be used to draw decorative overlays.

Clasen then showed how developers can add their own content to the popovers that appear when the user triggers a touch-selection event. The signal is called GtkTextView::populate-popup and, in addition to adding custom options for touch-selection popovers, it can be exploited to customize the right-click context menu of any GTK+ widget. That even includes scrollbar widgets, he noted. "I don't know why you would and I'm not sure it's a good idea," he added, "but if you need to do it, you can."

Arguably more practical than context menus on a scrollbar were two enhancements to GTK+ controls that Clasen demonstrated. One is that spinbuttons—which traditionally allow the user to enter a numeric value by clicking + or - buttons, can now be customized. The range of acceptable values has always been configurable, but now the labels can be, too. He showed an example where the underlying values on a "month" spinbutton were restricted to the interval 1–12, but where each value was presented as the corresponding month name. This was followed by examples that displayed the underlying numeric values as clock times and as hexadecimal digits.

The other enhanced control is the slider, where the user moves a handle across a scale to set the value. But a slider may not correspond to a variable that can accept continuous input. In previous versions of GTK+, it was possible to add tick marks to the scale so that the user could see discrete values along the slider, but it was still possible for the user to leave the slider in between the markers. This has now been fixed; developers can mark a slider as accepting a set of discrete values, and the handle will "stick" to the nearest acceptable value as the user moves it along the scale. To make the feature work, developers will also need to set the round-digits property on the scale, so that only discrete steps are returned:

    <object class=”GtkScale”>
      <property name=”round-digits”>0</property>
    </object>

There are also two new text-related features in GTK+, Clasen said. First, text-view widgets now support Pango markup, which allows the text to be styled or colored and allows various font features (like spacing or character variants) to be activated. Second, any Pango text can be turned into a Cairo path using pango_cairo_layout_path(), which allows it to then be manipulated with a wide variety of Cairo tools and transformations. This should be done with great care, he said, particularly since the Pango-to-Cairo conversion is not very efficient.

For each feature he discussed, Clasen showed example code as well as a live demo using the gtk3-demo application. For those who missed the talk (and until a video of the session is published) his slides [PDF] are available online, as is a blog post showing screenshots of many of the demonstrated features.

New widgets

There were, as one might expect, several other talks that addressed new or ongoing work within GTK+. Emmanuelle Bassi gave an update on his work creating the spiritual successor to the Clutter toolkit, GTK+ Scene Graph Kit (GSK), although he said the code was not yet ready to be released for mass consumption. Several of the LibreOffice talks referenced Pranav Kant's Google Summer of Code (GSoC) project with GNOME Documents, in which he made progress toward a new GTK+ widget for accessing a LibreOffice document from any GTK+ program.

Another GsoC intern, Timm Bäder, presented a lightning talk about his project: a GTK+ widget named GtkImageView. The widget's purpose, he said, is to provide developers with a convenient way to show images to users—in particular, large images that are too big for GtkImage. That existing widget is optimized for icons, button images, and similar small content. It starts to break down when loading large images, however.

The new widget can load any image type supported by gdk-pixbuf, and it loads content asynchronously. It also implements scaling and rotation functions, and it supports GTK+'s internal scale-factor setting, so it works on high-DPI displays. Bäder is still at work on the widget, he said, and may add more features in the future, such as touch-gesture support.

The last new GTK+ widget discussed at the event was Matthew Waters's gtkgst, a widget for displaying the output of a GStreamer pipeline in a GTK+ application. Obviously both GTK+ and GStreamer are mature projects at this point, so Waters started off his talk by explaining the difficulties of working with both of them in a single application.

The main difficulty is that GStreamer pipelines are inherently complex beasts: they have to handle a wide range of video codecs, color spaces, scaling factors, and effects when showing a video—and even more variables when generating or editing video. Historically, embedding a video in a GTK+ window has added even more complications, requiring the application to push key and mouse events into GStreamer, to notify the GStreamer video sink of resize events, and to perform careful setup that is highly dependent on the details of the windowing system.

Waters's new widget is an attempt to wrap such details into a more convenient package. The code lives in GStreamer's "plugins-bad" package for now (although, when stable, it will likely move to "plugins-good"). An application developer only needs to set up the GStreamer video pipeline they require and connect it to the gtkgst sink; that will provide a GTK+ widget that can be placed anywhere in the widget hierarchy. That allows for clean separation between the GStreamer and GTK+ sides of the code, which should simplify development and troubleshooting. In response to an audience question, he said that gtkgst renders video far more smoothly than Clutter.

The current implementation renders the video into a GtkDrawingArea, but Waters is in the process of implementing it using OpenGL. That would enable hardware acceleration and multithreading, he said, although there are a number of challenges to overcome before it is ready for general usage. Both GTK+ and GStreamer have supported OpenGL for some time, but hooking them up to one another is not quite trivial. His code works on X11 and Wayland so far, and he hopes to add Mac OS X and Windows support in the future.

GTK+ is approaching 20 years of age, and while there are certainly longer continuously running projects in free software, it can be easy for a project to stop evolving to ever-changing circumstances and developer expectations. Nevertheless, the toolkit seems to be resilient and is still adapting to support new uses with each passing release.

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