GNOME Summit – Sunday

Sunday was dominated by informal discussions in the hallway. Among other things, I got to see a demonstration of bonds, vlans and other ‘exotic’ network configurations in the network panel and the shell network indicator.

But we also had number of breakout sessions on individual topics: GTK+, epiphany, multi-monitor, sandboxing, and maybe one or two more that I can’t remember now. I’ve participated in the GTK+ and multi-monitor sessions.


This session was focused on discussing features that people would like to see in GLib and GTK+, with sometimes extensive discussion about the pros and cons and implementation details.

For GLib, Ryan presented a long list of things that he would like to see

  • ‘Native’ thread operations: This is about reimplementing GMutex and GCond on Linux with futexes and atomic operations instead of relying pthreads. The hope is to end up with a faster and more performant implementation.  Targeted for 2.36
  • epoll support: Using epoll in the GLib mainloop is a long-term goal. As a step towards that goal, we may introduce api in 2.36 that lets  sources forego the prepare() and check() stages and instead use a precomputed timestamp.
  • Remove dynamic types: Unloading types when a module is unloaded is a nice idea in theory, but has never worked well enough to justify the complication it forces on GType. In practice, everybody makes their modules resident. Not clear if we will do something about this for 2.36.
  • Remove dynamic interfaces: It is generally considered a mis-feature of GType that one can add interfaces to a class after class_init. Removing this feature would again allow us to simplify gtype.c, and it is not something that is actually used. The plan we’ve agreed on is to add an assertion in this code path for this development cycle (it will be reduced to a warning in the stable 2.36 release), and remove the feature in 2.38.
  • Fix g_signal_connect_object(): We will finally fix this 10 year old bug this cycle.
  • Reversible: Ryan explained this idea that he already outlined on the mailing list. The discussion was inconclusive; both Dan and Stef pointed out the problems with such implicit, context-based APIs, and cited default thread contexts as an example that has caused problems in practice.
  • Implicit g_type_init: We are already doing an implicit g_thread_init(), using constructors. Ryan wants to extend this to also call g_type_init() automatically when a program is linked against libgobject. Not much discussion around this; nobody could come up with an example where you would need to delay g_type_init() to do something else first.
  • Cleanup at exit: Freeing all memory allocated by GLib would benefit people who are using valgrind to find memory leaks in their applications. Stef pointed out that a common desire is to run test suites under valgrind. The reason that we’ve not done this so far is that it is a hard problem. This became clear as wediscussed the possible approaches. It will be easy to get this done for libglib; libgobject is much harder. One thing Owen mentioned is that in the meantime, we could just improve our documentation about memory management and write up some best practices for dealing with memory leaks.
  • GTask: This is #661767. Dan will land it this weekend.
  •  GProperty: This is currently stuck; somebody to pick it up again since Emmanuele doesn’t seem to have the time to finish it.
  • GDateTimeSource: Ryan explained this as a special-purpose GSource that gets dispatched at fixed intervals (e.g. every full minute), and also takes discontinuities (such as clock changes, timezone changes, DST) into account. This functionality is currently provided by GWallclock in libgnome-desktop. It be too specialized for GLib, we didn’t reach a conclusion about it.
  • GSettings list: We have a branch that has the necessary API, and would really like to get this in 3.8. It needs to be landed in sync with dconf, since it requires changes of the GSettingsBackend API. This currently holds up the merge, since we also need to update the OS X and Win32 backends. It would be fantastic if we could find volunteers to do this work (and maybe maintain these backends, going forward). As Ryan said, having native backends for all major platforms is a selling point for GSettings, and we should not regress here.
  • GSubprocess: This is in the final stages of review between Ryan and Colin, and will land soon.
  • Unicode 6.2 support: Ready to land.

For GTK+, the list of discussed features wasn’t quite as impressive (we were over the 2 hour mark at this point).

  • Paint clock: Owen is fairly confident that we can sort out api questions; we need at least some proof-of-concept implementations for Windows and OS X, Wayland should be easier. Owen mentioned ‘a month’ as an estimate for merging this.
  • Actors: Benjamin explained his plans for this:
    • add a lookalike of ClutterActor to GTK+
    • keep it private for now
    • start converting widgets one-by-one. The progressbar is good starting point, since it has no event handling, and its drawing is complicated enough to make it interesting
  • Accessibility: API brought up that people have been asking for a way to subclass gtks accessible implementations. We had kept these private because we wanted to make more changes such as porting the iconview accessible to use cell accessibles, and moving away from atk and instead implement D-Bus interfaces directly in widgets. The outcome of the discussion was that these changes are likely never going to happen (the current a11y seems to work well enough that nobody is willing to invest into these larger-scale refactorings). Therefore, we should clean up the gtk a11y headers, and expose them. Before running out for lunch, the discussion moved on to one other cleanup task in the a11y area that hasn’t happened: getting rid of key snooping. Joanie explained why orca needs to filter key events (to add useful extra navigation, such as ‘h’ to go to the next heading in a browser). We discussed possible ways to implement this outside the client, using passive grabs – but of course you don’t want to grab the ‘h’ key, that would make it hard to write text… I pointed out that input methods currently also use key snoopers, because they want to get at all key events. This is bug 90082.


The multi-monitor session was quite different. I brought an external monitor, and we huddled around my laptop, taking lots of notes about issues we saw. All those notes are with Allan, who can hopefully put them on the wiki soon. Until then, here’s what stuck in my memory:


  • The transition from plymouth to the login screen is really bad. This is not specific to multiple monitors, it is always bad :-( The progress in plymouth is not really useful nowadays, since the part of the boot that is covered by it has gotten so fast that it is dominated by the wait for the login screen – and we have no progress there, except for the ugly wait cursor. The pointer should be hidden until it is moved.
  • On the lock screen, monitors should have independent shields, so that lifting it on one monitor does not cause activity on the other one.
  • The on-screen keyboard needs to appear on the monitor where the focus is. Currently, it just always appears on the primary monitor.
  • Windows should be centered if there is not enough free space to place them.
  •  Side-tiling should work differently at the shared edge between two monitors.
  • The difference between maximized and fullscreen is not very clear on non-primary monitor. We should have more uniform behaviour and controls for fullscreen windows.
  • In the overview, starting a drag on one monitor makes windows jump on the other monitor, which is unexpected.
  • The display panel needs lots of love:
    • we should drop the confirmation dialog; nowadays, we can find out if a configuration changed worked or not, and can revert without asking the user.
    • dragging monitors needs to be keyboard navigatable
    • there should be a non-DND way to change where your top bar appears
    • no need to show monitor labels when cloned
    • monitor labels did not update when un-cloning
    • ‘Laptop’ is not a good name to use here

We also briefly talked about how multiple regular monitors are different from laptop+projector.

Today we’re going to talk about authentication, CIFS and other enterprisey stuff.


Input Sources in GNOME

Today I want to take a look at one of the bigger new features in the upcoming GNOME release, Input Sources. I have written some early code for this, but the credit for getting it all working and completed really goes to Rui Matos and Takao Fujiwara.

On a high level, the goal of the work we’ve done here is to make input methods an integral part of the user experience, just like keyboard layouts. You should no longer have to choose and install an input method framework manually. Things will just work out of the box, and the user experience for configuring and using input methods will match the rest of the desktop.

To reach this goal, we’ve made numerous improvements to the input method support in GTK+ 2, GTK+ 3, clutter and gnome-shell. IBus itself has also seen some changes as a result of this work. So, even if you don’t agree with our decision to use IBus and choose to use a different input method framework (which is still possible), you will benefit from these improvements.

But lets look in detail what’s available.

Keyboard layouts and input methods or Input Sources, as they are now called, are configured in the Region & Language settings.

When we first merged the input method support, there was only small list of supported input methods. We have now expanded the list to include input methods for all major languages.

The reason that we don’t just include everything is to avoid duplication between keyboard layouts and input methods and special-purpose input methods that are not aimed at language-specific input. If you happen to need one of these excluded input methods or layouts, you can use the setting to see everything.

Keep in mind that input methods are often shipped in individual packages or language-support groups, so if an input method is missing in the list, it may just not be installed on your system.

Some input methods are traditionally very configurable – we honour that by allowing them to open their own configuration UI. For keyboard layouts, some common variations (e.g. the Compose key) can be changed in the keyboard shortcuts.

You can switch between the configured input sources in the gnome-shell keyboard menu.

Again, we are respectful of input methods that traditionally have runtime configuration available in this place, and show the most important switches in the menu.

Some input methods present choices directly at the focus location. This candidate window is now using a shell-style popup, which has the same appearance regardless whether you are writing in an application or in gnome-shell.

So, what’s still missing ? GNOME 3.6 is right around the corner, but Rui is still busy working on support for layout-switching shortcuts like Alt+Shift. The user interface for changing these will find a (temporary) home in gnome-tweak-tool, together with some more keyboard layout variants.

Beyond 3.6, we want to make the on-screen keyboard play nice with input sources. We also plan to add an Alt-Tab like mode for switching input sources, etc. The feature page has some more details.

Here is a bonus screenshot which has nothing to do with Input Sources. It shows a gnome-shell feature that I recently discovered:

The Sound menu shows you the input level of your microphone – but only if an application is using audio input. Nifty !

A look at gnome-boxes

Too much talk about files, lately… what about VMs ? Our answer to that is to put them in Boxes.

When we introduced GNOME Boxes in 3.4, it was really just a preview, with much more to come in 3.6. Since then, the boxes team has been quietly working on adding features and polishing things.

So lets take a look at what’s coming in Boxes 3.6.

Boxes tries to be smart about choosing good defaults for memory and disk sizes depending on the OS that is being installed (this information is being provided by libosinfo). But sometimes, you know better,  and then that Customize button is coming in handy.

One particular aspect of customization is renaming.

This looks like just a small detail, but being able to give meaningful names to VMs helps when you have many of them, and want to find them again later. To do so, you can now search.

Search in Boxes looks much the same as search in other GNOME 3 applications. And just like for other GNOME 3 applications, your VMs will also appear among the gnome-shell search results in the overview.

Another aspect where Boxes is picking up patterns from other GNOME 3 applications is selection.

VMs are very convenient to quickly try different OSes or nightly snapshots. Boxes tries to support this by recognizing when you are working with live media. As long as you don’t make persistent changes, Boxes will treat such VMs as transient, and will delete them when you shut them down.

Sometimes, when things go wrong, it may be necessary to shutdown a VM forcefully. Boxes lets you do that.

What I cannot really show in screenshots is how much more fluid and smooth Boxes feels. A lot of work has gone into making libvirt calls async to ensure that animations run smoothly. Resizing the Boxes window very nicely adjusts the display resolution.

The Boxes command line interface has received some attention as well. You can find out if gnome-boxes will work on your machine:

$ gnome-boxes –checks
• The CPU is capable of virtualization: yes
• The KVM module is loaded: yes
• Libvirt KVM guest available: yes
• The SELinux context is default: no

You can also open a VM from the command line, by name:

gnome-boxes f18

In summary, a ton of improvements, many small and some large. Boxes will no longer be a ‘preview’; in GNOME 3.6, it will be solid, useful application. You should give it a try !

There’s also some things to look forward to in 3.7 already. A while ago, Christophe showed a preview of the coming ovirt support (see all your remove vms in gnome-boxes).

On nautilus

Shells // by Christina MathesonA lot of ink has been spilled recently over the fact that nautilus is evolving into Files.

I’d like to present a few facts and thoughts about this, and explain why I am looking forward to the new nautilus.


Here are some examples of what I am looking forward to in nautilus 3.6:

A more usable list view, which focuses on presenting important information in usable form:

List ViewWell-working search, with file search results in the shell.

SearchNautilus search is improved in many ways: it is fast, you just type, like we do in the shell – which has worked out great. It is case insensitive, can search hidden files or directories, can work recursively, doesn’t only do prefix matching, can search metadata, has ranked results based on a weighting algorithm, can work on indexed and non-indexed directories.

Recent files in the sidebar:

Recent FilesWell-working remote browsing:

Connect to ServerA visual appearance that fits in with other GNOME 3 applications:

NautilusBut let’s look at how we got to this point, and think a bit about the history. Actually, nautilus has quite a long and involved history. The first commit in the git repository dates back to 1997. In early 2000, Eazel starts to appear in the history. Along the way, ambitious features appeared: zooming with level-of-detail, desktop handling, spatial mode, a vfs, remote browsing…

Many of these things have fallen by the wayside over the years, but they have left scars behind:

A complicated and hard-to-maintain code base: for example, nautilus had a utility library called eel in the early days, which was then broken out as a separate module. Later it was merged back in.

There’s still a stripped-down copy of GnomeCanvas inside nautilus, for handling the desktop drawing.

Remnants of past features showing up in odd places in the UI. For example, the view mode was remembered per-folder until recently. That made a lot of sense in the spatial paradigm, but not so much in browser mode.

Another example is the overlap between search and find.

Nautilus development has been somewhat stagnant; while GNOME 2 turned into GNOME 3, nautilus largely remained the same. But no more. During the 3.6 development cycle, nautilus has seen intensive development, and it is still ongoing.

This makes what has happened this cycle even more remarkable. Not only has there been plenty of new features, but there has also been a massive cleanup operation. Over 500 (!) bugs closed, some of them really old, like 45708 (filed in 2001) some of them crashers, like 668674, some of them hard-to-track-down regressions in other parts of the stack, like 680349.

Bug countA lot of controversy has erupted about the fact that early parts of the roadmap removed some features. On some level, this is unavoidable: if you want to put a new coat of paint on a wall or your car, you also remove the old paint first, for best results. But if you read the roadmap in its entirety, you will find many feature additions on the list as well. Some of the removed features will come back in slightly different form, e.g. the split pane.

So give the new nautilus a chance and try it when 3.6 is released, and let us know what you think. We’ll be listening to your feedback, and there will be plenty of opportunity to make further changes in the future.

If it turns out after a test drive that the new nautilus is not right for you, keep in mind that nautilus is just an application. We think you’ll be happy with the new Nautilus, but if you aren’t, there are other file managers that you can try.

Rounding out the 3.6 feature list

Here is the next installment of ‘Seen in this weeks GNOME release’. Todays screenshot gallery is a little more extensive than last weeks. We’re rapidly completing our feature list. Most of the items on that list are now marked as ‘Complete’ or ‘Almost complete’. Good timing, since we are entering the freeze with the 3.5.90 release, and can now focus on polishing these features and fixing the remaining bugs.

The first feature to show this week is one that I’ve wanted to see for a long time: the harfbuzz 1.0 release is right around the corner, and harfbuzz support has been merged in pango. Behdad has been working on this OpenType implementation since 2006, and pango has been using an embedded copy of an early harfbuzz snapshot for a while.

After a long period of stasis, we will finally see new life in our text rendering stack. The screenshot I’m showing for this looks just the same as it always has, since all the harfbuzz goodness is still under the hood.


We’ve had a magnifier integrated in gnome-shell for a few releases now. Since 3.4, it was configurable from the universal access panel. In this release, it will be possible to configure various color effects on top of the zoom, such as inverted colors, desaturation and contrast changes. As you can see in the screenshot, we’ve reorganized the zoom options into tabs, and added a tab for the color effects.

Still in the control-center, we have a redesigned Mouse & Touchpad panel, which was implemented by our Red Hat desktop team intern in Brno, Ondrej Holy. Amongst other things, you might spot the option for ‘natural scrolling’ in here.

Over in the shell, there’s a new ‘mode-less’ overview. As you’ll notice, the search entry is bigger and centered, and the tabs are gone. To switch from the window view to the application grid, you can use the ‘nine dots’ button that can be seen at the end of the dash.

The new overview is the work of Florians summer of code student, Joost Verdorn, who has written more extensively about it already.

At the bottom of the overview, the new message tray is visible. It received a major redesign to address the problems that people have had with the original 3.0-era tray design.

Beyond the new visuals (bigger icons, no labels, close buttons), there are many subtle behaviour changes here that are hard to explain unless you try it yourself. One notable change is that the message tray is not raised ‘by itself’ anymore, you always have to bring it up explicitly. One way to do that is to use the new Super-M keybinding. Keyboard navigation is generally improved: you can focus individual icons and actions.

Many people have contributed to the message tray redesign, around the core work done as a summer of code project by Ana Risteska.

Back in the control-center, the sound panel has gotten its Hardware tab removed. Instead, the device lists now offer more fine-grained choices.

This simplification has been implemented by Canonical. It was made possible by earlier pulseaudio work by David Henningsen that has landed upstream in pulseaudio 2.0.

In the keyboard shortcuts section, some useful pieces of XKB layout configuration have reemerged. The frequently used compose key and ‘third level chooser’ variants can be set like other keyboard shortcuts now.


When it comes to appearance, GTK+ 2 applications will look less out of place in GNOME 3.6, thanks to a much improved gtk2 version of Adwaita. This theme was originally developed under the name ‘Bridge’ by Jack Gandy.

You have to look closely to see the differences between the GTK+ 2 and GTK+ 3 print dialog in these screenshots.

The last thing I have managed to capture in screenshots is the support for secondary Kerberos logins that has been integrated in gnome-online-accounts. The functionality is seamlessly integrated with the traditional krb5 commandline tools: if you run kinit in a terminal, the ticket will immediately show up the online-accounts panel, and you will get notifications before it expires.

This functionality was originally planned to land in the user panel, but the online-accounts panel seems a much better fit.

GNOME 3.5.5 impressions

It was my turn this week to do the GNOME 3.5.5 development release, and I took some screenshots while smoke testing the release.

The big feature that is new in this release is the new screen lock implementation. It sports a ‘shield’, which can be lifted by hitting Escape, or by dragging it up, to reveal the unlock dialog.

We had a BoF session on the new screen lock at GUADEC, and identified a number of issues that still have to be addressed.


Some applications have received more love, here is a screenshot of Baobab that shows its new location list.




In the System Settings, several panels have been improved.

First, here are some screenshots of the printer panel, showing that it is now possible to select drivers, set default options and control queued jobs.













The network panel sports  a new design for the wireless page.

The network combo box has been turned into  a list that shows not only access points that are in range, but also saved connections.

Connection details are available for active and saved connections, and it is possible to forget saved connections.

GNOME 3.5.4 sightings

Here’s another installment of my GNOME updates, showing some of the new things that I’ve seen land since we released 3.5.3 two weeks ago.

Nautilus has received a major face-lift, and looks very much like a GNOME 3 application now.




The initial support for presenting input methods alongside with keyboard layouts has landed in gnome-control-center,  gnome-settings-daemon and gnome-shell.

This feature has received a lot of attention already, and we expect lots of feedback – by all means, let us know what does not work right. But please keep in mind that we are still working on this, it is not 100% complete yet.

Pieces that are still missing are controls for changing keyboard shortcuts related to input sources, and for commonly used keyboard layout options, such as compose keys, 3rd level chooser keys, etc.

To learn more, follow the links in the feature page.






GNOME Disks (formerly known as palimpsest) has acquired a few features that people dealing with storage devices may appreciate. This screenshot shows it securely erasing a hard drive.

Such an operation can take quite a while, and if you are old and forgetful like me, you may have forgotten that this window was still open on some workspace.

If your system is using a recent systemd (>= 183, to be precise), the new system inhibitor facility lets applications block powering off or suspending the system while such a long-running operation is underway.

GNOME Disks is using this, and gnome-session has also been updated to pass suspend inhibitors on to systemd. Shutdown and suspend request coming in via gnome-session or upower APIs get routed through systemd, so they all respect the system inhibitors.

Another bit of system integration is the new support for ‘offline updates’.

This requires recent systemd and PackageKit, F18 will have all the required pieces for this to work when the 3.5.4 updates land later this week.

To learn more about offline updates and how they are implemented, look at the Fedora feature page.

As my last screenshot shows, even when installed ‘offline’, updates can still go wrong :-)

The sysadmin view on GNOME

A long time ago, we had a useful document that explained aspects of GNOME that are relevant to system administrators: GNOME Desktop System Administration Guide. Unfortunately, that document never made the jump from GNOME 2 to GNOME 3. In fact, it never made the jump beyond 2.14 or so…

With GNOME 3 is  a bit more than a year old now, it is high time that we this situation fixed. To kickstart this, I started a wiki page a while ago where I collect bits of information that should server as raw material for a new sysadmin guide. You can find it here:

This is not my private playground – I would absolutely love contributions from others; there’s many areas I haven’t touched at all yet. E.g.

  • Is it possible to set up online-accounts for users in advance ?
  • What about hardware compatibility –  how to find out if gnome-shell will work ?
  • Lockdown

And if you are a system administrator, please add the questions that you ran into when trying GNOME 3.  Your input will not only improve the new sysadmin guide, it may also show us where we need to make things more manageable.

GNOME 3.5.3 sightings

Here is another collection of things I’ve seen appear in the tarballs that are coming in for the 3.5.3 development snapshot.

Accessibility is now ‘always on’. We’ve worked towards this goal ever since GNOME 3.0, and we’re finally at a point where we can have accessibility enabled by default without affecting stability or performance in a major way.

To celebrate this achievement, we’ve added a ‘Screen Reader’ item to the shell menu.

The first signs of ‘Enterprise Login’ (i.e. Active Directory) support can be seen in the user panel. This is first and foremost the achievement of Stef Walter, who has more information on his blog post.

Some of our smaller applications and utilities are getting some love and attention. As an example, here is the reimplemented baobab disk usage analyzer.

Mounting removable media is now handled with a shell-style dialog.

Finally, the list of supported online accounts keeps growing longer.