All posts by mclasen

Why Wayland anyway ?

The Fedora Workstation working group decided this week that we’re not quite there yet for making the Wayland session the default in Fedora 24.

That is a bit of a disappointment for me, since we have worked very hard this cycle to close the gaps;  you can see the progress we’ve made here: primary selection, kinetic scrolling, drag-and-drop,  startup notification, pointer confinement have all landed this cycle. Not to mention countless smaller bug fixes and robustness improvements. But gaps are gaps, so we will take one more cycle to address them.


In any case, the Wayland session in Fedora 24 will be the best Wayland session we’ve ever had, and I really encourage everybody to try it out when F24 released.

Chances are that you won’t be able to tell the difference between the X and Wayland sessions. That is of course intentional – we’ve put a lot of effort into making sure that things work as well or better than before. But it is also a bit of a dilemma for advertising the Wayland work.

Why do it if everything is the same in the end ?


One reason is that Wayland is designed from the ground up to isolate clients from each other.  There is no shared coordinate space. Wayland clients cannot snoop on each others input or inject fake input events. They can’t draw on each others windows or cover up windows with fake replicas.

All of these things and many other exploits are possible for malicious X clients, because the X protocol wasn’t designed for untrusted clients.

This makes Wayland a much better choice of display protocol when sandboxing untrusted applications, like xdg-app does.


Another reason for using Wayland is that the Wayland protocol is a much better fit for a modern, compositing-based display system.

The X protocol contains many pieces that are simply no longer relevant today, like core fonts or core rendering. Modern toolkits and applications don’t use most of the protocol, but the obsolete parts have to stay if you want to claim to implement the X11 protocol.

Some problematic parts of the X protocol, such as grabs, are simply not present under Wayland.


A third reason for Wayland is that it will be a good basis to enable features that are hard to support under X, such as input transformation or smooth transitions between composited desktop and fullscreen clients.

Currently, we are still playing catch-up with the features of the traditional X session, so we haven’t really done much work on such new features yet. But as a small example,  we’ve already seen that it was relatively easy to add touchpad gesture support to Wayland, while X doesn’t have them yet.

There are more reasons for Wayland beyond these three, and you can read more about them e.g.  here or here.

Try it

Again, if you haven’t tried Wayland yet, the F24 release will be a great time to do so. Simply select the Wayland session (currently just called GNOME) in the session chooser on the login screen:


A Wayland status update

Peter argues that the question “Is Wayland ready yet?” is not the best question to ask.  Then maybe this is a better question:

Is GNOME on Wayland ready yet ?

It has been our goal for a while to get to a point where the Wayland port can be declared complete and ready to be enabled by default. We’ve come a long way since we started the porting effort in September 2013. In fact, we feel that we’re close enough that we can  aim for Wayland by default in Fedora 24.

But the last mile is always the longest, and there’s still a few steps to take before we’re there.  With this weeks releases of Wayland 1.9.91 and the GNOME 3.19.4 releases, we’ve taken a couple of the steps:

  • A lot of work has gone into fixing the positioning of dialogs, menus and other popups in applications. When it was first introduced, the GTK+ Wayland backend was using heuristics based on window type hints for this; now we are more strict about it: just setting a transient parent should be enough to ensure proper placement. We also try to handle dialogs without transient parent as good as we can.
  • Kinetic scrolling now works as well under Wayland as under X11 – or even better (at least as far as the protocol is involved; Wayland has explicit support for this while we are relying on driver-specific heuristics under X). The relevant Wayland protocol additions needed  for this are the axis stop events.
  • Drag-and-Drop under Wayland is now comparable to X11. This is the culmination of multiple efforts:  The Wayland protocol gained some necessary dnd events and supports actions now.  On the GTK+ side, we’ve moved drag icon creation and input handling to the GDK backends, where it can be done in a backend-specific manner.

Whats next ?

  • We should see initial support for Wacom  tablets in Wayland 1.10.
  • A replacement for the X11 primary selection (“middle click paste”) is also in the works; I hope we can reach agreement on the protocol soon.
  • Inside GTK+, menu positioning is being reworked in a similar way to DND: Pushing it down to GDK, where it can be implemented in a backend-specific manner. This is being driven by the team working on the Mir backend, but it will benefit Wayland just as well.

And here is a sneak preview of Wayland remoting that Jonas has been working on for a while:

CSS boxes in GTK+

In my last update, I talked about CSS nodes in GTK+, which are used to match theme style information to widgets, and to hold state that is needed to handle e.g. animations.

Today, I’ll focus on CSS boxes in GTK+. This is where we take size information from the theme, such as margins, padding, and minimum sizes, and apply them to the widget layout. The internal name we’ve chosen for the objects that encapsulate this information is gadgets . I’m well aware that we’re not exactly breaking new ground with this name, but the name isn’t really important (as none of this is currently exposed as public API). For the purpose of this post, you can think of gadgets simply as CSS boxes that make up widgets.

Lets start with a simple example widget, to see what this is about: a radio button (all of the screenshots here are showing GtkInspector, which is available in any GTK+ application, so you can easily do these experiments yourself).

We start by making the border of the widget’s box visible. The CSS snipplet shown below is using the element name radiobutton, which GtkRadioButton sets on its main CSS node, so this selector will match.

Radio button
This is how it looks. If you compare carefully with the earlier screenshot, you can see that GTK+ has made the widget bigger to make room for the 6 pixel border, while giving the same size as before to the content of the widget.

The CSS box model has more than just a border, it also allows for padding (inside the border) and margins (outside the border). In fact, the box model is much more complicated than this, and we’re only scraping the surface here. The GTK+ implementation of the box model handles most of the important parts, but doesn’t cover some things that don’t fit well in our situation.

So, lets add a margin and padding. To make this visible, we use some features of CSS background rendering: We specify two backgrounds (a solid blue one and a solid yellow one), and we let one of it be clipped to the size of the ‘content box’ (the area given to the widget content) and one to the size of the ‘padding box’ (which is the content area plus the padding around it).

This is how it looks. The margin is not very visible here, but you can clearly see the padding (yellow) and the content (blue). Note again how the widget has gotten larger to accommodate the padding and margin.

When I talked about CSS nodes, I mentioned how widgets can have extra nodes for their ‘components’. This extends to gadgets: each of the widgets components gets their own CSS box, with its own margin, padding, background and whatnot.

So, lets continue the coloring exercise by making our CSS snipplet match not just the radiobutton itself, but also the label and the indicator. Their CSS names are label and radio.

This is how it looks. Here, we can actually see the margin of the label have an effect: it causes the content area (in blue) to be bigger than it would otherwise be.

I hope by now it is obvious that this is giving a lot of expressive power to theme authors, who can use all of this to affect the layout and rendering of all the widgets and their components. And there are a lot of them:

The GtkInspector is a really useful tool for exploring what is possible with all of this. It gives easy access to both the CSS nodes of each widget:

…and to the CSS properties of each node, which is basically the outcome of matching the theme CSS information to the node tree, also taking into account inherited properties and other complications:

CSS properties

Whats next ? All of what I’ve shown here  is already available in GTK+ 3.19.5. We’ve made good progress on converting most widgets to use gadgets internally (‘progress’ is a bit of an understatement, it was a herculean effort, mainly by Benjamin Otte, Cosimo Cecchi and myself). But we are not done yet, so we will continue working on completing the conversion, and on documenting GTKs CSS capabilities better.

When that is done,  we can look at adding other interesting bits of the CSS spec, like calc() or border collapsing. CSS is a huge standard, and theme designers always ask for more.

A GTK+ update

You may have noticed that GTK+ master has a large number of changes in the CSS area. As some like to put it:

Oh NO! they’re breaking themes again!

Which is certainly one way to look at it, but I think it misses the point a little bit – since the effort is actually meant to make life easier for anybody who wants to change the appearance of GTK+ widgets.

What changes are we making ?

As a first step, we are introducing CSS nodes. A CSS node has an element name, a state and it can have style classes.  Each widget has one or more CSS nodes, and they are organized in a tree.  GTK+’s CSS machinery matches CSS selectors on this CSS node tree, and as a result, each node carries a full set of CSS properties.

The transition to CSS nodes is mostly done in GTK+ 3.19.2.

In a  second step, we will integrate CSS nodes into size allocation and rendering. This will bring consistent support for margins, padding and min-width/height for all widgets. This step is currently being prepared on the wip/otte/gadget branch.

None of this is exposed as API yet  (with some small exceptions, such as gtk_widget_path_iter_set_object_name ) . It needs more time to prove itself before we are ready to offer this as stable API.

Why are we doing this ?

There are a number of reasons for doing these changes. In no particular order,

  • Element names and style classes use by widgets for their CSS nodes (and their tree relationships) are now documented and provide a stable interface for themes and custom CSS.
  • Element names provide a level of abstraction over the direct use of type names, and will allow reuse of CSS. You wil be able to add a “check” node to your own widget, whereas you can’t call your own widget GtkCheckButton.
  • CSS nodes are permanent. This implies that they can carry state, e.g. for running CSS animations. They can also notify on state changes.Spinning
  • CSS nodes can explored and manipulated in GtkInspector.Inspect!
  • CSS nodes (in particular, the second phase) force us to clean up all the irregularities of the current widget rendering and move to a much more regular model, where every node draws a background and a  frame. Fancy Switches
  • Positional selectors such as :first-child now work everywhere, including parts of a widget. You can e.g., use :nth-child(even) to style notebook tabs.Fancy Tabs

What do you have to do ?

If you maintain a theme or custom CSS for an application,  update your selectors to use the documented element names and classes. The changes in Adwaita can serve as an example for the kind of changes that are needed.

If you use GTK+’s style machinery to render non-widget content (like mutter does for window decorations), use
gtk_widget_path_iter_set_object_name to make your widget paths look like the widgets they imitate.

If you have code that pokes colors out of GtkStyleContext to do your own rendering, you should really port to use the gtk_render APIs and custom CSS. If you want to keep your existing code working for now, you need to minimally fix gtk_style_context_get_color calls to use the correct state.  Ie. go from

gtk_style_context_get_color (context,


gtk_style_context_save (context);
gtk_style_context_set_state (contexts,
gtk_style_context_get_color (context,
          gtk_style_context_get_state (context),
gtk_style_context_restore (context);

What else is new ?

Support for help overlays Shortcuts got merged into GTK+ and is available in 3.19.1. We’ve gotten some feedback from early adopters and added a few more features, so things should be in good shape for wider adoption: please add it to your favorite GTK+ application, and update this page if you do so.

Wayland support is progressing. So far in 3.19, the focus has been on straightening out issues with window and popup sizing and positioning. Many of the remaining gaps will be fixed by integrating the protocols that have been under discussion for a while now: DND actions, tablet support, pointer lock,…  Jonas just revamped the Wayland protocol development process, which should lead to faster progress on this front. For more details, see Jonas’ mail.

Boston GNOME Summit update

The Boston GNOME summit this year is a small, focused hackfest.


The first day was filled with discussions and planning, with one of the central topics being how to make gnome-builder, xdg-app and gnome-continuous play well together. You can find notes and conclusions from this discussion here.


In the afternoon, Christian Hergert gave us an extensive demo of gnome-builder, with led to lots of discussion around future plans.

The second day was entirely devoted to hacking. Everybody got something done:

  • Cosimo added support for operating with elevated privileges to gvfs.  Here is a screencast showing this in action:

    The code for this is already in gvfs git.

  • Owen debugged and fixed various issues with gnome-builder under Wayland: mispositioned code completion popups and window stacking problems with the project chooser.
  • Christian asked everybody in the room what missing features kept them from using gnome-builder, and implemented several of the answers he got. One example is better indentation support in both emacs and vi modes.
  • Giovanni added support to the gnome-continuous build machinery to produce xdg-app bundles, and used it to produce an xdg-app for gnome-weather.
  • Myself, I took the shortcuts overlay implementation from gnome-builder and adapted it for GTK+.
    Shortctus overlay
    This code can be found in gtk+ git.

Thanks to everybody who participated so far. The Summit will continue tomorrow with more discussion and hopefully more productive hacking.

I’d also like to thank  Walter Bender and the MIT for hosting us, and Red Hat for sponsoring our breakfasts.

GNOME Boston Summit 2015

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 sometimes met in Montreal,  but we are back in Boston, at the MIT again, this year.

Early Turning


When: Saturday, October 10 — Monday, October 12
Where: MIT building E51, Cambridge, MA


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

  • gnome-builder and xdg-app
  • Application development (bundling, SDKs, sandboxing, portals…)
  • A visual refresh for GNOME

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

Hope to see many old and new faces there !

Guadec update

Here is a quick  tour of what you missed if you did not make it to my Guadec talk this year.

It was a bit different from my usual ‘state of the union’ or ‘GTK+ roadmap’ presentations. Instead, I showed a selection of tips and tricks, things you perhaps didn’t know yet how to do with GTK+.

Scrollbar steppers still exist

Guadec 1

Context menus on scrollbars

Guadec 2

Adding items to context menus and popovers
Guadec 3
Decorative overlays

Guadec 4

Custom spin buttonsGuadec 5
Discrete scales

Guadec 6

Markup in text views

Guadec 7

Filter models with extra columns

Guadec 9

The slides are here, and if you want to study the examples in more detail, they are all available in gtk3-demo in GTK+ master.

Some GTK+ sightings

I had a chance to demonstrate some GTK+ file chooser changes that have accumulated in the last year, so I thought I should share some of this material here.

File Chooser 1
All the screenshots here are of the testfilechooser application in GTK+ master as of today (some bugs were found and fixed in the process).


Search in the filechooser area that I have spent a bit of time on myself this cycle. We’ve improved the internals of the search implementation to match the sophistication of nautilus:

  • The current folder is already loaded, so we search through that data without any extra IO.
  • We ask tracker (or the platforms native indexer) for search results.
  • Locations that are not covered by that, we crawl ourselves, skipping remote locations to avoid excessive network traffic.

File Chooser 2
The easiest way to start a search is to just type a few characters – the search entry will appear and the search begin (you can of course also use the Search button in the header, or hit Ctrl-F to reveal the search bar.
File Chooser 6
If you type a character that looks like the beginning of a path (~, / or .), we bring up the location entry instead to let you enter a location.

Note that we show helpful hints in the subtitle in the header: if you are searching, we tell you where. If you are expected to enter a URL, we tell you that.
File Chooser 3For search results, we show a location column that helps to determine quickly where a result comes from – results are sorted so that results from the current folder come first.  Recent files also have a location column. The formatting of the modification time column has been improved, and it can optionally show times in addition to dates.

As you can also see here, the context menu in the file list (as well as the one in the sidebar) has been changed to a popover. The main motivation for this is that we can now trigger it with a long press on touch screens, which does not work well with a menu.

File Chooser 4If the search takes longer than a few moments, we show a spinner.  Hitting Escape will stop the search. Hitting it again will hide the search entry. Hitting it one more time will close the dialog.

File Chooser 5If the search comes up empty, we tell you about it.

File Chooser 7As I already mentioned, we don’t crawl remote locations (and tracker doesn’t index them either). But we still get results for the current folder. The footer below the list informs you about this fact.


The GtkPlacesSidebar is shared between nautilus and the file chooser since a few years ago. This cycle, it has been rewritten to use a GtkListBox instead of a GtkTreeView. This has a number of advantages: we can use real widgets for the rows, and things like the eject button are properly themeable and accessible.

File Chooser 8Another aspect that was improved in the sidebar is the drag-and-drop of files to create bookmarks. We now show a clear drop location and gray out all the rest.  Some of these changes are a direct result of user testing on nautilus that happened last year.


The sidebar used to list all your removable devices, remote mounts, as well as special items for ‘Enter Location’, etc. To prevent the list from getting too long, we have moved most of these to a new view, and just have a single “Other Locations” item in the sidebar to go there.
File Chooser 9As you can see, the places view also has enough room to offer ‘Connect to Server’ functionality.

File Chooser 10It has completion for known server locations.

File Chooser 11We show progress while connecting to a server.

File Chooser 12And after the connection succeeded, the location shows up under ‘Networks’ in the list, from where it can be unmounted again.

File Chooser 13The recent server locations are also available in a popover.

File Chooser 14If you don’t have any, we tell you so.

Save mode

All of the improvements so far apply to both Open mode and Save mode.

File Chooser 15The name entry in Save mode has been moved to the header (if we have one).

File Chooser 16For creating directories, we now use a popover instead of an embedded entry in the list.

File Chooser 18This lets us handle invalid names in a nicer way.


All of these changes will appear in GTK+ 3.18 in September. And we are not quite done yet – we may still get a modernized path bar this cycle, if everything works out.

The improvements that I have presented here are not all my work.  A lot of credit goes to Allan Day, Carlos Soriano, Georges Basile Stavracas Neto, and Arc Riley. Buy them a drink if you meet them!

Westcoast summit 2015

I am in San Francisco this week, for the second Westcoast Summit – this event was born last year, as a counterweight to the traditional GNOME summits that are happening every fall on the other coast.

Sunday was a really awesome day to arrive in San Francisco, my hotel is right around Market St, where this was going on:

Gay pride parade

Maybe this inspired my choice of texture when I  wrote this quick demo in the evening:

Pango power

Like last year, we are being hosted by the awesome people at Endless Mobile . And like last year, we are lucky to have the elementary team join us to work together and have a good time.

We started the day with a topic collection session:

Topic collectionSince everyone was interested in sandboxing and xdg-app, we started with Alex giving an overview of the current status and ideas around xdg-app. Endless has done an experimental build of their own runtime, and (almost) got it working in a day. After the general sandboxing discussion had run its course, Alex and I decided to patch evince to use the document portal.

GTK topicsIn the afternoon, we did a session on GTK+ topics, which produced a number of quick patches for issues that the elementary team has in their use of GTK+.

Later on, KentonVarda and Andy Lutomirsky of came by for a very useful exchange about our approaches to sandboxing.

kdbus vs cap'n protoI have put some notes of todays discussions here.

GNOME 3.16 sightings

As is my habit, I’ve taken some screenshots of new things that showed up in my smoketesting of the GNOME 3.15.90 release.Since we are entering feature freeze with the .90 release,  these pictures give some impression of whats in store for GNOME 3.16.

The GNOME shell theme has seen the first major refresh in a while. As part of this refresh, the theme has been rewritten in sass, and is now sharing much more code with the Adwaita GTK+ theme. Window decorations are now also sharing code between client-side and server-side.

New Shell ThemeA long-anticipated redesign of notifications has landed just-in-time for 3.15.90. This is a major change in the user interaction. Notifications are now appearing at the top of the screen. The message tray is gone, old notifications can now be found in the calendar popup.

New notificationsNew NotificationsSystem integration has been improved, e.g in the area of privacy. We now have  a privacy page in gnome-initial-setup, which offers you to opt out of geolocation and automatic bug reporting:

Privacy Outside of the initial setup, the same settings are also available in the control-center privacy panel.

The nautilus UI has received a lot of love. The ‘gear’ menu has been replaced by a popover, the list appearance is improved,
and file deletion can now be undone from a notification.

Improved NautilusNautilus ImprovementsOther applications have received a fresh look as well, for example evince and eog:

EvinceEye of GNOMEThere will also be a number of new applications, here are a few:

New applicationsYou can try GNOME 3.15.90, for example in Fedora 22 today. Or you can wait for GNOME 3.16, which will arrive on March 25.