Tag Archives: GNOME

Learning from Fremantle Themeing

Back in Germany, found a nice flat in Berlin, and finally some time to reflect on the last few months.

Working on the Fremantle themes was (and is) a great experience, especially because we had the freedom to do things we could never do on the desktop without breaking compatibility to the myriad of applications out there. When you control the entire environment, practically everything becomes a possibility. But it also makes it painfully obvious when certain technologies make things harder than they really need to be. The current Gtk themeing architecture is certainly one of those technologies. Hopefully we can lean from it and create a better experience with Gtk 3 and Qt/Harmattan.

Pixels Still Matter

There has been a lot of talk about scalable interfaces, and using SVG. But the reality is, that even with incredibly high DPI mobile devices, the pixel is still the most important unit. This becomes most obvious when doing the common “ridge” effect, which at a minimum requires a two pixel line:Example button at different resolutions

You may argue that the buttons on the right are still “good enough” on a high DPI device, but when your graphics look even slightly fuzzy while your competitors’ graphics looks sharp and crisp, you need a really good reason to justify that (the philosophical high road won’t cut it).There is a time and place for vector graphics, and it is generally a good idea to keep your source images in a vector format, but the end result still essentially has to be a pixel-optimised bitmap image. Perhaps this will all change when we switch display technologies or reach DPI values in the four digit range, but I do not see this happening any time soon.

The bottom line is, any themeing architecture for current technology should make using pixmaps simple and efficient. Good performance is a must, as well as 9-slice scaling and overlay images. It must be possible to create pixmaps for precise dimensions, instead of expecting the engine to provide arbitrary sized images.

Sapwood does a fairly good job at enabling efficient pixmap themeing on Maemo devices, but in many cases we had to heavily bend the themeing architecture to create the desired result. This includes using (many) custom widget names to provide size hints, and in some cases Gtk widgets make the unfortunate assumption that certain images are expected to scale down to almost 1×1 pixels.

Applications First

Another big problem has been the Gtk philosophy of abstracting everything into building blocks. I won’t go into Gtk’s habit of abstracting even those building blocks into boxes and shadows, as I believe it is generally agreed that this doesn’t make any sense any more and hopefully will disappear in a revamp of the themeing structure. But that’s only a small part of the problem. To create the rich and detailed UIs that are starting to become generally expected, we really need to start with the design of the application first. We simply cannot build every application from a limited set of standard widgets. Take for example the Palm Pre’s notes application (which looks like a bunch of actual sticky notes on a chalk board). The Gtk way of doing it would be to assemble a bunch of standard elements, and then try to shoehorn these into the intended design with themeing rules. It doesn’t work.

The only way to create UIs like these is to use custom graphics and custom layouts. Fortunately this is easy to do when you are working with a limited amount of components on an integrated device, unfortunately Gtk makes it more difficult than it should be. E.g. to load a custom graphic, you basically have three choices: 1) Create custom themeing rules for your application and try to use standard widgets, 2) load the images directly from the theme folder, or 3) provide your own images and ignore the theme.

None of these options are particularly tempting on the desktop. 1) and 2) pretty much require all themes to take your application into account, otherwise you end up with missing images. 3) completely circumvents the theme and may lead to inconsistency. Fortunately 1) and 2) are reasonable options when you can keep the global theme and application layouts in sync, so we made heavy use of it. Unfortunately third party applications will still have to struggle with it.

Global Overload

A serious issue with putting too many application-specific elements into the global theme, is that the themeing rules become unwieldy and providing a complete theme becomes increasingly hard.

The Diablo GtkRC was huge, the Fremantle GtkRC is even bigger. Despite heavy optimisations and caching, this creates a significant slowdown at the start of every application. This is a shame considering that each application only uses a small subset of the available elements. In hindsight, it would have been better to keep the global GtkRC to a minimum, and provide custom rules for each application (even if they would largely duplicate each other), but this creates its own set of problems.

The large amount of images provided by the global template means that creating a new theme from scratch is incredibly hard. Not just because you have to re-do so many images, but also because it becomes virtually impossible to accurately predict where everything will be used (especially if you factor in legacy elements, which may not even be used in any available software).

Third party applications are completely out of luck, and limited to either re-use existing elements from the global template, or provide their own unthemeable and potentially inconsistent set of images.

The Future?

If I had the chance to design a themeing architecture from scratch (either for a specific device or the generic desktop), I would do it like this:

– Provide a lean global stylesheet, which suggests colours and a small amount of very common elements. I say “suggests”, because it would still be up to each application to ignore the defaults in isolated cases or completely.

– Applications provide their own graphics and stylesheet, that (together with the lean global stylesheet) are sufficient to display it properly.

– User themes can provide a custom global stylesheet, as well as override application specific stylesheets. I.e. themes selectively replace specific elements, rather than being forced to re-implement the whole structure.

The reason I say “stylesheet” is not an accident, as all of this is already  easily possible with CSS based systems. This is one more reason why I believe that the future of rich application UIs will be very heavily based on web technologies. It just makes sense.


Thoughts on the GUI

Before I start, let me get one thing off my chest. The progressbar animation in Ubuntu 8.10… It moves the wrong direction! Sadly the original default in Clearlooks was chosen from a poll, which had a subtle flaw: The progressbar wasn’t actually progressing, and that makes all the difference (as more people will hopefully realize now 😉 ).

Thank you, this was important.

Some observations about current trends in GNOME themes:

  • Desaturation. I see many many themes and mockups tone down the amount of colour in the general chrome, which also happens to be what Apple and Microsoft are doing. The popular Ubuntu Dust is a good example of this. Personally I find this style very attractive, so I welcome this development.
  • Another popular thing seems to be the reduction of borders and bevels. Many themes for a long time have tried to reduce the window border to a thin line, to create a cleaner look (as OS X does), which obviously fails to the lack of a consistent resize handle for GNOME applications. A workaround is to only make the bottom border thick, but this can look rather crude, especially when the application also has a status bar with a resize handle. Dust uses a fairly small bottom border which looks nice, but I find the usability of it to be fairly poor.
  • Along the same lines, people are trying to create a more unified look and remove the separation between titlebars and the application (again, Dust is a decent example for this). This makes a lot of sense, it doesn’t just look good, it also makes windows appear more like objects and it should increase the area of the chrome which can be grabbed. Of course the latter isn’t the case with Gtk. Another problem is that the menubar gets in the way. Creating a unified look that works well with and without the existence of the menubar is near impossible. Dust does a better job than most, but the lack of a separator on no-menubar windows still feels like a bad compromise.

So what could we do to support these trends? It is unreasonable to think that themers will come up with something truly remarkable, if we don’t provide them the means to implement popular concepts. I see this as a general problem in the GNOME art community, design generally seems to be seen as this thing that has nothing to do with programming. But providing a set of API functions and replaceable images just isn’t enough. Great design has to be a top to bottom effort. I’m not optimistic that we can ever rival OS X (or Windows even), if we don’t start talking to each other and take design seriously on all layers.

That said, here would be some thoughts:

  • Reconsider the menubar. Soon we are the only ones left who still stick to the traditional method of putting the menubar at the top of every window, right below the titlebar. It’s not just bad for design, there are other problems too. E.g. it really isn’t well suited for applications that have a very small profile, like a buddy list. And a small menu looks silly on a large window, which invites application developers of simple applications to add countless trivial menu items, instead of keeping the application menu nice and tidy. Let’s brainstorm some alternatives and let’s not be afraid of breaking consistency. We will have to do it sooner or later, if we don’t want to be trailing behind for all eternity.
  • Make the resize handle ubiquitous. Resizable windows should have a resize handle, not just to make “borderless” designs a real possibility. I regularly find myself unmotivated to resize a window if it got no resize handle. Marrying the resize handle with the statusbar seems fairly pointless to me. Let’s make it possible to integrate the handle in every possible window design (even if it has to transparently overlap the content area).
  • Pull the window frame drawing into the toolkit. The strict separation between frame and application causes many problems. The application should have complete control over the appearance of the window object, and there should be no difference in behaviour between different (often equal looking) parts of the chrome. This could also allow applications to tweak the entire window object, if the conventions are not ideally suited for a specific task. Consistency can be ensured by using common themes/layouts (more thoughts on this coming). This would also open up the possibility for many alternative menu designs (and of course “legacy” applications would still be supported with a separate frame).

I planned to write more, but this is already getting quite long (and I tired), so I will break it up into two posts. I will go more into my reasons for some of the more controversial thoughts and add some more thoughts about theming in general.

I am aware that this must look like armchair-criticism, but I am mostly just trying to express the various thoughts I’ve had in my head for a while now. I fully intend to make up for it in the near future with some actual work.