Guadec 2013 – day 2

The second day of Guadec is starting with a very inspiring keynote. Matt Dalio of Endless Mobile is sharing his vision for how to bring computers and the internet to the 80% of the worlds population that don’t currently have access to it, and how they are using GNOME in doing it.

Truly exciting. The world is changing, and we can be part of making it happen.

Matt Dalio keynoteThe audience is listening.

Keynote audience

Some GNOME 3.9 sightings

Today I spent some time building various branches and modules to see if I could find some early signs of the features that have been proposed for GNOME 3.10. It is still early in the cycle, we are just about to release 3.9.2 this week.

Here is my harvest of screenshots. Not all features are easy to capture in a screenshot, but see for yourself.

GNOME MusicGNOME Music is a new app for, well, playing music. Of course, it can’t yet compete feature-wise with e.g. rhythmbox, but it looks fresh and promising. And it plays my music already.

GNOME MapsGNOME Maps is a map viewer. It is still in its infancy – it does not do much yet beyond loading maps and showing me my location. But that will soon change.


Gitg is a git repository viewer. It has been around for a while. Recently, it has been rewritten in vala and it is getting a visual refresh this cycle.


Bijiben is a note-taking application, it was available as a ‘preview’ in 3.8 (and you can install it in Fedora 19 by running yum install bijiben). For 3.10, it will be much more feature-complete, data exchange with tomboy and online accounts is planned.

VideosTotem is getting a face-lift, picking up user-interface elements from other GNOME 3 applications (while not losing any features).

Status menuThe GNOME shell status area may be getting a design update, combining most of the hardware controls into a single menu.

That’s all the screenshots I could gather in an afternoon. If you want to learn more about the things that GNOME contributors and summer-of-code students are working on, you can look at the proposed features, or you can try out the latest code with OSTree or jhbuild.

GTK+ hackfest, wrapup and end

I had to take a day off from the hackfest on Tuesday to get a few things done in the office. The GTK+ hackers surprised me by collectively jumping on the bus and coming out to visit me in Westford. How sweet ! Yesterday we were back in the OLPC offices for the last day – much faster to get to the airport from Cambridge…


In these last 2 days, we’ve discussed various non-technical topics, including Guadec planning, the 3.10 roadmap, regressions, etc. Before diving into these, here’s a little demonstration of scrolling under Wayland. This is a testcase we’ve used in evaluating drawing performance with the wip/simple-draw branch. It certainly shows that the Wayland backend is doing ok as far as drawing speed is concerned.

Scrolling, scrolling, scrollingOur Guadec presence will include at least two or three GTK+ talks, and we’ll also have a Wayland BOF, which should touch on GTK+ topics as well. If you haven’t submitted a talk yet, do so this week !

On regressions: There are a number of problems in git master currently. This includes growing infobars, the (temporary) loss of search in the file chooser, problems when drawing to client-side decorated toplevels, as well as numerous issues with window sizes.  We are aware of these, and will hopefully have most of these addressed before too long.

Merging all of the big pieces early in the cycle gives us enough time to find and fix these problems before 3.10.


On that topic, we’ve made a list of things that we still hope to complete and merge for 3.10 (I wouldn’t quite call it a roadmap).


  • Alex will add support for row containers
  • We can improve the separator API by turning separators into properties of the row container
  • Model support should not block the initial merging

Simple drawing branch:

  • This should be ready for merging soon
  • The drawing model changes are considerable, but incompatibility should not be a problem unless you are using GDK without GTK+ (and who does that ?)

Support for hi-DPI displays:

  • Alex has hardware to work on this
  • the goal is to demonstrate it working at Guadec

Wayland tasks:

  • Clipboard cleanup: Benjamin is working on moving GtkClipboard to GDK, so we can cleanly support multiple backends at the same time
  • DND: a lesser priority, but also on Benjamin’s list
  • Owen got frame synchronization working with Wayland at the hackfest, and the performance is good
  • Client-side decorations: I’m going to introduce a second window again, to make things more compatible. widget->window will go back to being just the content area.

A few other things would be nice to get landed for 3.10, but these are less certain to make it:

  • Notification API (Ryan and Lars)
  • Action descriptions (Ryan)
  • GtkBuilder / action integration (Ryan)
  • Make GtkPathBar public and share it with nautilus (Federico)

Finally, there are things that really should be worked on, but don’t have a name behind them currently:

  • Popovers: We do have a prototype for this in GtkBubbleWindow, but it needs love
  • Touch: There are many details that we currently don’t get right

If you feel like you could be interested in working on either of these, meet us on #gtk+.

I hope to see most of the GTK+ team again at Guadec, this meeting was very productive.

GTK+ hackfest, days 3 and 4

The GTK+ hackfest continued on Sunday and Monday. These were days full of good discussion and  hacking, but we still managed to catch some of the nice spring weather outside.

Since we are meeting at the OLPC office in Cambridge, there’s plenty of lunch choices around in walking distance.

So, what have we achieved so far ? Lets start with a few old projects.

The file chooser sidebar is now a public widget, and nautilus will use it in 3.10. This will address long-standing complaints that the file chooser dialog looks and feels subtly different from the file manager. Federico has been working on this for quite a while.

Another old project that we’re finally wrapping up this cycle is composite containers.  In a nutshell, this means (a) less lines of code in complex GTK+ widgets like the file chooser and (b) you get to create such complex widgets in glade in a structured way.

Tristan and Juan worked on this for several years. Tristan wrote about it here. This branch was actually merged a few days before the hackfest (good thing too, since last-minute scheduling complication prevented Tristan from attending).

Alex has just merged his baseline alignment branch – this lets us align widgets like spin buttons, buttons, labels so that their text is at the same level, visually. The effect of this will be subtle in most places, partially because we have trained ourselves to avoid layouts where (lack of) baseline alignment would be very noticeable. I’m listing this among the old projects even though Alex’ work on this doesn’t have a long history, since it was part of the original height-for-width geometry management gsoc project long ago.

The stated goal for the hackfest is new widgets to support modern applications like gnome-documents or gnome-music.  As the patterns for these applications were developing over the past year or so, we’ve used libgd as a staging area where these new widgets could be shared between applications, but they really belong in the GTK+.

So, what has been achieved ?

GtkHeaderBar was already integrated a few weeks ago as part of the client-side decoration support, and I’ve written about it here.

GtkStack and the associated GtkStackSwitcher have just appeared in GTK+ master. Taken together, these two can replace GtkNotebook in many uses (though it is not a 1-1 feature-complete replacement. E.g GtkStack does not support tab drag-and-drop). A nice new feature of the stack widgets is that the transitions between pages can be animated in various ways. This kind of animation is reasonably easy to do in GTK+ now, with the new frame clock framework that we have since 3.8.

You can see GtkStack and the switcher in the video above. I’ve slowed down the transition there to make it very obvious, it is normally much quicker.

Another new widget that makes use of animation is GtkRevealer, which can show a child widget in an animated fashion. This is commonly used to implement in-app notifications, or for sidebars that should not appear abruptly, but smoothly. Compared to GdRevealer, the GTK+ version has been generalized a bit: the child can slide in from any direction or it can fade in. We’ve also added rtl flipping support.

The ‘is a multiple of 3’ popup in the video above is an example of the revealer in action.

What’s still cooking ?

The last big new widget on our wishlist is EggListBox. This one is not quite ready to be merged as-is, but after our discussion, we now have a  list of what is missing:

We agreed that we need a row container widget – being able to add arbitrary children to the listbox is very nice, but without an intermediate container, handling selection state, focus drawing and accessibility is a bit problematic. Alex is looking into adding this to EggListBox (and EggFlowBox).

The other thing we need for scalability is a way to hook up a data model and only instantiate rows as they are needed, instead of populating the entire list or grid at once. Benjamin has prototyped this long ago, in the wip/list branch. While we eventually need this, many of the current button-box-like uses of EggListBox are working just fine without it.

Apart from new widgets, we’ve looked at all the GtkSettings and have plans for how to deal with many of them in better ways. Some will require more work (like getting rid of modules), others will be easy (like can-change-accels – just stop doing it).

Of course, plenty of other cool stuff has been hacked on on-the-side, and may has already landed or may still find its way into GLib or GTK+ before too long:

Cosimo and I have spent some time on client-side decoration, and fixed some issues. There are no more black flashes when complex widgets are mapped, opacity works again, and the theming has been simplified.

Alex has a branch that simplifies the gdk drawing scrolling model. Initial tests with this are very encouraging, so it will likely find its way into 3.10 after the few remaining problems have been fixed.

Ryan has committed a nice speedup to GObject instantiation, and while at it, made GLib behave nicer when running under valgrind – it is no longer necessary to set G_SLICE=always-malloc manually.

Once again, thanks to the OLPC for hosting us in their offices, and thanks to the GNOME foundation for travel assistance.

GNOME 3.8 in moving pictures

I just ran across this nice video that was done by the World of GNOME team:

It does a great job of highlighting some of the new things in 3.8. Worth watching, if you don’t want to wait until GNOME 3.8 appears in stable distributions, such as Fedora 19 (in ~ 2 months).

There is a silent version of the video as well, if you have trouble viewing the one above.

Adventures in Wayland

I’ve spent the last two weekends with the GTK+ Wayland backend, trying to make some progress towards day-to-day usability. While there are still some big gaps, things are looking pretty ok now.

Window decorationsThis screenshot shows client-side decorations on a GTK+ window. You can see rounded corners and invisible borders – shadows are still missing. We use the proper resize cursors, depending on which directions the window can be resized. This is a combined work of Kristian and Rob, based on older work by Cody Russell.

SettingsThis screenshot demonstrates that GTK+ applications are picking up desktop settings now – in this example the cursor theme as well as the text size.

The support for settings in GTK+ is a bit complicated: We have a GtkSettings object which receives changes from the xsettings client in the X backend. These xsettings are provided by the xsettings manager that is part of gnome-settings-daemon, which in turns reads the settings out of GSettings.

In Wayland, there is not root window to store properties on, and no X selection mechanism to manage it. In principle, the compositor could provide a settings interface for clients to use. Since we don’t have that yet, the GDK backend reads the settings directly out of GSettings for now. That works fine and fits the Wayland philosophy of doing things client-side.

Keyboard supportThis screenshot tries to capture some improvements of the keyboard support. Key repeat is done client-side and similar to the settings, we pick up the configuration for it directly from GSettings. Keyboard state information is propagated, and causes the Caps Lock warning icon to be shown in the password entry.

The Wayland backend should also handle keyboard layout changes, but since weston does not support changing layouts at runtime, this has not been tested.

The tooltip on that icon shows that there’s some work left to be done on popup window placement.

Custom titlebarsOnce we have client-side decorations, it becomes very natural to allow custom titlebars, like the one shown in this example. This has always been possible: you could use old-style wm hints to tell the window manager not to put a titlebar, and do your own. Using gtk_window_set_titlebar() just makes this easier, and it does the right thing, regardless whether you are using client-side decorations under Wayland or traditional wm decorations under X.

All of the screenshots are with current git master of GTK+. Trying out Wayland is pretty easy if you are on Fedora 19. The gtk3 package has the Wayland backend enabled. Just install weston, and set GDK_BACKEND=wayland.

To learn more about the status of the GTK+ Wayland backend and the work that remains to be done, visit the wiki page.

Is your GNOME shell extension ready for 3.8 ?

GNOME 3.8 is right around the corner – we are working on the release candidate today. In 3.8, shell extensions get a lot more recognition; via the new Classic mode that is built with extensions.

Coral tree flowers // by Tatters

But there’s a whole universe of interesting extensions out there on beyond the ‘official’ ones. Unfortunately, many of them are not currently marked as compatible with 3.8. Now is the perfect time to test your extension and make sure it is ready for the new stable release.