Here’s a quick round-up of interesting goings-on in the Metacity and Mutter worlds this week.
Photo © Tiara, cc-by-nc-sa.
Lots of happy buzz about window managers here at the desktop summit. Some things people have said:
- Someone asked about implementing window matching. It’s always been our policy that it should be done with an external tool, but policies can of course be rethought. We might implement it in a branch and see whether anyone likes it.
- People are very excited about Mutter.
- Some concern was expressed by distros about whether enough machines will be capable of running gnome-shell: not just rather old machines but new ones which don’t have drivers yet. Some interest in a version that uses software rendering.
- Owen Taylor’s work on the git migration and on gnome-shell got a standing ovation at the AGM.
- Several patches got reviewed and committed at last in hack sessions.
- Some discussion of the use of CSS in theming.
- Someone raised the idea of a generalised EWMH testing suite that can be used with Metacity or Mutter. This sounds like a sterling idea.
- the rpnparser branch (which is a simpler and faster theme expression parser) is still viable, but since the theme format for Mutter isn’t decided, it doesn’t really make sense to merge it. But perhaps it still belongs in Metacity 2. What are your thoughts, gentle reader?
- the squib of the day section in the blog only deals with enhancements, and since enhancements in Metacity are less likely and moving things to Mutter is more likely, this section may be on hiatus for a bit.
Photo © jcorrius, cc-by.
Here’s a quick roundup of recent happenings with Mutter and Metacity.
Photo © Fernando Ariotti, cc-by-nc-nd.
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.
Photo © Greg Emel, cc-by-nc-sa.
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.
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.
GNOME bug 504729 suggests that switching with alt-tab, while using compositing, is too slow. This is because all the images of the windows are scaled on the client side before the window is displayed.
There are two possible answers to this problem.
Firstly, we can check for key release while scaling is happening, and if one is received, abort scaling and simply switch to the next application.
Secondly, scaling can be faster if it’s done server-side. This is possible but apparently there’s a common bug that it hits. Fixing this would also mean that we got to have animated previews easily.
I think the first solution should be added in any case, and the second should be added when it’s possible. I can add the first solution; I’m not sure I know enough to fix the second.
Photo © L. Marie, cc-by.
In GNOME bug 502491 someone is asking for an effect like Exposé on OS X. Iain, who wrote the compositor and ought to know, believes it would be better done as a separate program. There was an attempt to do this a while back, called Expocity, but nothing much came of it. Does this mean the bug is INVALID? Should the external program exist? Anyone fancy doing it?
Includes the memorable exchange:
“Every time I propose an enhancement, you say ‘go for it’. What are you doing?”
“I’m cooking my dinner. What are you doing?”
If it was a separate program, it could be activated by a mouse button or a keybinding in the same way that, say, Print Screen is currently activated. The program could move windows about using the EWMH, but I don’t see how an external utility could tell the compositor to scale the contents of windows down and back again. Iain, can you throw me a clue? Update: Thanks.
Someone said yesterday in the discussion on animated previews in the alt-tab switcher that an Exposé-like effect would be good for everything that animated previews would, and more.
Photo © Underpuppy, cc-by-nd-sa.
True to my promise, here’s the first bug/squib of the day.
In GNOME bug 567757 someone is asking for live previews in the alt-tab window. I can’t think why this would actually be useful, as opposed to pretty, and it sounds like a lot of work and a source of new bugs. I am therefore minded to say no. Can anyone think of why it might be worth the trouble?
Listen to this.
For everyone complaining about having to use gconf-editor to turn compositing on:
- Hit alt-f2
- Type metacity -c
- Hit return
THAT IS ALL.
It seems, from reading blogs and forums, that many people like the idea of using Metacity’s compositor but are scared of changing the deep magic of gconf. In addition, there is nothing in the “–help” text to show that we have a compositor at all. Therefore, I propose a new switch to override the current gconf setting for the compositor, which will display in “–help”, and for symmetry another switch to turn it off again.
I am not sure whether –compositor and –no-compositor, or –composite and –no-composite, would be better names.
What do you think? Tell us at GNOME bug 545323.