overview – …for the adult in you

Trees

I know what you’re thinking: you thought this blog was dead. Well, I have to apologise for the lack of attention to Metacity recently. I’ve been trying to rectify this, and I’ll try to keep it up. There have been things sucking up my time, but they are mostly over now. I’ve closed a few bugs over the last few days; I’m trying to review all the unreviewed patches first. Next to go is GNOME bug 156543.

Posting to the Metacity blog was taking more of my time than actually working on Metacity, so I will try to cut back on the posts. But if someone from the GNOME project who has a basic idea about window managers would like posting rights here, that would be fine with me.

Some actual news: As well as the standard git tree at gnome.org, I have pushed Metacity to github and gitorious, so you can easily clone it if you need to. I will try to keep them up to date. I hope this is useful for people who would like to hack on it.

Photo © Federico, cc-by-nd.

How to help with Metacity

Someone was asking how they could help with Metacity. Here are some thoughts.

Why it’s important. Metacity is (for now) the official window manager of the GNOME desktop. Even though Metacity supports compositing, one of its strengths is that it can also run in a non-composited mode: plenty of people run Metacity who can’t or don’t want to run a compositing window manager. Then there are the people who use Metacity in compositing mode because they prefer it that way, often because Metacity’s maturity gives it the edge over other window managers. Even after Mutter becomes the official window manager, Metacity will remain important: the core of Metacity is the core of Mutter.

Things you should read.

You should read the HACKING file to get a decent overview of the project. This will also tell you how to go about debugging a window manager.
The project continues to be guided by the directions given by its creator, Havoc Pennington. You should read his policy on adding new features.
The two specifications which guide us the most are the ICCCM and the EWMH. They are not the easiest reading material, however, and you can safely put off reading them until you need to.
You should read this blog!
You should subscribe to the metacity-devel-list. It’s very low traffic.
If you’re new to fixing GNOME bugs, talk to the Gnome Love team. They’re good at helping newbies.

What needs doing. Metacity is a mature system, coming up to its ninth birthday, so there isn’t much new development to deal with. Day-to-day work falls into one of these categories:

Triaging new bugs. A bug is either a report of breakage or a request for an enhancement. Bugzilla will show you a summary of current bugs. There are a lot of them.
For reports of breakage, writing patches. This is really important. If you’re looking for something to work on, try searching for the “gnome-love” keyword in Bugzilla. This is used to mark bugs which are particularly suited to being fixed by newcomers to the project. There are currently six of them.
For enhancement requests, deciding whether they should go in or not. Usually the answer is “not” (see Havoc’s policy document). This kind of bug has traditionally been discussed in a “bug of the day” feature here on the blog, but this took more time to write than it took to fix bugs, and so it’s been quiet recently.
For enhancement requests which should go in, writing patches.
Reviewing those patches and deciding whether they should be committed.
Making releases.

New developments. But if it’s new development you want, you might be interested in helping out with:

Mutter. This is the forthcoming window manager and desktop system for GNOME 3. It uses Metacity as its core.
Cowbell. This is an attempt to reform the recondite window border theme system into CSS, which is much simpler to understand. This is stalled for the moment for lack of time and direction.

Photo © Chris Dixon, cc-by-nc-nd.

Bug of the day

There are several hundred bugs still open in the Metacity bug tracker. Over a hundred of these are enhancement requests.

During the first quarter of last year, this blog ran a daily “bug of the day” or “squib of the day” feature, where suggested enhancements would be discussed. Every so often, there’d be a roundup post where the fate of the bugs of the previous few weeks was revisited. The idea was that decisions could be made in the open rather than behind closed doors.

That was all very well, and it got the community more involved in discussing new features. However, there were two main problems:

Enhancement bugs are probably the least important kind of bug, and yet they’re the most interesting to write about. So this plan focused people’s attention on the least important things.
There’s only a few people who are willing to hack on Metacity, and they only have a certain amount of time available to do it. This plan meant that more time was spent writing blog posts than writing patches.

It might be useful to resurrect this feature, but not unless these two issues were addressed. Perhaps we should extend it to covering all kinds of bugs in order of priority, and instead of having daily posts have a strict rule that nothing new could be posted until the previous bug had been dealt with. Perhaps your chronicler should also delegate writing the posts, if some willing amanuensis could be found.

Photo © wiccked, 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.

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.

The future of…

The future of the project: It’s fairly clear now that Mutter will be an alternative window manager in GNOME 2.28, and the only window manager in GNOME 3. It is therefore taking over the reins from Metacity 2: effectively, Mutter is Metacity 3.

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.

Mutter integration: the story so far

One of the forks of Metacity is known as Mutter, because it’s Metacity with Clutter support. It’s used by the forthcoming gnome-shell project.

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

That Mutter should be developed using the GNOME infrastructure; and
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…

Blogger’s Choice Awards

Administrivia: I’ve nominated this blog in the Blogger’s Choice awards, more because it might bring in fresh readers and more insight than because I think it might win. Other GNOME blogs might consider whether they’d like to enter as well.

Administrivia

LiveJournal users may read the Metacity blog by friending its syndicated feed.
Photographers and other artists who publish work under the Creative Commons licences and who would like their work to appear occasionally in the “bug of the day” series here should contact Thomas by email (tthurman at gnome dot org). These would be interleaved with random beautiful things we find on Flickr, as usual.
Remember when there was a talking version of the blog (the little Listen to this links on every post)? Was that useful to anyone? Would anyone want it to appear on iTunes?

Zenity, sessions, and window matching

It has been pointed out that session management in Metacity is currently a bit broken. Firstly, it leaves a lot of useless files around. I assume that the only session file which is really necessary is the most recent one. Secondly, I recently found and fixed a bug where Metacity actually crashed when attempting to save a session. I wonder nobody had found it before, but maybe this shows that session management doesn’t get used, or at least looked at, very much. Thirdly, there’s still a bug in the session management that I found the other day while fixing Zenity support, wherein it tries to put up a dialogue before closing the session… and then always quits, so you can’t see what you were told.

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.