Policy – …for the adult in you

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.

On enhancements which need changes to the EWMH

Some of the enhancements which have been suggested need some sort of hint to be set on windows. For example, the recent squib about a special style for warning windows could only work if warning windows were marked in some way, and at present they’re not. Similarly, drag and drop can only work better if the window manager is warned which clicks start a drag and which don’t. This too will need a new hint.

There are two ways this can be done. The simplest way is to use a hint whose name begins _METACITY; this doesn’t require us to talk to anyone. It’s sometimes one way of starting the process of adding a feature like this. Of course, it means that the feature’s unlikely ever to work with any other window manager.

The better and more extensible way is to make a new standard hint, one beginning _NET_WM. This means adding the hint to the Extended Window Manager Hints standard (the EWMH). Changing this standard means arguing it out on the wm-spec list. The maintainers would like not to be the only ones to raise new ideas on this list.

In either case, the toolkits (such as GTK) will then need to be updated to mark the relevant windows with the relevant hints, and finally the applications will probably need to be updated to use the new functionality in the toolkits. You can see, gentle reader, that enhancements like these are the source of more work than the average enhancement. They may nevertheless be worth the effort.

This entry exists mainly so that we can link to it when the issue comes up.

Photo © !!sahrizvi!! (back in Dubai) !!, cc-by-nc-nd.

Policy about theme versions

Metacity has a policy about enhancements which require changes to the theme format. Metacity has to be both backwards and forward compatible. In other words, it’s not enough that a later version of Metacity can run with themes intended for an earlier version. Earlier versions must also be able to run with themes intended for a later version.

In order to accomplish this goal, themes are kept in a file named metacity-theme-n.xml, where n is the number of the version of the theme format. A theme which supports a version should also have files for all the preceding versions, and Metacity will read only the highest version found which it can understand and leave the rest alone.

This works. However, if there were hundreds of theme versions, it would become unwieldy. So we save up enhancements and commit a bunch of them all together. The only time this has happened so far was in October 2006, when v2 was introduced. (Not many people are using v2, even over three years later, and even though users evidently want the features it brings. This may be because theme artists aren’t sure how to create them. One of the advantages of a theme editor would be that it would be able to take care of creating valid intermediate versions for you.)

Some enhancements still being suggested will involve changes to the theme format. For example, Screwtape has suggested a special window state representing windows which are running as root, so that they can be drawn using a different colour or something. Enhancements such as these will all have to be made on a branch and merged all together at some time in the medium future, perhaps next year. I have made a category to group posts about such enhancement requests into.

One of the big questions about v3 is whether it should be SVG-based– the so-called Vectacity format. This will quite possibly win us very little for the extra effort that will be required to mould SVG into a format which can adequately represent window decorations, so Vectacity may not happen in version 3, or at all.

Photo © Tim McFarlane, cc-by-nc-nd.

Notifisation

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.

Adding new titlebar buttons is always problematic for reasons given earlier.
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.
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?
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:

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.

Similar results would no doubt be common with a similar system for buttons.

Double-click to close

Window decorations on Windows 3.1 had no close button, so they used to let you double-click the menu button to close a window. When Windows 95 came along, they added a close button, but they kept the double-clicking behaviour. The ability to close a window by double-clicking the menu button has lasted right up until Vista; apparently Microsoft tried to take it out in the beta, but so many users complained that they left it in in the end.

Many *nix window managers support double-click to close for the benefit of people moving from Windows who learned how to close a window before 1995 and haven’t broken the habit yet. Metacity doesn’t, and in GNOME bug 83892 people have been saying it should. Often, they add that there’d be no harm in adding the behaviour because people who wouldn’t know about it wouldn’t trigger it. However, other people say that the effect of accidentally double-clicking the close button, and losing anything which happens to be in the window, is too disastrous to add a feature for such a marginal audience.

The HIG also (apparently) says that the top entry in a context menu should be the one triggered by a double click. “Close” is not currently the top entry in Metacity’s window menu.

A good while ago, Thomas Thurman provided a patch to add this behaviour, which has rotted, and today provided a current one. The current consensus among the maintainers is that this will not be added. However, you might be able to change our minds if at least one distro includes the patch. For example, Debian bug 381509 discusses the matter; if you know corresponding bugs in other distros, please let me know and I’ll add them here.

Photo © saba♫dija, cc-by.

The one where we argue about themes a lot

The Metacity theme format has been roughly the same for six years now. Many people are quite happy with it as it is, but we fairly regularly get people coming along and asking why it can’t do this or that and how they can make it do so. The trouble is that changing the theme format is a fairly large upheaval, and not something we’d like to do much. Recently, two ideas have been put forward to change all that by making it not our problem to change the format if some newfangled idea comes about that we don’t support already.

It’s GTK’s problem. Metacity doesn’t draw borders at all any more. This makes us a much more lightweight window manager, because all we’d have to do is keep out of people’s way and manage windows. It also means that the toolkit can interact more easily with the borders, leading to fun stuff like these Tango experiments. (Of course, this is a source of OOH SHINY, which gets people writing about GNOME more than anything else.) Or as alex-weej points out, we could do things like this using standard libraries. Downsides: non-GTK applications have a bit of a problem; we would obviously still need to figure out what we’re doing about window border theme file formats; all this will need a lot of coordination between people from different projects. However, it does have the seeds of great awesomeness within it.
It’s librsvg’s problem. Make a new file format where everything is based on SVG files. Feed these into librsvg, substituting results of expressions as appropriate. There you have a simple format which can do anything librsvg can do, and keeps on growing as librsvg keeps growing. (This is all possible; I’ve done a little bit of test work here.) Allow no other instructions but a set of SVGs (I have the way to do this in my head if anyone’s interested, but I won’t bother writing this down if this is going to be a blind alley). Add a script which can take out an SVG so you can edit it with Inkscape. Disadvantages: it’s an evolution, not a revolution; it’s slower than the current system in tests (though I haven’t tried to optimise it); it doesn’t let us do all the fun stuff the other option does.
Both.
Neither.

Your thoughts, Gentle Readers, both on the pros and cons of each and of the best choice? I shall be updating the post with your ideas, with attributions.

Photo: © swizzled, cc-by-nc-sa

Update: See desrt’s mockup inspired in part by this entry.

If the user will not come to the window, the window shall come to the user

Suppose you have two workspaces, and a window on each one. You’re looking at window A, so clearly window B is offscreen. You click something on window A, and window A attempts to present window B to you. What does that mean?

Let’s have two concrete examples:

0x01: You’ve clicked a link in Pidgin’s buddy window, and it’s attempting to present the chat window to you.
0x02: You’ve clicked a link in Evolution, and it’s attempting to present Firefox to you.

In 0x01, you want to stop looking at the old workspace and look at the new one. But you don’t want the windows to move off their workspaces. You want everything to stay where it is.

This is the way upstream Metacity currently works throughout. However, since Firefox is a tabbed browser,((I know Firefox has had tabs since 2002)) people have been asking whether this is the wisest course all the time. In case 0x02 above, in the old days, the browser would just have launched a new window in your workspace. People don’t like that now, because they want all their tabs in the same window. But if the user gets shoved onto the workspace of the existing window and then we add a new tab, eventually they’ll close it and then wonder where their mail went. (At least, that’s how I understand their argument; perhaps I’m mistaken.) As a compromise, downstream Metacity has now been patched in Ubuntu, Fedora, and possibly other places to make the window demand attention when this happens (i.e. go pulsy on the taskbar).

So we have multiple options when this happens:

Bring the window to the user, always.
Bring the user to the window, always. (This is what we do now.)
Make the window demand attention– in other words, apply the downstream patch. This is not the path of least resistance, since judging by recent feedback it appears to really annoy anyone using, say, Pidgin.
Tell the target application to deal with it. This would mean that Firefox could open a new window if you were on a workspace where it had no windows open and open a new tab if you were on a workspace where it had one already. It would mean finding some way of dealing with windows that didn’t co-operate. It would also mean, alone among all these solutions, that we’d have to find a way of communicating with the target application.
Ask the summoning application to give us a hint as to which of these it would like. This is my (Thomas’s) favourite solution. It will need a change to the EWMH.

Things which are not solutions:

Allowing the user to pick one and then requiring them to stick with it. As Havoc said, this is basically giving them a choice between “break Pidgin” and “break Firefox”.
Window matching. We do not do window matching. We are not about to start for an issue as small as this. That’s what devilspie is for.

Want to join in the ~~argument~~ fun? Dive in at GNOME bug 482354. The water’s lovely.

Photo credit: rofanator.

Zenity

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.

Client attempts to deal with stacking order considered harmful

I was asked on IRC to explain why it is that programs mostly cannot raise their own windows.

The mechanism:
gtk_window_show() indirectly calls XRaiseWindow. This causes a ConfigureRequest X event. Metacity will only honour this if:

the window belongs to the active application (but if there is no active application, any application can raise its windows), or
there has been user activity in the new window more recently than in the active window

In all other cases it will ignore the request. If the request is to raise a window (rather than to lower it), it will set the attention hint on the window which was trying to raise itself.

The policy:

Havoc noted in r460 that:

…in fact all client attempts to deal with stacking order are essentially broken, since they have no idea what other clients are involved or how the stack looks.

although that changeset did allow clients to raise themselves.
After a discussion based partly on this, GNOME bug 166395 in February 2005 established a consensus that client attempts to deal with stacking order should be ignored; this was implemented in r1936.
However, this left the program believing that it had alerted the user but with no change in the display, which was unhelpful. Therefore, in GNOME bug 305882 it was decided that when client attempts to deal with stacking order were ignored, the attention flag should be set instead; this was implemented in r2045.

This is not just GNOME being weird: here’s Lubos Lunak (the kwin maintainer) saying the same thing last year.

If you think this is a bad idea, figure out which part of it you think is a bad idea and then complain on that bug, or on wm-spec-list.