Theme-based button layouts

day 80Some window border themes, such as Radiance Chrome or any theme attempting to recreate the look of OS X, have the window buttons carefully designed as separate images which can’t be re-ordered without breaking the design.

At present, the order of buttons is under the control of the user, not the theme.  If a theme artist creates such a theme, they must tell the users separately to set the button_layout key in GConf to whatever is needed.  This problem is particularly acute because Ubuntu 10.04 Lucid Lynx uses such a theme by default, and accordingly sets button_layout to an unusual value; see Launchpad bug 532633 for much more discussion of this matter.  Users of Lucid who switch to other themes will still find the buttons arranged as before, which may confuse them.

GNOME bug 613522 suggests solving the problem by allowing themes to specify an override for button_layout.  This may be a workable idea.  However, according to policy, once a version of the theme format is released, it’s set in stone. So we can’t add new information to v2 themes: we can only move up to v3.

One possible workaround, however, is to allow a GKeyFile in the theme directory which specifies only the new value for button_layout:

button_layout = menu:minimize,maximize,close

That would allow newer versions of Metacity to honour the layout request while allowing older versions only to honour what’s written in the theme file.  Gentle reader, what are your thoughts on such a scheme?

Launchpad bug 542772 is another attempt to deal with this problem, by adding an option to the window menu to choose the layout.  However, this is unlikely to be implemented: the window menu is already cluttered, and besides the button layout is a matter for gnome-control-center to decide.

Photo © kygp, cc-by-nc-nd.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

6 thoughts on “Theme-based button layouts”

  1. I’d rather added preferred button layout in theme format v3. Though, not as set in stone layout but as recommendation. And warn users when they select a theme and it’s preferred button layout is different to current one. That would allow user to chose new layout for better appearance or keep current layout if user has hard time changing habits.

  2. Sounds like a good idea to me. Regardless of what people think of Ubuntu’s new theme, it’s bad that they had to do it by changing a global preference that affects all themes, and which can only be changed by obscure gconf settings. Going by some of those bug reports, they’re burning a lot of goodwill over that – as much from the difficulty of changing the setting back, as from the changed default.

    As to a solution, the GKeyFile option may be effective, but it sounds to me like a horrible hack – it *is* a change to the theme format, just done by putting the change in a new file instead. Why not just bump the format version, and take the opportunity to resolve any other bugs that would likewise require a format change…

  3. I’ve always felt that Metacity’s “themes can’t specify button order” was a direct consequence of the “themes shouldn’t be able to screw you over” theme model – a v2 theme could draw the ‘maximize’ button to look just like the ‘close’ button and make the actual ‘close’ button blank, but then the button order would be visibly screwed up and the user could still perform the intended action by clicking where the close button *should* be.

    If themes could change the button-order, it would be possible to create a theme where every button looked as it should but acted like ‘close’, which is a much bigger abuse of theming.

    I can think of two arguments for themes specifying button order – (a) some themes are designed to reflect some specific other theme design (such as another desktop OS, or some other physical item with a particular well-known button layout), and (b) Metacity’s current renderer for v2 themes has a number of bugs with rendering button groups that make it difficult to support all possible button layouts (I believe Fedora’s “Nodoka” theme exposes a bug where mousing over the close-button paints the “hover” background at the far right of the title-bar, regardless of where the button actually is, for example).

    In response to (a), I expect such themes would be sufficiently limited in appeal that manually setting the button order would suffice, and in response to (b) I think a better solution would be to just fix Metacity’s rendering bugs.

  4. I guess you already know how KWin approaches the issue, nevertheless I just post it here as I think it is an elegant solution.

    KWin has a default (menu, sticky on the left – help, minimize, maximize, close on the right) which can be overwritten by the decoration plugin, which can be overwritten by the user’s configuration choice. So it’s half controlled by the theme and half by the user – best of both worlds ;-)

    Of course that approach does not work for the case that the theme is designed in a way that reordering the buttons breaks the theme. No idea what to do about that.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.