All posts by mclasen

Wayland porting continues

Mosaic by Alison's Eyes.

It has been a while since I’ve last reported progress on the ongoing port of GNOME to Wayland. Giovanni did an unbelievable amount of groundwork in mutter and gnome-shell during the 3.10 cycle. After that all landed, we took a bit of a break to catch our breath, while GNOME 3.10 matured to 3.10.1 and now 3.10.2.

Now it is time to pick up the effort again, and sort out what remains to be done for full Wayland support in GNOME 3.12. From a high-level perspective:

  • Wayland sessions in gdm
  • Keyboard handling (layout switching, on-screen keyboard, accessibility, input methods, shortcuts,…)
  • Pointer handling (pointer barriers, accessibility, better touchpad support,…)
  • Window management (lots of details)
  • Application support (gstreamer, clutter-gtk,…)
  • Application testing and porting

If this sounds like a lot of work, that is because it is a lot of work.

Thankfully, quite a few of these things are already in progress or at least being planned. For example, a new xdg_shell interface has been discussed for a while to handle window management. For keyboard handling, Rui has started by implementing layout switching for weston. A new library for sharing input handling code is beginning to take shape too. clutter-gtk support needs subsurfaces, for which Jonas has patches here.

But there is still a lot to do, and any help is welcome. If you feel adventurous and want to learn about Wayland, please join us – there are tasks in all levels of difficulty here, you don’t need to be a über-X-hacker to find something useful to do.

More details on the Wayland port, including the list of open tasks, can be found on the wiki.

Smooth progress

Alex did a nice writeup of the GTK+ 3 drawing model, explaining how the frame clock lets you do smooth animations with a tick callback. To show the difference that this makes, I did a quick exercise this weekend: I converted the activity mode in GtkProgressBar to use a tick callback. You can see the necessary changes here.

In activity mode, the progressbar displays a ‘bouncing’ block, to indicate activitity, instead of showing definitive progress. Applications manually trigger the bouncing by calling gtk_progress_bar_pulse() periodically. What we have done so far is to just move the block a fixed amount, taking care to change the direction whenever we hit the edge of the bar. This works, but gives a jumpy effect that is not very smooth.  Applications can influence the speed of the block by calling pulse() more or less frequently.

Since I did not want to change the public API of GtkProgressBar, and I still want to let applications influence the speed of the block, I use the time interval between the most recent pulse() calls to estimate of the desired speed, and move the block the appropriate amount in a tick callback that gets called for each frame. Note that the tick callback has to explicitly request a repaint, by calling gtk_widget_queue_draw().

Here is how this looks in practice:

GTK+ 3 on Windows

gtk-logo-48There have recently been some stories about applications switching away from GTK+ due to portability concerns. Therefore, I’m really happy to announce that we now have official GTK+ 3 builds for Windows. Currently, the supported version is 3.6.4. You can find these on the very informative download page:

The driving force behind this was Manuel Bachmann (Tarnyko on irc). Thanks, Manuel !

We also have a page with instructions for GTK+ on OS X.

Montreal summit

Here is a belated update from the GNOME summit that is happening this weekend in Montreal.

Montreal at night

Jasper and I drove up from Boston Saturday morning, so we arrived a little late. Most people were already there, and there was a well-filled whiteboard with plans:

Ryan making plans

The weekend has been pretty productive so far.

We’ve talked about adding support for notifications to GApplication. This will allow us to get rid of the libnotify dependency and make our application API a bit more complete. This has been discussed for a while, on the gtk-devel list and at the last GTK+ hackfest and again at Guadec. Today, we agreed to merge the GIO patch (see bug  688492). It uses a GIO extension point to allow different implementations; currently we have implementations based on the spec and on a new, nicer D-Bus API). It should be possible to write implementations for the native Windows and OS X notification APIs too. Help with this would be much appreciated !

Another session I have participated in is a design review and planning session for GNOME Boxes. We’ve done a pass over the UI and took notes about many smaller and larger issues, but we’ve also talked about new features such as multi-monitor support, import/export, snapshots and cloning, and how the user experience for these could look.

Getting ready to partyThe small piece of code I got to write this weekend is to bring back meaningful accessible names for icon-only buttons; these used to come from the GtkStock system, and we didn’t have them for buttons that are constructed from icon names or GIcons. This is an unfortunate regression in the otherwise good out-of-the-box accessibility support of GTK+, so it is nice to have it back. The fix will appear in GTK+ 3.10.2.

Another related session I participated in is a review of the Wayland port from an accessibility perspective with the GNOME accessibility team; we’ve identified a number of issues that we will have to address to keep our a11y support at the same level (such as giving the screen reader a way to identify the surface under the pointer).

GNOME / Wayland in Fedora

I’ve been itching to write this post for a while.

With the GNOME 3.10.0 release, we actually built mutter-wayland in Fedora 20, and enabled the Wayland compositor in the gnome-shell package. For a while, we were missing the xwayland support from our X server package, so gnome-shell-wayland would not actually run. As of today, with the very latest builds of xorg-x11-server, xorg-x11-drv-intel and mutter-wayland, it is actually possible to test GNOME under Wayland in Fedora 20. Note that these updates may not have made it into the updates-testing repository by the time this post appears.

Much of the credit for getting us this far goes to Giovanni Campagna, who writes about it here.

Of course, this is an early tech preview, so you should not expect wonders. The planning page for the Wayland porting effort lists the known limitations and regressions. The more noticeable ones are:

  • The generic Wayland driver is still under package review, so for now you can only try this with Intel graphics.
  • You can’t currently launch a Wayland session from gdm. To start a session, switch to a vt and run
    gnome-session --session gnome-wayland
  • Global keybindings don’t work
  • The touchpad support is very limited
  • The hot corner and pointer barriers don’t work
  • clutter-gtk applications (totem, cheese, …) display their content in the wrong place

But you can try it out, and that is huge milestone.

In the near future, we’ll focus on stability fixes and on addressing the most serious regressions. Our goal for the next cycle is to complete the port to the point where you can use it day-to-day without noticing it. There is still a lot of things that need to be done to get there, we are tracking this effort here. We are also going to discuss the Wayland port at the GNOME Montréal Summit in 10 days, feel free to drop by there if you are interested.

Help is very much appreciated.

One thing that would be helpful and can be done by anybody without expert knowledge of X or Wayland is to try applications and see which ones are working and which ones have issues. To try a GTK+ application with the Wayland backend, use

GDK_BACKEND=wayland <your-test-app>

This will only have an effect for applications using GTK+ 3, of course. There is no Wayland support for GTK+ 2. Applications using GTK+ 2 should transparently use the X server that is provided by xwayland.


F20 alpha is not new enough for this. You need to run yum upgrade after installing the alpha, and then install the three aforementioned builds for GNOME / Wayland to work.

GNOME 3.10

I’ve just flipped the switch to release GNOME 3.10. As always, the last few days before the release were pretty hectic, trying to hunt down blocker bugs. A fun bug showed up on Monday, when all of a sudden, gnome-continuous started to show serious rendering issues on the login screen – its awesome rollback capability allowed Colin to quickly determine that the breakage had appeared within the last 24 hours. Only, there was no suspicious-looking commits anywhere to be seen. After considerable head-scratching and debugging, Ray found that the culprit was the change of the gdm version number from 3.9.90 to 3.10.0. It turned out that gnome-shell was using a simple string comparsion with the string ‘3.5.90’ to determine if the gdm version was new enough. That worked great all the way from GNOME 3.6 through 3.9 …

With that bug out of the way, and another client-side-decoration related rendering glitch tracked down by Giovanni and Owen on the day of the release, GNOME 3.10.0 is now officially available. You can find the release notes here. This time, we even managed to have a live image available at the time of the release, you can find it here.

I think it has turned out to be a pretty nice relase. As always, I’ve taken a couple of screenshots during smoke testing:

System SettingsThe new system status menu and the new display panel.

Login screenThe new system status menu on the login screen.

ApplicationsSome existing and new applications.

More applicationsSome up and coming applications to look forward to in 3.12.

GNOME 3.10 sightings

I’ve not been very good about posting updates on this GNOME development cycle. I was busy with other things, and all of a sudden, we’re already at the beta – I’ve just released 3.9.90, which is the first beta release.

High time to show some of the nice new things that will come in GNOME 3.10.

System statusFirst, we have a new combined system status menu. This addresses a number of complaints about our previous system status area, such as the user name taking too much space on top bar, and privacy concerns about showing it prominently on the screen.

This screenshot does not really do the work justice, for a full impression, you should try it yourself or study the design.

Headerbars are the new blackNext, many applications are using header bars instead of traditional titlebars.

Our previous approach of hiding titlebars on maximized windows had the problem that there was no obvious way to close maximized windows, and the titlebars were still using up vertical space on non-maximized windows. Header bars address both of these issues, and pave the way to the Wayland future by being rendered on the client side.

Accessibility settingsSomewhat unexpectedly, the control-center has seen quite a bit of work this cycle, too. There is a new Universal Access panel…

Display settingsa new display panel…

Background settings…the background panel lets you configure the lock screen image now…

Date & Time settings…and finally, there is a new Date & Time panel.

Timezone mapThe map is still there, if you manually configure your timezone. I hope we can enable automatic detection for 3.10, so you won’t have to, anymore.

Speaking about maps, I should mention at least one new application:

Maps !GNOME maps will be a preview in 3.10.

That’s it for now. There’s a lot more new to discover in GNOME 3.9.90, like a completely redesigned tweak tool, the note-taking application Bijiben, support for hi-dpi displays,  etc.

If you find the right branches of mutter and cogl, you even use most of this under Wayland instead of X – our porting effort is making steady progress.

GTK+ meeting notes

We had a GTK+ meeting during the Guadec BoF days. It was a long and good discussion touching on many issues. Notes from the session can be found here. Hard to summarize, but some highlights:

  • There’s a lot of interest in adding a flow box / grid companion to our new list box widget, and also adding a model-view separation. Expect to see work on this next cycle
  • We’re starting to make progress on clutter integration. Things are happening, but may not be ready for the next cycle
  • 3.10 will have pretty complete hi-DPI support. Just waiting on cairo, now.

GNOME / Wayland plans

In the interest of transparency (and for the benefit of Kristian, who had to leave before the BoF), I’ll quickly summarize the main decisions that were reached at the Guadec Wayland BoF today.

  • We are planning to have a tech preview of GNOME shell as a Wayland compositor in 3.10
  • GNOME shell will run on KMS, not just nested
  • We will keep the Wayland port of mutter on a branch for now
  • gnome-shell will build two binaries, for the X and Wayland compositor
  • Display configuration will work
  • In 3.10, we’ll keep input methods working as before, with client-side IBus. We will switch to using the Wayland text protocol and server-side IBus next cycle.
  • We may not get gdm to launch the tech preview, and fall back to launching the shell manually from a vt

For more details, see the feature page. That page also has a list of anticipated limitations of the tech preview.

Scrolling in GTK+


Scrollbars are hard to get right. They have very small click targets and are barely usable to make fine adjustments. In GTK+ 3, we’ve made a number of changes to scrollbars in the last few years.

  • We’ve removed the steppers
  • We made the scrollbar smaller and look more like an indicator
  • Clicking outside the thumb jumps to the position; paging is still available via right click

In particular the last change caused some heartburn. To compensate, we added a ‘zoom mode’, which scrolls slowly (1-1 correspondence between pointer movements and scroll delta). Unfortunately, it turned out to be too much of an easter egg. To trigger it, you have to hold down Shift while clicking on the thumb. The combined use of mouse and keyboard is also complicated for many users.

This cycle, we’re trying again to make scrolling useful. I’ve just merged patches by Jon McCann and Jakub Steiner to change the zoom mode is triggered. Click-and-hold or long press on the slider will now put the scrollbar into zoom mode. We’ve also added a visible feedback for this, which makes a big difference. To top it off, Jon added autoscroll – if you are scrolling in zoom mode and move the pointer above or below the widget, the scrolling will continue until you let go of the button. This turns out to be very nice. You should try it once GTK+ 3.9.12 is out.

Since the autoscroll is hard to capture in a screenshot, I’ve also made a little video to show it off.