Theme speed

The speed Metacity renders decorations depends on the theme in use. If you want to time all the themes installed and view them, use:

  • for G in $(locate metacity-theme-1|grep /usr/share/themes|cut -d/ -f5); do metacity-theme-viewer $G; done

Mean client-side times on my system to draw each frame, in ascending order of speed:

  • Prelude (the theme given in the previous post): 1.3ms
  • Bright: 1.9ms
  • Atlanta: 2.0ms
  • Mist: 2.1ms
  • AgingGorilla: 2.2ms
  • Metabox: 2.2ms
  • Simple: 2.3ms
  • Esco: 2.4ms
  • Glider: 3.7ms
  • Crux: 3.8ms
  • DarkRoom: 3.9ms
  • ClearlooksClassic: 4.3ms
  • Glossy: 4.5ms
  • Clearlooks: 4.6ms
  • Inverted: 4.6ms
  • Human: 6.0ms

A simple theme: Prelude

This is in answer to Stuart Langridge’s question about how the XFCE theme Prelude can be ported to Metacity.  Here is a quick attempt at porting it; I’ll be referring to that in what follows.  In order to install this theme for yourself, do:

  • mkdir -p ~/.themes/Prelude/metacity-1
  • wget -O ~/.themes/Prelude/metacity-1/metacity-theme-1.xml http://www.gnome.org/~tthurman/pics/metacity/Prelude.xml

I’m not talking about SVG here, because that’s still an experimental technology within Metacity, and I’m not talking much about version 2 of the theme format for simplicity.

We begin with the metadata, which isn’t unusual enough to explain.  Next comes the geometry, which is the key to the whole business: we only have the one, and it has rounded corners and no title.  We have to mark that there’s no title or Metacity will make space for one even though there’s no instruction to draw it.  If we were making a v2 theme, we could specify the degree of rounding, but v1 only allows you to say whether or not rounding is happening on each corner.

After the geometry we declare some draw_ops.  These are lists of instructions about how to draw each item.  All the draw_ops here are simply coloured rectangles.  One of them, “white”, is to draw the whole background of the window, but the entries for buttons stop slightly short in order to give the impression of gaps between the buttons but to leave the gaps clickable.  We declare the button colours twice in order to have a slightly lit-up version for the prelight.

I added a blue button for the menu button, but if you wanted you could use “white” there and have the menu button present but invisible.  In v2 you would need to declare three other button colours, which could get confusing.

Next, we only have one frame_style and it only draws one piece.  The differences between all the possible pieces can get confusing, but here we only wish to draw an enormous white rectangle over the whole window surface, and so we can use the “entire_background” piece and be done with it.

Then we have a frame_style_set which points in all cases to the one frame_style, and after that we simply declare that each window uses this one frame_style_set.  And there we have it.

There are many possible improvements, including dimming the button colours when a window isn’t focussed, and perhaps using the colours from the desktop theme instead of white all the time.

Edit: Stuart has tweaked the theme a little and uploaded it to gnome-look here.

Take that, Descartes

Die mosquito

Listen to this.

Here are two ideas with which I broadly agree:

  1. A theme format is less useful without a program to edit the theme files.  Having to modify XML by hand is not a prospect which most people relish.
  2. If there’s to be a third version of the Metacity theme format, it would be helpful if it was based around SVG, since theme files describe vector graphics and SVG has become a standard for such files.  It must not however sacrifice the ability of our current format to prevent themes making the computer unusable.

Back in August, I added simple SVG support to a branch of Metacity that I named “Vectacity“.  My project was shelved because of more urgent business elsewhere, but Iain has also done some work in this area.

In order to play around with the Vectacity format, I have since built a very simple version of an editor.  However, I have run into a theoretical problem for which I seek your insight, gentle reader.

There are certain problems which a theme file has to solve which are not faced by ordinary vector graphics.  One of them, which is easily answered, is the question of how to add the buttons which are currently in use to the titlebar, when this is not known in advance.  Another simple question is how to represent colours from the desktop theme.  A more serious problem is that the width and height of the window is not known in advance either, and nor is the width of the window’s title.  Metacity currently solves this problem using a simple expression language in which these variables can appear as terms.

However we solve this problem in Vectacity, it’s not a problem to modify the coordinates of elements according to the size of the window: the SVG in each theme file is going to have to go through a cleaner anyway before it hits the screen.  Some possible solutions include:

  • reuse. Use the existing expression language: <rect x="3" y="10" width="{w-3}" height="{h-3}"/>;.  This is how Vectacity currently works.  But this means we’re using the SVG namespace but including invalid SVG.
  • vectacity:expr. Mark the attributes which need recalculating, but leave precalculated values in the file: <rect x="3" y="10" width="997" height="997" vectacity:expr="width:w-3; height: h-3"/>.
  • stretchyspace. Subvert the concept of Cartesian coordinates by entering stretchyspace.  In stretchyspace there are 1001 coordinates; addresses below 0 and above 1000 are undefined.  Addresses between 0 and 300 are translated with respect to the left or top, addresses between 700 and 1000 with respect to the right or bottom, and addresses between 301 and 699 are as close to the centre as the address is close to 500: <rect x="3" y="10" width="997" height="997"/>.

Stretchyspace neatly keeps us SVG-compliant, but it’s a much less powerful representation than the existing system.  It’s true that the power of the existing system is rarely used to anywhere near its full extent, but there are existing behaviours which stretchyspace cannot represent.  In particular, titlebar decoration often places non-text graphics with respect to the length of the title:

Examples of the same titlebar shown in three themes
Fig. 1: Same titlebar, three themes.

The first line, for Crux, shows a graphic which has been pushed to the right by the length of the titlebar text.  The second, Atlanta, shows the window icon which is centred along with the titlebar text.  The third, Human, involves printing many copies of the titlebar text; this can be simulated in SVG using styling, but the other two are more of a problem, since they involve non-text participating in text flow.   If we’re using an expression language, this can be handled using coordinate substitution, but if we’re using something like stretchyspace, it will need to be handled in the SVG itself.  Non-text elements appearing in text flow may be possible in SVG1.2, but I don’t know how to do it in SVG1.1.  (Is there a way?  Do you know?)  For this reason, stretchyspace is not a useful answer for the representation of relative coordinates.

Another question we need to consider is whether external SVG editors should be usable.  There are many fine SVG editors around, such as Inkscape.  Allowing the use of one of these, with a tool which extracted SVG data and spawned an external editor, would permit people all the power of an existing application and save us the trouble of writing a new one.

If we are to use an external editor, though, we must consider how relative coordinates may be represented whilst within it.  One obvious conclusion is that we could use stretchyspace coordinates, but the same problems with title placement exist in this case as well; they could perhaps be worked around, hackily, since the title field in a saved SVG has a known length.  Other possibilities include using using the vectacity:expr field and copying its value into and then out of the description field of the relevant object, at a severe cost to usability.

If we are not to use an external editor, the value of using SVG at all becomes a little reduced.

Photo by kozzmen, cc-by-nc-nd.

Metacity 2.25.89

What is it ?

  • Metacity is a simple compositing window manager that integrates nicely with GNOME 2.

What’s changed ?

  • The maximisation key is a toggle. (Thomas ) (GNOME bug 343824)
  • “Unmaximise” is now called “restore”. (Thomas ) (GNOME bug 343824)
  • New thread handling call for gconf (Frederic ) (GNOME bug 565517)
  • Add screenshot commands back which had been removed (Yanko ) (GNOME bug 565343)
  • move_to_corner_se keybinding fixed (Thomas)
  • Windows on other workspaces which attempt to present themselves are marked as needing attention (Colin ) (GNOME bug 482354)
  • End the grab op when the user clicks the titlebar (Thomas ) (GNOME bug 401028)

Translations:

  • Jorge González (es)

Where can I get it ?

Photo: Lower Red Lion, St Albans. Photo by Gary Houston, public domain.

2008-12-23: Metacity Journal

Listen to this.

  • The patch in GNOME bug 482354 (the one about windows which present to other workspaces, which almost every distro has included) was finally committed.
  • GNOME bug 83892, double-click to close, is still being argued over; your chronicler would like to hear some usability experts discuss the reasons given for its inclusion.
  • GNOME bug 565241 is a small change to Atlanta, the default theme.
  • GNOME bug 160311, requesting the ability to change border sizes independently of the theme, has finally gained a patch which may well be included.
  • GNOME bug 345233 has the rather pleasant idea that “Take a screenshot” should be added to the window menu.
  • GNOME bug 343824 is a request for the default maximisation keybinding to be a toggle, which seems reasonable.
  • GNOME bug 564343, Launchpad bug 298463, and others have said there’s a problem with the print screen button on some distributions.  Still trying to track this one down.
  • GNOME bug 565409 believes there should be an option for alt-Tab to display all windows on all workspaces all the time.  What do you think?

We’re not doing the “around the blogs” section this time because they’re mostly repeats of what’s gone before.

Notifisation

Fire Notifier

Listen to this.

Launchpad bug 124326 requests a new titlebar button which minimises an application to the notification area rather than ordinary minimisation. Mostly this is currently done with the close button on the apps which support it, but some people feel it would be cleaner if these two functions were distinct. This action has been given the name “iconification” by some, but since this is the name the X specification gives to what we now call minimisation, I propose the ugly word “notifisation”.

There are four problems with this idea.

  1. Adding new titlebar buttons is always problematic for reasons given earlier.
  2. The EWMH specification is going to have to include a way to tell which apps may be notifised, and a way for the WM to tell an app to notifise itself.  This is going to require arguing out on wm-spec-list.  In itself, this is not a major obstacle, but it’s important to be aware of.
  3. It is unclear what the real difference between minimisation and notifisation is in practice.  And if there is one, why shouldn’t all apps be notifisable?
  4. Using the notification area for things other than ephemeral notifications– that is, using it as a cheap way to make panel applets– is contrary to the Human Interface Guidelines.  Perhaps the HIG is wrong, but then we need careful thought before we give the practice a stamp of approval by enshrining it in the EWMH.  Besides, there is talk of enforcing notification ephemerality.

Photo by The Joy of the Mundane, cc-by-nc.

Extra buttons

Listen to this.

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:

metacity-theme-2

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:

He was Edmond Dant(oops!)s... and he was my father.
He was Edmond Dant(oops!)s... and he was my father.
Similar results would no doubt be common with a similar system for buttons.