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.

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 git.gnome.org, 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.

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.

I’d like to thank Matthias and Emmanuele Bassi for their help reviewing the patch and to Intel for allowing me to develop it at work (it was a requirement for Moblin from our illustrious interaction designer, Nick Richards).

The final menu behaviour is a little different from my original idea and I’ve attached a patch to the bug that implements my preferred behaviour. You can try out the new setting by grabbing GTK+ from git and adding gtk-auto-mnemonics=1 into your ~/.gtkrc-2.0 file.

Disclaimer

This is a development release. API and ABI are very likely to change. Compatibility with future and previous versions is not guaranteed. It has had only limited testing and there are unfinished features and plenty of bugs in this release. It should definitively not be used in production environments.

Changes

Here is the least of new features and fixes, from the NEWS file:

0.3.0

Changes since 0.2.0

• New toolbar widget
• Convert MxBin to abstract class
• Add MxFrame as a drop-in replacement for plain instances of MxBin
• Use the i-beam insertion mouse cursor in MxEntry
• Clean up MxGrid API to be more consistent with other widgets
• Add support for font-weight property to buttons and labels
• Add animation layout support to MxBoxLayout
• Add special styling for ComboBoxes inside a toolbar
• Implement font styling in ComboBox
• Fix expander label visibility
• Add missing public headers and single include guards (Bastian Winkler)
• Clean up various references to removed functions (Bastian Winkler)
• Documentation improvements (Elliot Smith)

Sources

Sources are available from download.moblin.org:

http://download.moblin.org/sources/mx/0.3/

or from git:

http://git.moblin.org/cgit.cgi/mx/

git clone git://git.moblin.org/mx

I made a video of MxBoxLayout that shows changing packing options (expand, fill and alignment) as well as adding and removing children, and changing orientation (the layout children are just ClutterRectangles):

The work is currently in a branch of the Moblin UI Toolkit repository (animated-box-layout) which I will merge once I have added an enable-animations property to the actor.

In other news, there is now a page on Moblin.org for the Moblin UI Toolkit, and I expect API reference documentation to be available on-line soon too. There is also a new component in Moblin bugzilla specifically for the new toolkit (under “Moblin Distribution”).

We’re working on the bugzilla component, but for the moment issues should be reported in the “nbtk” component of bugzilla.moblin.org.

Quite a few people asked before about language bindings. I don’t anticipate supporting a lot of language bindings, but I will be ensuring GObject introspection works well. I hope that will help people generate any bindings they wish to use and keep them up to date with relative ease. Personally, I have already been using Javascript (via Gjs) to test some aspects of the project.

The interesting features in this release are:

• “long-press” signal added to MxButton (inspired by the “touch-and-hold” discussion in Gnome bugzilla)
• Added an “always-on-top” base class, which helps in creating the always-on-top actors such as tooltips and menus.
• Improved error reporting and various other bug fixes

Even more interestingly still, I hacked up support to allow most themes (gtk, metacity and icon themes) to be installed directly from the web page. This is achieved by setting the content-type to application/x-gnome-theme-package and allowing Firefox (or, I assume, any other web browser) to open the download with the default handler for this type, which is the Theme Installer. This ties in with the longer term plan we’re thinking of, which is to remove the extra themes from gnome-themes and place them (and more) on the website. Users would then install the themes straight from the theme manager or from a browser. Hylke’s already posted some mockups to the control center mailing list on what the new theme manager may look like.

Now, if only there was a nice way to set your desktop background from the browser, without going through right click menus…

The Moblin Toolkit

The first goal was to rename the library to something less specific to the “netbook” platform. We chose ‘mx’ as the name space, because the goal of toolkit is to support the Moblin User Experience. Mx provides a set of standard user interface elements, including buttons, progress bars, tooltips, scroll bars and others. It also implements some standard layout managers, although some of these will be available in Clutter itself when Clutter 1.2 is available. One other interesting feature is the possibility of setting style properties from a css-like file.

What’s New

Followers of Nbtk will be interested to know what’s new compared to Nbtk. The latest additions include:

• notebook – a multi-child container that shows only one child at a time (similar to a slide show). The notebook widget itself does not implement tabs, but these can easily be added by hooking it up to the new button-group widget.
• button group – allows buttons to be grouped so that the toggle state can be mutually exclusive across the buttons in the group (e.g. such as a group of radio buttons might behave.). Also features a property to allow no buttons to be toggled if desired.
• toggle widget – a widget that implements a boolean state and looks similar to a light switch or slider switch. This is a Clutter version of the MxGtkLightSwitch already available. The advantages of the Clutter version are that it provides better animated feedback on user interaction.

There have also been some behind the scenes clean ups, including:

• re-written table layout algorithm – this had much better support for correct minimum and preferred sizes, especially related to columns spanning.
• the stylable interface is now much simpler and has less dependencies
• the Widget base class implements hover and active states (if the actor is reactive)
• all constructors return ClutterActor, since this is the most useful base type.

Try It

Although the new project started as a branch in the Nbtk source code repository, it now has it’s own git repository at git.moblin.org. I am also making tarball releases on the brand new download.moblin.org. I have released a first version for testing purposes and it is important to note that the project is not API stable yet.