GNOME Wayland porting – the endgame

Mosaic by Alison's Eyes.

Its been a while since I mentioned Wayland in this space – of course that doesn’t mean that work on GNOME Wayland support has stopped.

Quite the opposite, in fact. The GNOME 3.15.4 release that is due this week will close a number of the remaining gaps:

  • libinput 0.8 has been released, with most of the APIs that we need
  • Handling of input configuration has largely moved to mutter (the picture is not quite as clean as it could be, because we still need support for X configurations that do not use libinput in gnome-settings-daemon)
  • The corresponding control-center changes are about to land too
  • gnome-shell supports pointer barriers for the hot corner under Wayland as well
  • GTK+ popovers are using subsurfaces now, so they can extend beyond window boundaries
  • GTK+ prefers the Wayland backend over the X backend, if both are available

One gap that has not been closed yet is support for Wacom tablets. The required libinput changes and Wayland protocol extensions did not quite make it into libinput 0.8 – but much of the work has been done and will hopefully land before long.

The hero’s of this latest round of Wayland progress are Carlos Garnacho, Rui Matos, Jonas Ådahl, Jasper St. Pierre, Peter Hutterer and Hans de Goede, to name just a few.

I can hear you ask the question:

Thats all great, but when is it going to be done ?!

Clearly, we want to reach an endpoint where we can declare the Wayland port done and use it by default, in Fedora.  So, in order to not drag this out forever, we are aiming for the following:

  •  Use Wayland for the login screen in Fedora 22

Why ? The login screen is pretty self-contained and we don’t have to worry about application compatibility or support for exotic devices. And we will get Wayland to run on (almost) all systems this way, which should give a lot more exposure and help shake out lingering bugs and hardware issues.

  • Use the Wayland backends of the various toolkits (mainly GTK+, but also SDL and maybe Qt), if we are in a Wayland session.

Why ? This ensures that we get the maximum amount of exposure from the brave souls who are trying the Wayland session today, while not affecting the experience of everybody else who prefers the traditional X session.

As mentioned above, this change is happening for GTK+ in 3.15.4.

  • Make the Wayland session the default in rawhide, soon after we’ve branched for F22.

Why ?  If we want to have a shot at switching the default for Fedora 23, we need to do this anyway. And doing it sooner rather than later is the only logical choice.

+ +

A looking glass for GTK+

gnome-shell has  a nice integrated developer tool called “Looking glass”. To bring it up, simply enter “lg” into the command prompt:

Alt-F2 lg

This brings up a translucent overlay with an interactive JavaScript prompt. Among the nice things it offers are tab completion and an object picker.

Here is how it looks:

Looking glass If you haven’t tried it yet,  you really should.

Over the years, many people have asked,

“Can I use Looking glass to debug my GTK+ application ?”.

So far, the answer has always been no. But now, the always awesome Alex Larsson has stepped up and made essentially the same functionality available for the GTK+ Inspector:

Interactive InspectorAs you can see, it has an object picker, tab completion and a result history just like its ‘big brother’.  Alex made a little demo video for it.

To avoid a gjs dependency in GTK+ itself and the associated cyclic dependency issues, this is implemented as an extension in a loadable module.  The code currently lives on github, in Alex’ gjs-inspector repository.


GTK+ Inspector update

GTK+ Inspector is a debugging tool that is built directly into GTK+ and is available in every GTK+ application by using of the shortcuts Ctrl-Shift-d or Ctrl-Shift-i.

Since I last wrote about it, a number of things have changed, so it is time to give an update on the state of GtkInspector as of GTK+ 3.15.2.

The UI has been revamped a bit to make best use of the limited space in the inspector window.  Some of our newer widgets, such as GtkStackSwitcher, GtkSidebar and GtkSearchEntry, were helpful here:

InspectorInspectorInspectorThe object list has a new search implementation. It tries to deal better with search in a tree than the built-in search in GtkTreeView. Please try it and let me know what you think.

InspectorWe’ve added a new feature: object statistics. This is made possible by corresponding new functionality in GLib. To enable it, run your application with


InspectorThe inspector is now using a separate display connection.  This isolates it from many of the changes that you can make in it, such as CSS tweaks:

InspectorAfter 3.14, we have started to integrate OpenGL rendering into GTK+.  This is reflected in the inspector, which shows information about the OpenGL stack and offers some GL-related debug settings:

InspectorMore recently, I’ve spent my coding time helping to make glade support all of the new GTK+ widgets and features.  We are not quite there yet, but you can already use client-side decorations, GtkHeaderBar, GtkSearchBar, GtkStack, GtkStackSwitcher and GtkSidebar with glade from git master.

GladeI hope to add a few more new widgets to this list soon.  My personal goal for this effort is to use glade for all the ui files inside GTK+.

Weekend hack, updated

After a bit more debugging, and with some help from Jasper, here is the inspector debugging an X11 application while displaying under Wayland:

Wayland inspection!It also turns out that the GTK_INSPECTOR_DISPLAY environment variable is sufficient to make this work. I started this demo with

GTK_DEBUG=interactive GDK_BACKEND=x11,wayland \
GTK_INSPECTOR_DISPLAY=wayland-0 ./gtk3-demo

The reverse (application displaying under Wayland, inspector  on X) also works:

Reverse inspection



A weekend hack

I’ve been working on making GtkInspector use a different display connection. This helps isolating it from some of the changes you can trigger from inside the inspector UI. Then I thought, why not use a different backend ?!

We did enough work on GDK backend separation that it could almost work. But since we didn’t add API to actually connect to specific backends (users and applications get some control with GDK_BACKEND and gdk_set_allowed_backends()),  nobody has ever used multiple backends in the same process. And things that don’t get used don’t work.  So some fixes were necessary.

But now I have gtk3-demo running under X while the inspector is using the Broadway backend and shows up in the web browser:

To my knowledge this is the first time a GTK+ application is using multiple GDK backends at the same time.

Anticipating some questions:

  • What is this good for ?

Not that much, really. I consider it mostly a curiosity. It does prove that the GDK backend separation is (almost) working.

For most cases where this could be used with the inspector, it is probably preferable to move the inspector out of process and communicate via D-Bus. There are some people who are interested in this, so it may happen.

  • Can I use this in my application ?

No. I haven’t committed that hack that makes the inspector use a different backend . If we wanted to support this, we would need to add a real API to connect to a specific backend.

What I did commit though is the code that makes the inspector always use a separate display connection (with the same backend), so you get the better isolation that can be seen in the video.

  • Does this also work with Wayland ?

No. I first tried to make it work with Wayland+X, but the Wayland backend is more complicated than Broadway. I’m still getting crashes fairly soon. Broadway pretty much just worked, after a  round of fixes.

An early view of GTK+ 3.16

A number of new features have landed in GTK+ recently. These are now available in the 3.15.0 release. Here is a quick look at some of them.

Overlay scrolling

We’ve had long-standing feature requests to turn scrollbars into overlayed indicators, for touch systems. An implementation of this idea has been merged now. We show traditional scrollbars when a mouse is detected, otherwise we fade in narrow, translucent indicators. The indicators are rendered on top of the content and don’t take up extra space. When you move the pointer over the indicator, it turns into a full-width scrollbar that can be used as such.

Other new scrolling-related features are support for synchronized scrolling of multiple scrolled windows with a shared scrollbar (like in the meld side-by-side view), and an ::edge-overshot signal that is generated when the user ‘overshoots’ the scrolling at either end.

OpenGL support

This is another very old request – GtkGLExt and GtkGLArea have been around for more than a decade.  In 3.16, GTK+ will come with a GtkGLArea widget.

Alex’ commit message explains all the details, but the high-level summary is that we now render with OpenGL when we have to, and we can  fully control the stacking of pieces that are rendered with OpenGL or with cairo: You can have a translucent popup over a 3D scene, or mix buttons into your 3D views.

While it is nice to have a GLArea widget, the real purpose is to prepare GDK for Emmanuele’s scene graph work, GSK.

A Sidebar widget

Ikey Doherty contributed the GtkSidebar widget. It is a nice and clean widget to turn the pages of a GtkStack.

IPP Printing

The GTK+ print dialog can now handle IPP printers which don’t provide a PPD to describe their capabilities.

Pure CSS theming

For the last few years, we’ve implemented more and more CSS functionality in the GTK+ style code. In 3.14, we were able to turn Adwaita into a pure CSS theme. Since CSS has clear semantics that don’t include ‘call out to arbitrary drawing code’, we are not loading and using theme engines anymore.

We’ve landed this change early in 3.15 to give theme authors enough time to convert their themes to CSS.

More to come

With these features, we are about halfway through our plans for 3.16. You can look at the GTK+ roadmap to see what else we hope to achieve in the next few months.

GNOME Summit wrap-up

Day 3

The last day of the Summit was a hacking-focused day.

In one corner,  Rob Taylor was bringing up Linux and GNOME on an Arm tablet. Next to him, Javier Jardon was working on a local gnome-continuous instance . Michael Cantanzaro and Robert Schroll were working on D-Bus communication to let geary use Webkit2. Christan Hergert was adding editor preferences to gnome-builder and reviewed design ideas with Ryan Lerch. I spent most of the day teaching glade about new widgets in GTK+. I also merged OpenGL support for GTK+.

Overall, a quite productive day.

Thanks again to the sponsors


and to Walter Bender and the MIT for hosting us.


GNOME Summit update

The Boston summit is well underway, time for some update on what is happening.

Day 1

BreakfastAround 20 people got together Saturday morning and, after bagels and coffee got together in a room and collected topics that everybody was interested in working on. With Christian in attendance, gnome-builder was high on the list, but OSTree and gnome-continuous also showed up several times on the list.

Our first session was discussing issues of application writers with GTK+. Examples that were mentioned are the headerbar child order changing between 3.10 and 3.12, and icon sizes changing for some icons between 3.12 and 3.14 . We haven’t come to any great conclusions as to what we can do here, other than being careful about changes. GTK+ has a README file that gets updated with release notes for each major release, but it is not very visible. I will make an effort to draw attention to such potentially problematic changes earlier in the cycle.

Another kind of problem that was pointed out is that  the old way of doing action-based menus with GtkAction and GtkUIBuilder has been deprecated, but the ‘new way’ with GAction, GMenuModel and GtkApplication has not really been fully developed yet; at least, there is not great documentation for migrating from the old to the new, or for just starting from scratch with the new way. The HowDoI‘s for this are a start, but not sufficient.


After the morning session, Richard Stallman came by and spent an hour with us, discussing the history of free software, current challenges, and how GNOME fits into this larger picture from his perspective.

In the afternoon, we had a long session discussion ‘future apps’, which is hard to summarize. It revolved around runtimes, sdks, bundling, pros and cons of btrfs vs ostree, portals,  how to get apps ported to it, what to do about qt apps. This thread covers a lot of the same ground.

I managed to land GType statistics support in GObject and GtkInspector.

Day 2

Over breakfast, we talked about the best way to communicate with a webkit webview process, which somehow led us to kdbus. Takeaways from this discussion:

  • We (GNOME release team) should push for getting all users of webkit ported to webkit2 this cycle
  • We should create a document that explains what application and service authors and distributors need to do when porting to kdbus

Day 2

After breakfast, we started out with a live demo of gnome-builder, which looks really promising. Christian is reusing a lot of existing things, from gtksourceview over devhelp to gitg and glade. But having a polished, unified application bringing it all together makes a real difference!

As this session was winding down, I started testing a GNOME 3.14.0 Wayland session with the goal of recording as many of the smaller (and larger) issues as possible in bugs.  The result so far can be found here. While I reported a long list of Wayland issues today,  all is not bad. It was no problem at all to write this blog post in a Wayland session!

Thanks to Red Hat and Codethink,  who are sponsoring this event


GNOME Boston Summit 2014

The Boston Summit is a 3-day hackfest for GNOME developers and contributors, that we traditionally hold over the Columbus day weekend.

In recent years, we’ve met in Montreal,  but for 2014,  we are back in Boston, at the MIT.

Early Turning


When:    Saturday, October 11 — Monday, October 13
Where:  MIT building E51, Cambridge, MA


There’s plenty of topics we can discuss. Here are some I would be interested in working on:

  • Application development (bundling, SDKs, sandboxing, kdbus, …)
  • Wayland (porting leftovers, possibilities for the future, …)
  • Privacy

If you are interested, please let us know you’re coming.

Hope to see many old and new faces there !

GNOME 3.14 impressions

As part of the release preparation, I’ve done some smoketesting of GNOME 3.14 – looking good! As I usually do, I’ve taken some screenshots while testing things, to share some impressions. Screenshot from 2014-09-24 07:50:18-smallScreenshot from 2014-09-24 09:25:44-smallScreenshot from 2014-09-24 07:30:42-smallNow back to final release preparations.