But it's just a mockup...
Jun 25 2008
From time to time I get asked why has GNOME become so conservative when it comes to widget theming. I generally answer that’s a good thing and simply an effect of the default theme to have matured and becoming usable to the majority of users.
At the same time, you don’t see many designers interested in theming gtk+. Maybe due to the inefficiency of the theming functionality in gtk, or rather ignoring its target audience. Themes in gtk still lie on the shoulders of theme engine hackers. While there are exceptions to the rule, usually those are the people who have their ‘good enough’ limits in visual design set very low. To show this more clearly, those are the people who call this a rounded rectangle:
In addition they would not find addressing corner case situations where one needs to remove a 1px padding between certain elements worth their time. In summary they should NOT be working on widget themes. While the following seems to be a general knowledge, I haven’t seen anyone summarize what we are actually lacking in the field of gtk+ theming. Here’s my suggestions based on my theming experience.
Drawing / box model. It should be possible to do some basic draw operations in a theme. A typical designer will be familiar with the web/CSS box model. From the theme it should be possible to draw a border, add a margin and padding to a widget/part, specify corner rounding solves most of the drawing needs if it’s accompanied by next item.
Bitmaps. Most important is being able to use an image as a background. In addition to the CSS tiling and positioning, it would be beneficial to be able to stretch the bitmap to the size of the box/widget.
Gradients. Drawing gradients as background/fill and box borders.
Compositing. An extremely important feature would be to properly composite objects with alpha transparency. We should be allowed to use RGBA bitmaps, setting a global opacity of a box/widget and being able to use alpha transparency in gradients.
Selectors.This one is slightly controversial, as the theming is already using a functional matching syntax, yet for a designer a CSS-like selectors would be much more understandable and approachable. With a tool described below, this may not be as important.
Debugger. For a web designer, one word would sum it up – Firebug for widgets. Being able to visually select a widget on a window and be able to find it in the widget tree(?) and see its associated style properties would be a dream come true. A tool to help form efficient selectors. A tool to measure speed implications of certain operations.
And if somebody would like to rewrite theming from ground up, I would suggest form/functionality separation. Having actual layout and positioning functionality in the theming, it would stop being a pain to conform to the GNOME interface guidelines. Application developers would worry about what type of input widgets they would like to use, not how to indent labels or how many pixels is the suggested padding between X and Y.
Update: Turns our Rodney has touched the topic around 3 years ago. While I do refer to CSS a lot, I’m putting the basic drawing capabilities to theme authors in front of all the other items. Having an intermediate layer in the form of a specific theme engine as cimi mentions in the comments is a good-enough short term solution I guess.