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…

Discussions

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.

Typing

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).

EggListBox:

  • 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 extensions.gnome.org 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.

Recent GNOME 3.7 sightings

With GNOME 3.7.90, we’ve entered the feature freeze and focus on polish and on whittling down the blocker list (don’t expect all of these to be fixed, the list currently still contains a mixture of actual blockers and nice-to-have things).

But just before that, there was a mighty effort to get things landed. All that happened while I was travelling, so here is a somewhat late tour of new things that have appeared recently.

Document scrolling

Document editing

GNOME Documents has  a new scrollbar with integrated preview, and lets you edit Google docs in place. What you can’t see in these screenshots: it has also been turned from a clutter-gtk app into a  pure GTK+ app. Among other things, this solves performance and accessibility problems.

Region & LanguageThe control-center has kept up its pace of one new panel per release. Here we see the redesigned Region & Language panel.

Network profilesAny type of network

The network panel can now create multiple wired configurations (called profiles), and it lets you create things like bridges, bonds or vlans.

Background menuMessage tray menuIn GNOME shell, we have a new context menus on the desktop background and on the message tray. These can be opened both with a right click or a long press.

Applications

The shell overview will now show your the most frequently used applications in a separate tab.

GNOME 3.8 will be released at the end of March. If you want to try it before, we have a live image.

The fountain of knowledge

I was at the developer conference in Brno over the last weekend, so I missed this when it first came out, but I’ve just watched the new video by my colleague Monty, and I must say it is really fantastic. Go watch it!

If you want to learn more about the topic and about the software that he used in the production, its all here.

GNOME 3.7 at the halfway mark

We are a bit past the midpoint of the development cycle for GNOME 3.8. That seems like a nice time to take a look at what new things are coming – most new features are visible at least in rudimentary form at this point.

First of all, Settings !

The control-center and settings-daemon have seen a flurry of activity which has resulted in several new and refreshed panels. In other words, plenty of screenshot material — I’ll get to that soon.

First I want to mention a few things that are not easily shown in pictures, but are still going to have a significant positive effect:

  • Tests. Martin Pitt has done great work in mocking up services and creating tests for the functionality of many modules, from udisks and upower to glib and gnome-settings-daemon. Bastien has also added many tests, and fixed the bugs that were uncovered by them. Here is an example.
  • Speed. The control-center panels are no longer loadable modules, but built into the control-center. And all of the .ui and other data files are loaded as resources. Opening the control-center should be faster, as a result.
  • Standards. Bastien added a tiny plugin to gnome-settings-daemon which implements the org.freedesktop.ScreenSaver D-Bus API. This should make it even easier for media players and other 3rd party applications to keep the screen from dimming at inopportune times.

On to screenshots.

Allowing you to focus on your task and minimizing interruptions has been an important aspect of the GNOME 3 design from the start. So far, we just had a global switch to turn off notifications. The new Notification panel expands on this and allows fine-grained control over what applications get to annoy you, and how much.

The new Privacy panel collects various settings to control who may get to see your personal data, etc. Some of these settings, e.g. the Screen Lock settings were previously available elsewhere, but have been moved here because they are related to privacy.

Similar to the Privacy panel, the Sharing panel collects settings that used to be available in other places, in this case the individual preference dialogs for gnome-bluetooth, gnome-user-share, vino, rygel, etc. It also lets you turn sshd on or off.

The new Search panel controls which applications get to show search results in the GNOME shell overview and the order in which they appear. there. Cosimo recently explained the various search improvements in GNOME 3.8 in great detail.

As mentioned above, the screen lock settings were subsumed by the Privacy panel. This left the Screen panel with very few settings, which all turned out to be related to power saving. Thus, they have been moved to the power panel, and the Screen panel has been dropped — which is a good thing, since three panels with monitors in their icon were a little too much.

There are more new things to discover in the control-center. I haven’t mentioned improvements to the user panel, or the color panel, or the rewritten network panel that will be merged soon. But enough about settings for now.


Next, some GNOME shell improvements:

The shell is being ported XInput2. Together with new pointer barrier features in the next X server release (1.14, expected in March) this will let us improve the somewhat annoying dwell-on-the-bottom-edge way to bring up the message tray. It also paves the way to improved side-by-side tiling and gesture support later on.

Keyboard shortcuts will work more consistently. E.g., it will be possible to take a screenshot while in the overview.

The shell overview is displaying search results in a new layout, using the order of search providers as configured in the search panel. I again point to Cosimo’s post for the fine points of this new design.

The algorithm for arranging the window thumbnails in the overview has been fine-tuned to create more pleasant layouts, and the currently hovered window is more clearly identifiable by a strong highlight.

Switching input sources is easier, thanks to a new OSD. This feature was already present in IBus; it has now been integrated in GNOME shell.


A new addition to GNOME 3.8 is the classic mode that is going to replace fallback mode as an alternative for users who want to keep using elements of GNOME 2, such as the minimize button, or the window list.

The reasons for replacing fallback mode have been explained here. In short, it needs to be replaced, because

  • it consists of barely maintained modules (gnome-panel, metacity, applets, notification-daemon,…)
  • it does not offer the quality and user experience that we want to deliver
  • keeping it (somewhat) functional keeps us from making improvements in other parts of the stack

Classic mode on the other hand, is using GNOME shell with a few extensions and few settings tweaks. New GNOME features, like the IBus integration, will ‘just work’ because classic mode is literally using the same code. We are reusing the infrastructure for defining ‘modes’ that was already present in the shell. It is used for the login screen in GNOME 3.6, for instance. The extensions and glue code that make up classic mode are being developed in the gnome-shell-extensions module.

The screenshots below give an impression of the current, preliminary, state of classic mode. We are still working on various aspects of it, and what ships with GNOME 3.8 may look different from what you see here.

To clearly differentiate classic mode from GNOME 3, we are using ‘GNOME 2 gray’. There is a window list at bottom, and the clock has been moved to where it was in GNOME 2.

An application menu.

The message tray coexists with the window list.


Finally, there will be a few new applications in GNOME 3.8. These apps are following the design patterns that have been developed over the last few releases in Documents, Boxes, etc.

A note-taking application.

A photo application.

A weather application.

Input Sources in GNOME 3.7.4, continued

Before Christmas, I wrote about the status of IBus integration and Input Sources in GNOME 3.7. Here is another update to show what has happened since then.

We have added back the option to have a different input source for each window. The GNOME shell overview with its search entry is considered a window in this context.

Many people rely on modifier-only keyboard shortcuts such as Alt+Alt or Shift+Caps to switch between input sources. GNOME 3.6 supports this, but we had to ‘park’ the UI for selecting this shortcut in gnome-tweak-tool, since it came too late to be included in the keyboard panel. This has now been rectified. In GNOME 3.7.4, the modifier-only shortcut can be configured in the Typing section of the keyboard panel.

Input sources in GNOME 3.7.4

I’ve been meaning for a while to write an update about the state of Input Sources and what we are doing for them in 3.7. Finally, I have some screenshots to show.

It is no secret that the input source integration we unveiled in 3.6 had some warts; we have pushed very hard to get it in, and there was just not enough time to get all things done (such as an OSD for switching input sources), or done entirely right (such as the UI for modifier-only shortcuts). Also, we’re all still learning about whats important in this area.

Our far-eastern users have taken to bugzilla and the mailing list to let us know what we got wrong. As they should – after all, they are the ones who use these input sources in their daily life, so they are the experts. We have listened, and in 3.7.4, input sources will be able to show options in the menu:

As you can see in this screenshot, the result is not ideal – the ‘Setup’ should really be accessed via the Region & Language Settings panel, not directly from the GNOME shell menu. But the blacklist we had in 3.6 was a really crude way to approach this problem; for 3.8, we will write guidelines for what kind of settings are appropriate to expose in the menu and work with the upstream authors of the ibus engines to implement these.

Another new thing that you can experience in 3.7.4 is the OSD I’ve mentioned above. Rui refactored the existing GNOME shell application switcher for it, so this did not require much new code in the end. It is triggered by the new ‘switch-input-source’ keyboard shortcut, which is bound to Super+space by default.

These are only the fixes that we have landed for 3.7.4. Next on the list is to bring back some form of ‘per-window mode’ and to move the UI for the Alt+Ctrl shortcut from gnome-tweak-tool back into the keyboard shortcuts panel where it belongs. We will also make these shortcuts work in the GNOME shell overview and in other contexts where they are today blocked due to a ‘modal’ context.

Later on, we hope to make the on-screen keyboard update its layout based on the current input source.