Sometimes, as in GNOME bug 562650, people ask for extra buttons on the titlebar to go along with the standard set. On the face of it, if you may bind a keystroke to some action, there is no reason why you should not be allowed to add it to the titlebar. The problem is, though, that somehow it must be drawn with a recognisable icon. This has led to the current policy that all themes must declare all possible buttons, and that no buttons are allowed outside that set.
Version 1 of the theme standard required all themes to declare how to draw menu, minimize, maximize, unmaximize (restore), and close. Version 2 allowed the addition of shade, above (“always on top”) and stick (“on all workspaces”). If you’re looking to add one of those functions, as GNOME bug 562650 actually is, the solution is to switch to a theme which has a copy in version 2; unfortunately, there aren’t many which have adopted this version. Bright and Crux both support it, though:
But requiring a theme to contain all permitted buttons restricts the number of buttons which can reasonably be permitted. In the future, how can we permit any buttons to be added? We could require unknown as a button type, which would certainly solve the problem of not being able to draw a button, but the user who was faced with two or three buttons bearing question marks might object. Or we could allow buttons we didn’t know to be decorated with text saying, for example, “stick“, which would work but wouldn’t be beautiful.
Alternatively, we could require all possible buttons to be declared in the base theme, Atlanta, and simply allow fallback. This is reminiscent of the way fonts work: a font may contain any Unicode character, but most fonts don’t attempt to cover the whole range. This means that people wanting to write any language which includes characters outside the ASCII range would often run into holes in their words– so the system will use a glyph from another font as a substitute. This often leads to ugly rendering, though, even for names from a language as common and well-known as French:
Can’t you just allow a theme to define any buttons it wants, and extend the theme spec to bind the button action to a specific DBUS method, then extend Metacity to listen for DBUS events from the theme engine? This would work for the simplest actions… more complex actions could be handled by having a scripting engine that would allow theme designers to bundle scripts with their themes (and then we’re back to using something like Sawfish again ;-) )
@Luke:
Certainly it’s a possibility to make actions bindable to DBus methods, and that goes for keybindings too. But I’d rather not have the actions available to me dictated by the theme I’m using– so I had to use a theme I didn’t like merely because it happened to be the only one which had a screenshot button. I realise people could hack up the XML to copy a button to another theme, but not everyone’s willing or able to hack XML.