July 2009 – …for the adult in you

Apologia for CSS

This blog is not about to become devoted to the single topic of experimental CSS theming, but some interesting points were raised in the discussion yesterday, which spilled over to Slashdot. We should have emphasised the experimental nature of the CSS subsystem in its name: perhaps “CSS On Window Borders Experimental Layout Language”.

Why? Some people have asked why anyone should be interested in CSS theming, given the existence of a stable and mature theme description format. The answer is that there are perhaps a couple of hundred people in the world who understand the Metacity theme format, and its complexity presents a significant barrier to entry for anyone else attempting to learn it. By contrast, millions upon millions of people have a basic understanding of CSS.

Efficiency. Some have pointed out that using CSS may cause great increase in memory footprint or execution time. Both of these are of primary importance to us. Furthermore, we know just how fast every theme renders using the standard engine. We are not prepared to introduce a new theme engine unless it is at least as efficient as the old one.

Mismatch. Some complain that the lists we gave of things we would need to ignore and things which would need to be added proved that there was a mismatch between CSS and what was needed. This is based on a misunderstanding of CSS as a language to style HTML. In fact CSS is a general-purpose styling language, and there are only a few places where it does not quite meet our needs. Even in those places the design is flexible enough to accommodate us.

The balance of power. Ray asked whether the structure of the window should be under theme control, as well as the styling. Some ask how we decide what is under the control of the CSS. We always need to find a balance between giving power to themes and giving power to users. Some things should be under theme control and some under user control, but it’s not trivial to decide which. Here are some examples:

Justification of the text on the titlebar. Currently this is entirely under theme control; the user can’t change it. Some people would like this to change.
The arrangement of buttons on the titlebar: which are on the left, which are on the right, and which aren’t shown at all. This is currently entirely under user control; the theme can’t change it. (This means that themes which attempt to look like OS X have to ask you to reorder your buttons so that close is on the left, since they can’t do it themselves.)
The font on the titlebar. Currently this is entirely under user control; the theme can’t change it. This among other things is something we’d need to reexamine with a CSS theming engine.

(“Under user control” means set in GConf and, generally, modifiable in the control panel. Some of these options cannot be set in the control panel at present, but that’s a separate problem.)

It may be true that windows should have a more flexible structure, and the ability to have the titlebar elsewhere is certainly something that’s been asked for from time to time. But assuming we should add such abilities, should the decision to use them be made by the theme, or should it be something selectable by the user in the control panel? These are deep questions.

Co-operation with GTK CSS theming. Yes: a good idea. Whatever they’re doing, we should probably try to share in it.

Complexity. Some have said that CSS is a complex system, and that anything implementing it will therefore also be complex and difficult to implement. This is an unwarranted assumption. Take a look at the table of contents of the CSS specification and see how little of it actually applies to a fully-functional system for description of window borders:

Syntax and basic data types; Selectors; Assigning property values, Cascading, and Inheritance; Media types: all handled for us already by libcroco.
Box model: we would need to implement this. Not terribly complex because we have a simple and unchangeable layout model.
Visual formatting model; Visual effects: these are complex, and we can ignore them entirely, since our layout needs are simple and unchangeable.
Generated content, automatic numbering, and lists: we would need to implement basic generated content (the easy part); we have no content to be numbered, and no lists.
Paged media: does not apply to us.
Colors and Backgrounds: the most complex part which we would need to implement.
Fonts; Text: partially applies to us (since some of it isn’t theme-controlled); mostly involves passing things into Pango.
Tables: doesn’t apply to us; we have no tables.
User interface: this is about setting cursors and things, and doesn’t apply to us.

Finally, we should probably reiterate that:

this is still an experiment, and not an official direction which Metacity is taking;
even if it ever happens, there’s certainly no decision to use WebKit.

Photo © johninbkk, cc-by.

Recent happenings in Metacity and Mutter

Here’s a quick round-up of interesting goings-on in the Metacity and Mutter worlds this week.

Sam H wants to implement tabbed windows in the window manager (so that each application would think it had multiple windows open, but the user would see tabs). The responses included “awesome” and “my personal hero”. Sam H plans to work on this on github and merge later.
Thomas wrote some basic window matching code. It needs some work.
Our post on the future of Metacity gained quite a bit of mournful attention, including an article in Linux Pro Magazine.

Photo © Tiara, cc-by-nc-sa.

More CSS thoughts

The recent discussion about CSS themes looks as though it may become one of the most interesting new ideas in theming in recent years. Here are some further thoughts on what may evolve from this.

An alternative. There is no general way, and few special ways, to convert expression-based v1 and v2 themes to the hypothetical box-based CSS themes. Therefore this would need to be an alternative theming system, without any upgrade path leading to it.

Document structure. CSS exists to style documents. In our case the document is purely notional rather than existing somewhere as a file, so we have great leeway in its representation. As I mentioned earlier, there are multiple ways in which we can use the ideas of element name, ID, and class to represent what we want to do. The guiding principle is not what would be easiest to implement but what would cause least astonishment to new theme authors. After some thought, I think such a layout might look like this:

<frame class=”maximized”>
<area class=”titlebar”>
<button class=”menu”/> <!– possibly others –>
<title/>
<button class=”minimize”/>
<button class=”maximize”/>
<button class=”close”/> <!– possibly others –>
</area>
<area class=”content“/>
</frame>

Feel free to disagree and to come up with alternatives.
There are no attributes on any element. Attempts to select on attributes will fail. The class is written as an attribute only for notational convenience: hence the italics.
Class is used instead of identifier because it’s not impossible that some implementation of this scheme will wish to have multiple buttons with the same function on a frame.

CSS3. Almost everything we already have can be represented in CSS level 2, and there is no immediate need for level 3. The sticking point mentioned earlier was the window icon being part of the title in Atlanta. However, this can be implemented in CSS2 as follows:

title:before { content: url("metacity:icon"); }

where metacity:icon is a magic URL which returns the current application icon. (But it might be wise not to use the name “Metacity” in this format, in case other window managers might like to use it; that goes for vendor-specific extensions, too. Maybe we should use -wm-.) That said, I am salivating over the possibilities of the new round attribute to background-repeat.

However, there is one piece of level 3 we absolutely need: we will need to allow border-radius at least on the frame, if not on the subsidiary elements.

Implementation. A format is independent of implementations, of course, but we need at least one implementation in order to test things. There have been a few possible implementations suggested:

webkit. This would work and reuse a lot of code, but I’m a little wary of embedding a web browser into the window manager.
nbtk. This seems to be missing a lot of what we need at present.
libccss. This has more of what we need, but still there’s a lot left open to us to implement, and a lot of what it implements we don’t need. It also doesn’t allow us to define new colours, which we need, and appears not to implement sibling selectors, which we will probably also need.
Using libcroco for parsing and cascading and building the rest ourselves. This is slightly more work than using nbtk or libccss, but may be necessary because of the particularly specialised nature of what we are doing here.

Justification. One of the things people seem very keen on is how the window title is justified. In the box model, the correct way to do this is with the auto keyword on the padding or margins of the title, and not using a text-justify declaration (since the title only has one line of text which fits snugly in its own content box). However, since people are bound to try to use text-justify anyway, perhaps we should allow them to do so, and merely interpret it as another way of setting the padding.

Things we need to implement: The whole box model; several kinds of border pattern; basic generated content for the title; various kinds of text styling for the title; ability to use pseudoclasses to prelight and press buttons.

Things we should ignore: Padding on the frame. Height and width set on the frame, or the content box. Perhaps: Any theme without proper metadata. If we’re doing things the same way as in v2, the font-family, font-weight, and font-style set for the title. (Or should we allow themes to specify a font?) Should we give a warning if a theme attempts to use anything we don’t support?

Photo © Jonathan W, cc-by-nc-nd.

The wider world of window border themes

After all this talk about theme formats, an overview of how they are handled in other window managers seemed in order. Your chronicler is no expert on most of these systems, so there may well be mistakes below.

As you probably know, Metacity uses a complex and powerful (perhaps over-powerful) XML-based vector theme format.
Matchbox uses a similar XML-based format, but the graphics are done using pixmaps.
Openbox uses a complex system of hierarchical properties, and again the graphics use pixmaps.
Emerald has a set of different engines each of which can be used to represent a theme in a particular way. For example, there is the pixmap engine for pixmap themes. Settings go into a keyfile called theme.ini shipped inside a gzipped tarball.
KWin themes are either pixmap themes, or written in C++ and compiled.
Compiz has no theming system of its own, but can use KWin, Emerald, or Metacity themes.
Awesome allows themes written in Lua using its Beautiful library.
Sawfish themes are written in Lisp.
fvwm themes are written in its own custom scripting language. Here are some rather beautiful examples (which I think should be ported to Metacity).
Enlightenment themes are in some strange binary format which your chronicler does not understand.
icewm themes are pixmap-based.
xfwm themes are also pixmap-based.
twm and ratpoison do not support theming.

Feel free to add more in comments.

(And then of course there are two examples from outside the free desktop, which are so large they are easy to miss:

OS X does not generally allow theming;
MS Windows only allows very basic theming and no redefinition of window borders.

One reader contacted your chronicler offline to ask whether a theme editor, and indeed customisable themes, were not a white elephant, considering that most users of most computers in the world have no ability, and perhaps also no desire, to remodel their window borders.)

Conclusions:

Most environments do not allow anything beyond very basic theming.
Most of the other window managers rely either on pixmap theming or express their themes using a programming language. The middle ground of using vector graphics is unknown outside Metacity. (Of course, in the world of gnome-shell, we could always express themes in JavaScript, but expressing themes in code brings a whole raft of security implications of its own.)
Nobody uses external standards such as CSS or SVG, except insofar as programming languages are external standards.

Photo © scazon, cc-by.

Further thoughts on extending the window menu

The previous post about extending the window menu caused a great deal of discussion. It would seem that our readers would be interested in an implementation. Thomas is considering working on this after the window matching experiments are more stable.

Now, we can imagine that any package might want to add menu options when it was installed, and delete them when it was removed. Let us not concern ourselves for the moment with how a menu option and its effects are represented, other than assuming that it may be represented by an ASCII string. Rather, let us consider the ways in which a newly-installed application may wish to add menu options. We are concerned with two kinds of menu option:

∀: these appear on every window menu, for as long as the application is installed. It need not be running. For example, Take screencast should be available when Istanbul is installed and removed when Istanbul is removed.
∃: these appear only on the menus of windows created by the application itself. For example, Play should appear on Rhythmbox‘s window menu, but not on other applications’ menus, even if Rhythmbox is running. (Otherwise, how would a user tell the difference between Rhythmbox’s Play and the Play of Totem?)

Users should have the option of disabling any ∀ options which are currently installed; the full set of ∀ options would be available in some kind of settings dialogue where a decision could be made about which options belonged on the list. It should be noted that Minimize, Maximize, Close, etc., are the ∀ of the window manager itself.

So, where should these settings be stored?

In X properties on windows: The ∀ options would be stored as properties on the root window, and the ∃ options as properties on the windows involved. This would be the simplest to implement, but who has the responsibility to set the property on the root window, and where does the data come from?
In GConf: This would only work for ∀ options. It’s presumably a better plan than keeping them on the root window, though, and we could still use X properties for the ∃ options.
In /usr/share/applications/*.desktop: This is the way which would integrate best with package management, but would cause rather a performance hit as all the .desktop files would need to be scanned when the WM started up, and then there would need to be some kind of particularly clever window matching to work out which .desktop file corresponded to which windows for ∃.

Some kind of hybrid approach may be best: we could keep the ∀ menu options in .desktop files, and have a utility program that was run when any package was added or removed, to update GConf with the values. Or perhaps this updating could be done in the control centre, when the user chose which subset of ∀ options they wanted. Then we could keep ∃ options as properties on the windows, and rely on the toolkits to update them (perhaps even by parsing the application’s .desktop file).

Photo © van swearingen, cc-by-nc-sa.

Two hundred

The Metacity blog has been going now for a little over two years, and this is our two hundredth post. We began at least partly as a place to keep an essay about building the tab list, and we grew from there, picking up the Metacity Journal, release notes, and the Bug of the Day feature along the way. Plenty of people said there was no life in Metacity, and then Iain Holmes came along and implemented the compositor; they said it again, and Owen Taylor created Mutter, and Metacity sprang forth with life anew. And the blog was there to record it all.

We hope you’re enjoying the ride, and we hope you stick with us for the next two hundred and beyond.

Photo © mag3737, cc-by-nc-sa.

Copper: an experiment with CSS

Further to our previous discussion of CSS, Thomas spent a few hours on sketching out a possible design for a CSS-based theme format, and on representing Daniel Borgmann‘s Human theme using it. This is an experiment, all very blue-sky and unofficial, and is quite likely never to lead anywhere.

The first question to resolve is how the interplay of element names, classes, and identifiers applies to us. For example, when styling the close button, is it:

a button with id=”close”, or
a box with class=”button” and id=”close”, or
a close with no class or id attributes?

For simplicity, we went with the last option. We represent the decorations of a window frame using a set of unique element names arranged into a particular hierarchy. Almost every element is a simple box; the exception is title which is textual.

We use libccss to parse the theme and also to apply certain of the box styles; this means that this experiment is drawn using Cairo. (It would have been possible but more complicated to use nbtk for styling, which would have meant this experiment used Clutter. This is more probably what a final working result would be like. An attempt was made to use nbtk but some of the more complicated styling options appeared to be currently unsupported.)

libccss supported background images and reasonably complex border drawing. There were two things we needed which it did not (yet) support, so we had to kludge those in:

text styling, for the title; we only bothered to implement justification. Our approach here is to use a simple text label for the title and to style it, rather than using explicit vector graphics as in v2. Effects like Human‘s shadowing would be implemented by something like CSS3’s text-shadow. More complicated arrangements like Atlanta‘s centred icons would be impossible.
the complete CSS box model; only borders were supported. We made a half-hearted attempt to support margin, and did not even touch padding. However, in so doing, we made…

A useful discovery: In doing this it became clear that there are two possible ways for a file format to describe vector graphics. Either the position of everything can be represented using arithmetic expressions, which is how the current Metacity theme format works, or it can use a hierarchical box model, as HTML and CSS do. One of our stated aims for v3 is ease of editing, and the box model appears to be a better fit for humans to understand in a drag-and-drop editor (as seen, for example, in Inkscape). Therefore, if we do not adopt SVG or CSS for v3, it may be worthwhile to look into box-based layout models even in a custom format.

Here’s one draft of the CSS for Human, and the results of processing it with this hacky and experimental code are shown on the right (with the real thing around it for comparison). Example of CSS-based approximation to the Human theme

Problems and challenges:

New properties. We are certainly going to need to invent properties which are unheard of in real CSS. (For example, corners will need to indicate the degree of rounding.) These properties should probably be marked in some way. Mozilla marks its new properties with a leading -moz; perhaps we should do something similar.
Dublin Core metadata. This could be implemented using custom properties on the toplevel “theme” element, representing the author, licence, and so on.
Named colours (especially those which refer to the GTK theme). libccss does not allow new colour names to be defined; perhaps we should ask for this. On the other hand, it does allow new callback functions to be created, so that you can write color: gtk("bg-selected") or something. This allows us to get the same effect at least within the CSS. However…
Pixmaps. This system is well-suited to defining pixmap themes, which are at least fast, easy to understand, and simple to manipulate. However, they are generally discouraged because they scale badly and don’t recolour well when the GTK colours change. There are two possible workarounds:
- Introduce custom properties to scale and colourise the pixmaps as appropriate. v2 is already capable of pixmap colourisation (it’s used quite heavily in Crux, since that is a pixmap theme, but rarely elsewhere).
- Use SVG images instead. This immediately brings up the problem of how to style these images: we could of course use this very CSS to style them, but then our custom callback functions to get GTK colours would still need to be honoured somehow.

Conclusions:

CSS has possibilities as a window border format: it is a standard and well-understood format and there are plenty of tools around to edit and parse it. However, it is certainly not as powerful as v2 and probably cannot be. That may not be a problem, as we said before.
As somebody mentioned earlier, research is needed to discover which features of v2 are commonly used, and therefore necessary in any possible v3. We need to make a big collection of themes and score each feature with how heavily it is used.
Box-based layout is simpler for humans to edit (and perhaps to understand in general) than expression-based layout.

The window menu

The window menu is the menu you see when you click the menu button (which usually has the window icon on it), or right-click the titlebar. An identical menu appears when you right-click an application’s entry in the task switcher on the panel, although this menu is owned by libwnck rather than Metacity and is manually synchonised. The contents of both menus are currently fixed. Let’s treat them as the same menu.

The menu currently has around a dozen options. What is the optimum length for this menu?

These are the current contents. Which of these should not be in the menu by default?

Minimise
Maximise
Move
Resize
Always on top (checkbox)
On every workspace / On only this workspace (radio buttons) ★
Move to workspace above, to the right, below, to the left (four separate options, only the applicable ones being visible) ★
Move to another workspace (leading to a submenu) ★
Close

Some say that the workspace options (★) are overkill. They are by far the most complicated options in the menu, and they take up a large amount of space even for people who do use workspaces. Perhaps that’s not everyone; if workspaces are something that only advanced users are aware of, maybe these options ought to be enabled separately.

There are other things we could put on the window menu, if it doesn’t get too crowded. What extra options would you like to see there?

Take a screenshot of this window
Share this window with another user using VNC
Screencast this window and upload it somewhere using Istanbul
Anything you can bind a keystroke to. (Nargery: This would be kept as a hint on the root window, encoded either as a keybinding name (e.g. “toggle_shaded“) or as a representation of an EWMH command.)
Similarly, application-specific options, given in a hint on the window itself: so your music player could have play, pause, and so on when you clicked its entry in the task switcher; consider how this could move towards replacing permanent notification applets, evolving into being part of notifisation in Metacity 2, and how useful it might be in gnome-shell.
By analogy with right-clicking on the desktop allowing you to set the wallpaper, perhaps “Edit window borders“, which would take you to a dialogue which let you reorder the buttons, modify which user-chosen options were in the window menu, pick a window border theme, and perhaps even do some light theme editing.
…your ideas here…

Towards a third version of the theme format: some design goals

When we add features to the theme format, they must be added all in one go for reasons which were explained earlier. We are currently on version 2 of the theme format. In case there is ever a version 3, here are some of our design goals. Not all of these may necessarily be met when and if it happens. These are not in order of importance.

Standard format. If possible, it should use standard file formats rather than custom ones. This helps build tools, it helps code reuse, and it helps users learn the format.
Editable. It should be designed such that it’s possible to write a theme editor which is easy to understand and use.
Delegation. It would be useful if at least some of the code to parse and render the theme files was in a pre-existing library rather than being part of Metacity itself.
Shareability. It should be at least possible to use the same theme format with various other window managers, which could perhaps be helped by keeping the code in an LGPL library.
Single file. There should be a standard format for keeping all files associated with a theme in a single file, at least for both distribution and installation. This will save the end user from ever having to deal with tar or zip.
Subthemes. It should be possible to write a theme which inherits some of its attributes from an existing parent theme.
Named colours. It should be possible to give identifiers and descriptions to a subset of colour constants so that the theme artist can override them on the fly. (This is perhaps already solved given that we can use colours out of GTK themes.)
Well-defined metadata. There should be visible metadata, including licence identifiers, which can contain a list of all authors as a theme gets remixed. Theme editors should make it easy to keep this up to date. In keeping with our use of standard formats, we should probably use Dublin Core for the fields and perhaps the same identifiers that DOAP uses for licences. The casual theme artist should never see any of this, of course.
Upgrade path. It should be possible to convert themes in version 1 or version 2 format to version 3 format automatically. Conversion from other WM’s formats would be a nice touch.
Minimum power. We don’t need to be able to do everything that v2 can do. We do need to be able to do everything that is commonly done in v2. (For example, v2 allows you to have a title “centred” ⅔ of the way across the titlebar. This has probably never been used, and it’s no big problem if v3 can’t do it. If it can’t centre the title in the middle, that’s more of a problem.)
Maximum power. It should not be possible for the theme to get in the user’s way. For example, it should not be possible to write a theme which obscures the contents of windows; otherwise it would not be possible to switch away from it. Neither should it be possible to solve the Towers of Hanoi in the theme engine. People have better things to do with their time.

Your thoughts on these and your suggestions for other goals are welcome, gentle reader.

Window matching experiment

At the Collabora party, Robert Ancell asked me how difficult it would be to implement window matching in Metacity. I decided this was an interesting question and spent an hour and a half today working on it. The results are now in the matching branch in GNOME git. If you’d like to download it and give it a try, please feel free.

It currently saves configuration data in a keyfile which contains one group per window, in this format:

[xlogo] x=287 y=178 w=250 h=231

This isn’t necessarily how it will end up: we could use GConf or perhaps some database-like format. It uses a modified version of the system suggested by Hongli Lai: if WM_WINDOW_ROLE is set, we use that to recognise the window, otherwise we use the window title– otherwise programs like xclock wouldn’t be matchable. The role or title is currently represented by the group name in the keyfile. The keyfile is saved at ~/.cache/metacity/matching.conf.

The system stores the position and size of every window at the moment it was closed. There is no need to edit configuration files by hand.

There are inevitably some caveats:

There is a bug such that when windows are restored they are offset by the size of the top-left hand corner of the frame. (In other words, the coordinates are misinterpreted as the client window’s position, not the frame’s.)
I haven’t tested this for scalability at all. Keyfiles might be very inefficient when you have hundreds of records for all I know.
It doesn’t know about workspaces, and it should; this will probably be the next thing I add.
If your window was minimised or maximised, this will not be restored, and it should be. This will probably be the next thing after that.
It might not be the best idea to write out the keyfile on every window close. Probably better to keep it in memory until the WM exits.
It might be useful to have a switch on the window menu to lock the position and size so it restores the same way when you reload it, in case you move it. On the other hand, this sounds like crack.

Should this branch be merged when the bugs are ironed out? Should it replace WM-based session files? These are good and interesting questions and ones we should discuss. Tune in next time, gentle reader! Or better, comment below.