Searching the Control Center

Nick and I had a discussion a few days ago about what search should look like in the new Settings shell. I had a go at implementing what we discussed and now it is possible to search not only panel names, but also their descriptions:

Showing the match in-line (much like search engines do) gives the user an understanding of why the item has matched, but also some context. It probably needs some tweaks to detect things like word boundaries, and the description of each panel needs to make sure it includes relevant keywords.

I also made sure that keyboard usage was easy. The filtering is done as you type and pressing enter will activate the first (top left most) item. Hitting the escape key will clear the entry and return you to the All Settings view. I also need to add arrow key support so that it is possible to navigate directly to the results view from the entry.

If you’d like to try it out for yourself, the code is in the extensible-shell branch of gnome-control-center.

Monet – A Widget Drawing API

I’ve been quietly working in my spare time on a new project, called Monet. The aim is to provide a cross-toolkit widget drawing API and theming architecture. This would allow different toolkits to use the same code to draw their widgets, thus producing a more consistent look and feel across applications. The other motivator is to improve the theming abilities provided by existing toolkits and applications. The main target is to improve GTK+ theming opportunities, but I am also considering extending this beyond traditional widget theming, especially as GTK+ may have client side window decoration support soon.

Following on from the discussions at the theme hackfest last year, with extra input from Benjamin Berg (current maintainer of the gtk-engines package) and other Gnome artists and designers, we’ve created a new widget drawing API, drawing on ideas used in existing toolkits such as GTK+, Qt and Windows.

The main concepts behind the design are fairly simple. Each widget is represented by an object that encapsulates all the information necessary to draw it. This can include geometry, context, state, colours, and other properties such as text. For example, the Button class includes text, background and border colours, as well as certain flags such as whether the button is focused. This information is passed to the theme drawing API (the “theme engine”) with a cairo context, onto which the button will be drawn. More complex widgets are split into sub-elements and passed to the theme engine as a group. More exotic widgets such as window frames could also be added as part of this API. The advantages of using objects to define each widget’s drawing parameters is that they can be sub-classed and provide well documented properties.

Since the drawing API is defined as an abstract class, it is still possible to write new themes in code, just as they are done now in GTK+. However, I would like to include a theme engine that allows artists and theme authors to write new themes without requiring a compiler and even provide GUI tools for creating themes. There are several possible solutions to this:

Using an existing specification such as CSS seems attractive, but on closer inspection it is clear that CSS is not suitable for widget drawing without using images or custom extensions. As author of the Moblin toolkit, which uses CSS exclusively for styling, I have experienced first hand its short comings when it is applied to a widget scene graph, rather than an HTML document. There are several unapparent problems that arise, such as the lack of class hierarchy matching*.

SVG might be an alternative solution, but again there are problems that can only be solved with custom attributes and renderers. These would need to include the ability to keep constant stroke widths and corner radii when scaling. This would necessitate both custom editors and renderers.

Another possibility would be to use a custom scripting language such as Lua or even Javascript. The drawing API could be exposed to appropriate objects in these languages and cairo used directly. However, I would expect concerns about performance and efficiency, not to mention that writing a wysiwyg editor would be near impossible.

Finally, a custom XML format was suggested as a possibility (in fact, by a designer, no less). Personally, I don’t think anyone should have to write XML to create a theme, but luckily it would be trivial to write a custom editor for this type of theme. It also would have the advantage that it is not bound to any existing but ever-so-slightly different use case. It would also be trivial to expose the cairo API in such a format. Metacity also has a drawing API defined in XML and this could be used as a starting point (although, a much simpler schema could be achieved since less geometry needs to be specified).

I would be interested to hear any further thoughts on alternative theme formats.

I have started prototyping these ideas in a git repository on, under the Monet project. Since the API includes an object for each widget type, I have experimented with implementing this to some success using Vala. The abstract base classes are available, as are classes for simple widgets. There is also an implementation of a GTK+ engine in Vala, which would form the basis of a translational mechanism. A very simple (and limited) test engine is implemented, along with a test case to drive it. Certainly none of it is interesting to users yet.

My hope for the future would be that toolkits gradually begin to start using the new API natively, but to help during the transition period, wrappers can be added to the existing infrastructure. For example, the project will include a traditional GTK+ engine as a proxy to allow GTK+ users to start using the new architecture immediately.

There are certainly problems that the API does not yet solve, such as transition effects. Other considerations might whether to add support for “native” styles on other platforms, such as Windows and Mac OS X, or whether these are best left to each toolkit to implement themselves. I would be interested to hear any suggestions around these areas.

* Qt “solve” this in quite an interesting way, but it changes the semantics of class selectors in CSS.

GNOME/Moblin Control Center

I’ve been looking recently at what can be done to improve the GNOME Control Center shell for both GNOME 3.0 and for Moblin. In Moblin, we wanted a single window approach, so that finding a setting and opening a preference pane could be done within a single environment. After some discussion on IRC and on the control center mailing list, it seems people within the Gnome community were also interested in this idea. I’ve been having a go at prototyping this behaviour to see how it would turn out. We’ve now gone through a couple of iterations of refining the design into something that is more promising. Here are some screenshots of how it looks right now:

Displaying all settings categories:

Searching for a setting:

Opening up the keyboard preferences:

The work is all available in the single-window-shell branch of gnome-control-center. At the moment, the single window behaviour is implemented using the XEmbed protocol via GtkPlug and GtkSocket. This allowed us to quickly prototype and experiment with the behaviour while making minimal changes to the existing capplets, although any capplets without the added functionality will open in a new window as before. Jon McCann of RedHat is also looking at using GIO Extension Point based approach, but this requires a more significant re-write of the capplets.

At the upcoming GNOME Usability hackfest I hope to gather more feedback on the design and possibly start working on refining the UI for many of the individual preference panes as well.