This post is a presentation of the ideas behind GNOME bug 521914.

At present, we ship a program called metacity-dialog, which is often to be found as the sole occupant of /usr/lib/metacity, and it gets spawned on the rare occasions when Metacity needs to ask the user a question. For example, if you attempt to close a window, Metacity asks the permission of the program which owns it; if nothing is heard back from that program within a reasonable time, Metacity spawns metacity-dialog to ask the user whether the window should be closed by force.

There are only three occasions when Metacity needs to ask such questions, and metacity-dialog has ad hoc code for each, with the usual problems attendant on ad hoc code. When there’s any difficulty with metacity-dialog (see, for example , Debian bug 427406), reproducing the fault can be pretty difficult.

GNOME also includes another program called zenity, whose purpose is to pop up and ask questions in just this way. Zenity is stable, polished, and well-understood. With the closing of GNOME bug 335763, zenity’s abilities are now a superset of metacity-dialog’s. It would be a simple matter to remove metacity-dialog from the codebase, and use zenity instead.

The only difficulty I can see is that in some distros it may not always be true that if Metacity is installed, zenity will be too, and it may be difficult to add this as a dependency. Of course, they can always patch and keep metacity-dialog; what do you folks think?

Photo by Dave Spellman; cc-by-nc.

2008-03-30: Metacity Journal: out like a lion

The White Hart, St Albans. Photo by Gary Houston, public domain.Here we are again. It’s been a hectic few weeks and the backlog has built up a lot, so we’ll just talk about the most recent couple of days.

There’s been an effort to get all unanswered bugs answered. The next step is to go through all NEEDINFO bugs and close as appropriate, and then group all policy questions together and try to find answers to them.

You are invited to share your opinion on, and help out with, any of the following:


  • GNOME bug 490668 – When Metacity starts up, nothing has focus. This isn’t beautiful, but more importantly it confuses accessibility software.
  • GNOME bug 491090 – on startup, minimised windows are not dealt with correctly; this was actually fixed in 2.20 and never fixed in trunk; now fixed
  • GNOME bug 511826 – we don’t pick up colour changes when GTK themes change (unless this is a GTK bug; someone needs to investigate)
  • GNOME bug 516088 – the drop shadow on the panel doesn’t show after login (for some people)
  • GNOME bug 517429 – workspace and ctrl-alt-tab switchers should be compositorified like the alt-tab switcher
  • GNOME bug 521914 – use zenity: see “Policy Changes”, below
  • GNOME bug 522166 – compositor was slowed down; Iain removed the delay; rejoicing
  • GNOME bug 523914 – the window drop shadow is not centred; it shouldn’t be, because lighting is always from the northwest
  • GNOME bug 525051 – bring us into line with new gnome-session rules about .desktop files
  • Launchpad bug #199402 – fix crash in the theme viewer (unusually, this bug was closed before it made its way upstream)

Policy changes

  • GNOME bug 499301: MetaDisplay is now a singleton. meta_displays_list() is replaced by meta_get_display().
  • GNOME bug 521914: we are strongly considering removing metacity-dialog and replacing it with zenity. A separate post on this matter is forthcoming.

New gnome-love bug

  • GNOME bug 524343: Fallback icons should be from stock. This is a trivial fix which should help you learn more about how Metacity works. Come and pester Thomas on IRC (marnanel on irc.gnome.org, channel #gnome) about how to do this if you want to try.

Checkins on trunk



  • On trunk: es by jorgegonz

Photo: The White Hart, St Albans. Photo by Gary Houston, public domain.


What is it ?

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

What’s changed ?

Thanks to Marco Pesenti Gritti, Iain Holmes, Josh Lee, Thomas Thurman, and Matthew Wilson for improvements in this version.

– Workspaces whose name is the same as the standard name, plus some string, are not cut off. (Thomas ) (GNOME bug 453678)
– Improve compositor performance (Iain ) (GNOME bug 522166)
– Draw wallpaper correctly when we start up with compositor (Iain ) (GNOME bug 522599)
– Don’t draw shadows on shaped windows unless they have frames (Iain ) (GNOME bug 505333)
– Several other smaller compositor fixes (Iain)
– Newly-created keep-above windows get focus (Marco ) (GNOME bug 519188)
– Allow moving workspace when dragging with modifier key (Matthew ) (GNOME bug 474195)

Kenneth Nielsen (da), Gabor Kelemen (hu), Vasiliy Faronov (ru), Daniel Nylander (sv), Maxim Dziumanenko (uk), Woodman Tuen (zh_HK)

Where can I get it ?


1dc28ef6b8da2662caff2b25eca3fda5 bzip2
bb0917ad4f4a9168e9cce6a60bd2dff2 gzip

Logging again

As I mentioned earlier, Metacity has quite a good logging system, but it’s almost never turned on; you have to set some environment variables. If someone reports a bug, we have to ask them specifically to turn it on, and then run Metacity again, and see whether the problem recurs. Federico and Luke suggested earlier that it could be supplanted by a gconf key, which users find easier to turn on and off than an environment variable; I think that’s a generally good idea.

I’m also floating the idea here of encouraging people to log all the time, at least on unstable builds, perhaps by making it the default. In that way, when something went wrong there’d be a logfile to refer to, even when you couldn’t recreate the bug. Obviously you’d be able to turn it off as well.

The files would be dated as Sabayon now can. Since we also have the ability (for session management) to dump a list of window details, it might be useful to dump them in the file when it got closed, too. Perhaps we could do some kind of logrotate thing so that the files didn’t grow like that fish (no, not our own Wanda).

Federico mentions that bug-buddy now has the ability to attach logfiles to bug reports; I think this would be enormously useful, and save us days of debugging time, but is still a bad idea because nobody wants a list of all the names and movements of all their windows for the past few hours attached to a public bug (some people may remember the unfortunate side-effects last year of having a stack trace of someone’s totem process attached in such a way). This is an existing problem, since it’s inherent to the use of logfiles in a window manager, and applies whether the log is supplied by bug-buddy or attached by a human. I’m having trouble thinking of a good way around it.

2.22.0 released

What is it ?

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

What’s changed ?

Jordi Mallach (ca), Kostas Papadimas (el), David Lodge (en_GB),
Jorge González (es), Gabor Kelemen (hu), Žygimantas Beručka (lt),
Vasiliy Faronov (ru), Maxim Dziumanenko (uk)

Where can I get it ?

Source code


MD5 Sums

8cb6d02cf66a1003532b4f5d2754d696 metacity-2.22.0.tar.bz2
08bc5077b328f15532b3132429ae26e5 metacity-2.22.0.tar.gz

Thank you to my daughter Riordon for helping me with the release :)

Session management

It’s time to talk about session management. It might even be interesting.

The basic idea is that when you log in, you want your desktop to look like it did when you logged out. There is a program called the session manager which starts up all the programs which were running when you logged out, and tells them that they’re being restored. It is smart enough to call the window manager first. The specs which govern this, if you really want to read them, are §5 of the ICCCM and XSMP.

You can compile Metacity with session management turned off, but most people don’t. If you’re running a copy of Metacity which knows about session management, and you’re running under a session manager, then the session manager will tell Metacity to save state when you log out, and give it a session string. Metacity will write out a single file named after that string, including the position, minimised/maximised state, size, and so on of each window. When you log back in, the session manager tells Metacity the name of the file, and it will reload all the information.

This is the icky part: remember how the session runs the window manager before any of the applications? Metacity now has a list of the windows that were open before you logged out, and none of them have been opened again yet, because the applications haven’t run. So Metacity keeps a list, and when the applications start and open their windows, Metacity will place them how they were beforehand.

So what we have here is window matching. Gentle reader, when you hear the words “window matching”, you have my permission to scream bloody murder. There is simply currently no good way to do it, and so we don’t. What do we match on? The window’s title, its role, its class, or what? We don’t do window matching in Metacity, because there is no good way to do it at present. Rather, we leave that to power-user tools like Devil’s Pie, where people who really want this behaviour and have enough time to specify exactly what they want in detail can do so.

But, as you’ve noted, we do do window matching in Metacity: we just pretend we don’t. And we don’t in general, but session management forces our hand. Every time we open a window (if there’s session management going on), we make a list of session windows which were opened by the application with the same session client ID and have the same resource name and class and the same role setting. Then we use the settings of any matching window which has the same title; if we don’t find one, we use the settings of any matching window which has the same type; if we don’t find one, we give up on window matching. (“The same” above includes the case where they’re both null.)

That was pretty complicated. Add to that complexity the fact that most applications don’t even set the role and resource settings to anything useful, and you begin to see why we (supposedly) don’t do window matching in Metacity.

Now, there are five possible ways forward for us:

1) Carry on as we are.

But we have this directory “~/.metacity”, which clutters up people’s home directories and has to be cleared if they want to remove all state. “~/.metacity” only ever contains the directory “sessions”, anyway.

2) Move metacity session data to “~/.gnome2/metacity/session”.

You might think this was the obvious way forward, but it isn’t going to happen because…

3) Move metacity session data to “~/.config/metacity/session”.

As GNOME bug 518596 points out, freedesktop.org is standardising hidden directory names across all desktops. The name to use based on this idea depends whether our session files are configuration data, cached data, or some other kind of data; this has been discussed on that bug and consensus seems to be that they’re configuration data.

However, if we’re going to move to another directory, we should also consider:

4) Move metacity session data to “~/.config/metacity/session” and change the format.

The existing format is based on GMarkup, but does pretty much exactly what GMarkup is bad at. It is also generally rather inelegant. It would be very simple indeed to replace it with a GKeyFile-based system; there’s almost a one-to-one mapping with the API in many places. We’d know that files in the new place were in the new format and files in the old place in the old, and after a few years perhaps we could drop support for reading back the files in the old place (how long do people keep session files around for, anyway)?

But the most radical solution is:

5) Abolish session management (or at least session management within the window manager).

This suggestion has come from a number of people. The reasons given so far are: XSMP has so many problems that we’re better off not implementing it at all than implementing it partially; we really shouldn’t be even attempting to do this because it involves window matching, which is an impossible problem anyway; Sven Herzberg apparently gave a talk at last year’s GUADEC that said that applications should be responsible for restoring their windows because they know how to do so and the window manager can’t know in general.

Photo by Mark Norman Francis, cc-by-nc.

2008-03-06: Caecilius est in horto, Metacity Journal est in blogo

Ye Olde Fighting Cocks, St Albans. Photo by Gary Houston, public domain.

2.23.1 went out today. Yay.


  • GNOME bug 326156 – the debate over what raise_on_click means in various focus modes rumbles on
  • GNOME bug 358674 (unidirectional maximisation) – Josh Triplett says that the TCA fix doesn’t go far enough, and that we should (also? or only?) consider FMB. Your reasoned responses are most welcome.
  • GNOME bug 520136 – also, unidirectional maximisation should be in the window menu
  • GNOME bug 358866 – gentle readers, does anyone know how to tell vim to use GNU coding conventions?
  • GNOME bug 479107 and GNOME bug 491114 appear to contradict one another. One of them should be closed…
  • GNOME bug 482354 – the question of whether opening up new windows should bring the whole app onto the current workspace dogs us again. Apparently the reason Firefox doesn’t exhibit the problematic behaviour with KDE is that kwin special-cases it!
  • GNOME bug 513281 – a problem with sloppy focus that’s hard to reproduce
  • GNOME bug 519188 – windows created and set to stay on top will lose focus, contrary to what you might expect
  • GNOME bug 520713 from launchpad bug 120818 – maximisation is messed up on xinerama. Your chronicler should cadge some extra screens in order to test these things.
  • GNOME bug 520792 – Jeff Schroeder came on IRC asking why metacity said he didn’t have the composite extension when he did. It turns out that composite+xinerama don’t work together under nvidia. Thomas suggested that Metacity could detect this case and print a helpful message so people were less mystified.

Checkins on trunk


  • You may recall GNOME bug 448183, which was in general about writing programs which did clever window management things when Metacity’s only doing the bare bones, and in particular about a forthcoming window management utility. Well, Mikkel Kamstrup Erlandsen has announced the availability of that tool in his blog (although it hasn’t formally been released).


  • On branches/gnome-2-22: en_GB by pwithnall, es by jorgegonz
  • On trunk: es by jorgegonz

Photo: Ye Olde Fighting Cocks, St Albans. Photo by Gary Houston, public domain.