• 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.

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.

But what is to happen to Metacity 2?  Your chronicler believes that the community is better served by working on Mutter, and will do so.  Metacity 2 will not be actively developed, other than for bug fixes.  It is possible that some people out there would like Metacity 2 to continue, and if so they are welcome to fork the project and take over, and your chronicler will offer them as much support in doing so as possible.

The future of the bug list: There are five hundred bugs open against Metacity, more than one maintainer can humanly tackle.  Rather than simply closing them all, I propose working through them ten at a time and deciding for each one whether:

• alreadyfixed: it is already fixed in Mutter or gnome-shell (this is true of several enhancement requests), and so should be marked WORKSFORME or similar
• reassign: it is a Metacity bug that can be reproduced in Mutter, and should therefore be reassigned
• enhancement: it is an enhancement request which Mutter or gnome-shell could take on board; these should be discussed on the mutter-list and perhaps also in the squib of the day feature on this blog;
• metacity: it is a bug which should be fixed both in Metacity 2 and in Mutter;
• wontfix: it is an enhancement request which we WONTFIX.

These could be done as we go along, or could be marked with the relevant keywords and then group-edited.  Gentle reader, might you be willing to take on a block or two?

How can we best organise this?  Should we use the wiki and assign blocks to people?  Those of you here at GCDS, would you like to get into a room somewhere and work through the list together?

The future of this blog: I want this blog to continue.  I would like to expand it beyond its current focus:

• to include discussion of Mutter as well, obviously
• to include Mutter data in the Metacity Journal posts (these are largely automated and only edited by a human)
• to include news of interesting developments in window management (such as the current debate over compositor-specific hints in the EWMH)
• to have guest bloggers occasionally (again, any volunteers?)

One danger is that your chronicler spends more of their time writing blog posts than fixing code.  Suggestions for solving this problem are welcome.  It may involve delegation to someone who is better at blogging than coding.

Photo © Greg Emel, cc-by-nc-sa.

In a recent email to d-d-l, Owen Taylor gave two goals for the 2.28 release:

1. That Mutter should be developed using the GNOME infrastructure; and
2. That users will be able to choose between gnome-shell and ordinary Metacity.

Some possible ways of doing these were suggested:

• Merge Mutter and Metacity. Have Mutter as a separate compositor within Metacity.  Alternatively, as Colin Walters suggested, make Mutter a separate branch within Metacity’s DVCS.
• Import Mutter as a separate window manager. Remove all the parts in Mutter which are left over from Metacity and don’t work towards Mutter’s goals.  Metacity remains for people who don’t want to run gnome-shell.  Eventually it dies off.
• Forget about Mutter. Whatever we need to do would be done either in Metacity or in gnome-shell using JavaScript plugins.

One advantage of making gnome-shell play nicely with a standard (possibly Mutterised) Metacity is that it would still be possible to switch to other window managers: a great deal of ink was spilt in the discussion over whether users would mind switching away from Compiz, whether the Compiz developers would mind, and whether Compiz was the de facto standard window manager these days.  However, Owen says that gnome-shell requires tighter coupling with the window manager than is usual, and that this isn’t really an option.

The discussion continues…

Photo © Alexander Drachmann, cc-by-sa.

It seems to me that session management is three-quarters of window matching, but isn’t half as useful.  It further seems to me that if window positions were remembered properly during day-to-day use, they would be remembered properly across sessions.  This seems to be a rather compelling argument for dropping session handling entirely and adding some kind of window matching in its place.  After all, it wouldn’t affect our claim to be a lightweight window manager to drop one broken feature and add a more useful one instead.

Photo © TheBusyBrain, cc-by.

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:

He was Edmond Dant(oops!)s... and he was my father.

Some good properties to use for this are:

• SM_CLIENT_ID, which is set by the session manager for a particular instance of a running program. XSMP says that “a unique value called a client-ID is provided by the protocol for the purpose of disambiguating multiple instantiations of clients.”
• WM_WINDOW_ROLE, which is optional.  The ICCCM says that “the combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions.”  If there is no WM_WINDOW_ROLE, the ICCCM tells us to fall back on WM_CLASS and WM_NAME…
• WM_NAME is the window title.
• WM_CLASS is a two-part property.  Let’s call these Instance and Class, although these aren’t the real names. Instance is generally the name of the program, although it can sometimes be set on the commandline.
• Class is “the general class of applications to which the client that owns this window belongs”, i.e. the brand name of the program (rather than “editor”).

Metacity does not currently do window matching for three good reasons.

1. Separation of concerns: in-process or not?

The EWMH allows us to do window matching outside the WM, and in fact this is what Devil’s Pie and gdevilspie are for.  They have all the other problems, but they’re not part of the WM, and if they crash they don’t bring the WM down.  It appears that because this can be done outside the WM it should be.  (Isn’t this fun?  We can pretend we’re the Hurd.)  Feel free to argue the point, of course.

2. Separation of concerns: app or WM?

It is also possible that nobody except the application itself knows where its windows should be placed, and that everything should be left up to the apps (and in practice the toolkits).  This would allow us to do away with session management entirely.  Certainly it would mean that it was none of Metacity’s business.

3. Paucity of distinguishability: who sets what?

Devil’s Pie requires you to set up rules to identify windows.  Doing window matching at the window manager level implies that the rules are written for you automatically.  This wouldn’t be a problem, except that applications set the attributes above very inconsistently.  Although WM_NAME is always set, it isn’t necessarily reliable– for example, gedit adds a star to it when you begin editing a document. I believe therefore that we cannot use it in automated window matching.

As to the others, let’s introduce a notation: Role|Instance|Class.  If Role is missing, we write [NONE]|Instance|Class.  Here is a program called same.c which will print these values for you.  Some common examples:

• Firefox sets browser|Navigator|Firefox in all cases.  It is therefore not possible to distinguish Firefox windows from one another except by WM_NAME.
• Thunderbird sets [NONE]|gecko|Thunderbird-bin, but it usually only has one window open.
• nautilus sets [NONE]|nautilus|Nautilus and it is therefore impossible to tell the difference between Nautilus windows except by WM_NAME.
• inkscape sets [NONE]|inkscape|Inkscape similarly.
• gnome-calculator sets [NONE]|gnome-calculator|Gnome-calculator.
• gnome-terminal sets gnome-terminal-SOME-LONG-STRING-OF-NUMBERS|gnome-terminal|Gnome-terminal with the string of numbers different each time.  This gets an A.
• epiphany sets epiphany-window-SOME-LONG-STRING-OF-NUMBERS|epiphany-browser|Epiphany-browser with the numbers differing.  Another A.
• The GIMP sets gimp-XXX|gimp|Gimp where XXX is “toolbox”, “dock”, “tip-of-the-day”, etc.  This gets an A+.

Please feel free to comment with more results and I’ll add them.

Conclusion

• People often complain that Metacity doesn’t do window matching.
• There are many reasons why it shouldn’t (but feel free to disagree in comments).
• Window matching of any kind is needlessly difficult because the important properties are set inconsistently.
• Therefore for the sake of window matching in general, whether we do it in Metacity or not, it would be a useful exercise to patch all programs which don’t set roles as well as the GIMP does.  (gtk_window_set_role() is the relevant GTK function; it’s not widely used.)  Perhaps this could become a GNOME Goal.

Photo: Glass pane, shattered, © nchenga nchenga, cc-by-nc.