Creating Themes

(This is, more or less, a continuation of the previous entry)

Jono writes enthusiastically about the CSS theme engine work, and I would love to share his excitement. But I just can’t see it making a big difference. Don’t get me wrong, Rob’s work is fantastic and might lead to some very interesting things. It also promises to serve as a more flexible kind of pixmap engine in the future, and the familiar CSS syntax is certainly nice for us developers (and those of us sitting on the fence).

What I don’t see is, how it will dramatically lower the barrier to entry for GNOME theming, or even lead to better themes. When you look at the web, spectacular designs are (by and large) not spectacular because of CSS attributes, but because CSS allowed web designers to precisely position… pixmap images. Positioning, however, is the least of our problems in Gtk theming (or rather, we don’t have a choice in the first place). CSS attributes alone won’t help us create breath-taking designs, so by and large it will be things like the border-image attribute (a standard feature of the pixmap engines), which will drive most visually exciting designs. I believe this is a good thing and the right way to go, but the important part here is not the CSS syntax in the GtkRC, but that we get back to embracing image-based themes. Arguably, a more stream-lined syntax would even be easier to deal with for artists, even if they have previous experience with CSS. Just because many people know CSS, doesn’t mean that artists and designers will suddenly enjoy writing code. In the ideal case, they should never have to touch the GtkRC in the first place.

The only way I could see CSS making a real difference is if we would enable absolute themes as kamstrup calls it, which I believe are very badly needed if we want to see some actual creative spark injected into Gtk theming. A UI designer working with a graphics designer should be able to create compelling designs, but right now this just isn’t happening due to a ridiculous amount of abstraction. It’s not possible to create ideal interfaces because it is impossible to know how the actual elements will look like with a random theme, and it’s not possible to create ideal designs, because you have no control over how your graphics end up being used by application layouts. That’s why our themes feel dull and repetitive compared to the competition. There is no lack of artistic talent or enthusiasm in the GNOME theming community, there are just too many technical limitations (and sadly, CSS will not get rid of any of them). Look around GNOME theming sites and you will see a huge amount of creative ideas and compelling designs, but pretty much everyone trying anything out of the ordinary is running into problems sooner or later. Some we have been able to work around with terrible hacks and special cases in the theme engines themselves (which made pixmap themes all but obsolete), others we just accept or cave in and go for more generic, bland designs.

What set Clearlooks apart in the beginning was, that it tried to break with the monotony in many ways. So our comboboxes actually started looking like unique widgets, instead of a button put besides a text entry (a simple feat that frustratingly enough requires a lot of hackery), and many similar details which had generally been ignored by Gtk themes. I believe we managed to close some of the gap between our GUI and the competition at the time, but now they are running circles around us again. And I strongly believe that the core reason for this is that they actually design their user interfaces, while we generate them.

So what is this generic approach actually getting us? Perhaps it is easier to ensure a minimal amount of consistency like this, and the biggest advantage is probably that changing a theme will always affect the entire (Gtk-)desktop . But 1000 generic themes don’t out-weight a single really well designed one, and if we aren’t able to reach the optimal result because of our support for generic themes, then I believe that our priorities are terribly misguided.

A Proposal / Summary

Summing up all my thoughts on the subject, this is how I would like the future of GNOME/free-desktop theming to be like (you are welcome to flame my opinion, but in that case if you skipped to the end, please do me the favour of reading the entire post):

  • Drop the idea of themes as a central feature of the GUI. Instead create visual standards for platforms, similar to the HIG, allowing components to provide their own custom elements (e.g. graphics), as long as they comply to these developing standards. The community focus should be on maintaining and improving this common design. If more than one theme can be supported, that is great, just don’t work from the assumption that themes are arbitrary. Customization should still be possible (and would even be more powerful due to less limitation, just requiring more work like in the old days of xmms and friends), but if you do, you should be expected to be on your own and not necessarily get 100% consistency across the desktop.
  • Allow custom per-application/component layouts, ala Firefox (or at least considerably more flexibility than we have right now). Not every application has the same requirements, and it should be easy to create new interfaces specifically tailored to a new environment, e.g. a mobile device. Some kind of markup plus CSS and JavaScript perhaps. Just because this kind of flexibility has primarily been used for excessive irrelevant eye-candy in the past, doesn’t mean that we can’t use it for good (building fantastic user experiences).
  • Separate layout from “skin”. A layout should be specified by designers and implemented by developers (where both may well be the same person of course). It might involve a modified theme engine or module, and most definitely the theme RC file(s). The skin, or image layer, should be the only thing an artist ever has to touch, and could be used for easy re-branding or modified colour schemes. Even dynamic colours could be generated from this skin.

Most of all, I would like to see a new theming API/engine with the following features:

  • Image based. Cairo drawing operations have been a neat way to combine the flexibility of custom theme engines with some more attractive visuals, but this can’t scale forever. We are getting to a point where it becomes a serious consideration to use pixmap caching of complex drawing operations to increase performance, and this makes the entire reason to use coded drawing operations in the first place seem rather dubious. Images are what artists should work with, and the lack of flexibility is a problem we need to solve, not circumvent.
  • For the sake of this flexibility, the engine needs to support a wider range of definitions, e.g. various pixmap slicing and simple effects like gradients and shadows which can be applied on dynamic objects (think blurred text shadow) as well as unlimited compositing (e.g. blending various images and effects to create one widget). CSS with extensions is certainly suitable for this.
  • We need to solve the lack of contextual information (a button might be in an HBox inside a dialog, but does this make it a dialog button? There is too much guesswork involved in GtkRC pattern matching). A list of detail strings instead of a single one might be far more useful too. But there are certainly many good ideas out there, and it’s a well-known problem.
  • Massive simplification. The fact that a combobox is a composited widget containing an entry and button (or a button, separator, and icon, etc…) for example makes things unnecessarily complex, when all you really want is to draw one unique element. But most of all, it might have made sense to build widgets from shadows, boxes and lines in the past, but these days, it just doesn’t. Rendering widgets should not be any more complex than it needs to be and in the vast majority of cases merely involve the rendering of a single (sliced) image.

The engine that comes closest to this already is probably the maemo engine, sapwood. It may well be the most advanced Gtk pixmap engine right now (aside from its made-for-tablet limitations), and I believe that some of its concepts should be explored for the desktop (e.g. caching and serving pixmaps from a separate process to conserve memory and increase performance).

Right, this wasn’t a proper summary. Again, these are just thoughts I want to get out there. I know that many will disagree violently, but I do believe that this is an approach worth trying. I hope I will get around to hack on things that make some of this possible, and I hope that future revisions of the theming API will tackle at least some of the most glaring problems. Let’s make GNOME styling fun again.


14 responses to “Creating Themes

  1. +1

    I’ve always marvelled at how the operating system that is so often lauded for it’s great design and so well regarded by those interested in visual design is OS X – a system that IS NOT THEMEABLE. Sure, there are 3-rd party theme-systems available, but they are in the fringe.

    The most remarkable thing about this is that you never hear anyone complaining about the lack of theme-ability in OS X. Could it be that people don’t actually CARE if they can change the way a button looks as long as the button looks good in the first place?

  2. Just remember me. I’m a Gnome user who uses a 13″ 1920×1080 display, make sure things look at least as good as they do now for me.


  3. > Could it be that people don’t actually CARE if they can
    > change the way a button looks as long as the button looks
    > good in the first place?

    I think you’re correct, broadly speaking. Be prepared for a backlash from a vocal minority though. In this scenario you can provide limited customization which merely tweaks the parameters of the theme – for example the customizable colors of the “glass” in Windows Vista.

    > Image based. Cairo drawing operations have been a
    > neat way to combine the flexibility of custom theme engines
    > with some more attractive visuals, but this can’t scale forever

    Pixmap images? Bear in mind the problems with different display resolutions though. I know there has been some work done on resolution independence in Gtk. Qt already has the need because widgets in graphics-views are zoom-able. Windows Presentation Foundation was resolution independent from the beginning.

  4. Ironically, a CSS themable theme engine is getting close to XUL, the themable chrome framework of the firefox browser. It has had to endure its share of flames and criticism for being a bloated and slow thing.

  5. “Pixmap images? Bear in mind the problems with different display resolutions though. I know there has been some work done on resolution independence in Gtk.”

    Pixmap or SVGs, doesn’t matter. For now only pixmaps are a realistic option, but that’s an entirely different discussion. The reality is, that screen resolutions are not nearly high enough to ignore the pixel as a unit yet, and screen design is still pixel art in many ways.

    Even with cairo drawing ops we have limited ourselves to pixel values for borders, etc, so it’s far from true resolution independence and not much different to scaling, tiling, and slicing pixmap images.

  6. @Rob J. Caskey:

    wow – where can I find your 13″ 1920×1080 display? (pointer to make/model?)

    Variations in DPI from high (770/N800/N810) to low (30″ screens) clearly have to be taken into account. Where are the days where nearly everyone had 1024×768 screens ^_^.

  7. +1 Daniel.

    I think you hit the nail on the head at least with regard to not using technology just for the sake of technology (e.g., using SVG). The solution needs to focus on what the platform needs to provide to allow customization in the easiest way possible. And, widgets needs to be simpler, with the combo box being the poster child for a bad widget — I can’t believe how many theme engines the combobox looks clunky or terrible under.

    And as always, I’d still just be happy to fix the font issues…

  8. Custumization is one of the reasons to ditch Windows/OS X and switch to Linux. If you give that up, you give one of the compeling reaons to even look at Linux. This customizations are one of the reasons for accepting the limitations of it. Also customizations is one of the main reasons to to FOSS. Actually I don’t see much reasons to do FOSS if not for customization. So in my opinion you are totally wrong if you consider customization redundant.

  9. Much as I love Mathias, he’s not normal. I (who am wonderfully normal) never change the theme.

  10. I am sure there are many good reasons to work on FOSS that don’t involve customization. But FOSS by definition means that everything is customizable, which is great. It just shouldn’t necessarily be shoved into the user’s face.

    This reminds me of the saying that “Linux is about choice”, which is often used in contexts which makes me read it as something like “you can have any colour you like, as long as it’s rainbow”. If I happen to prefer unicolour, where is my choice? FOSS is just a way to write software, it should not dictate us which features or functionality to offer.

    Also of note might be that the “unthemable” Windows has a very active customization scene, which from the looks of it seems to be more diverse and passionate than ours. Customization for the GNOME desktop might be very accessible, but it’s not very good.

  11. +1

    There’s so many GTK themes which are just *okay*. There are a few good ones, and things have constantly been improving over time. You really just need an amazing graphic designer, who will design a theme/UI for GNOME, and do it with the right goals in mind.

    The designer is most familiar with Photoshop right? So they give you a final design, and then the programmer implements it. It’s just like web development. Maybe there are a few very talented people who are excellent designers and HTML/CSS experts?

  12. +1

    So right! Theming is a big limitation and the vast majority of the people never change from the default theme shipped by their distribution. And I’m a graphician! 🙂

  13. Pingback: GNOME Theming » Blog Archive » What is the CSS engine (not)?

  14. I’ve always said I’d love it if themeing just went away, so we could concentrate on the most important things on our desktop: usability, accessibility, speed. All of these are hampered by themeability. OS X isn’t designed to be themeable, Windows isn’t (really) designed to be themeable, and they don’t suffer one iota.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s