Thomas Thurman – Page 5 – …for the adult in you

Window matching experiment

At the Collabora party, Robert Ancell asked me how difficult it would be to implement window matching in Metacity. I decided this was an interesting question and spent an hour and a half today working on it. The results are now in the matching branch in GNOME git. If you’d like to download it and give it a try, please feel free.

It currently saves configuration data in a keyfile which contains one group per window, in this format:

[xlogo] x=287 y=178 w=250 h=231

This isn’t necessarily how it will end up: we could use GConf or perhaps some database-like format. It uses a modified version of the system suggested by Hongli Lai: if WM_WINDOW_ROLE is set, we use that to recognise the window, otherwise we use the window title– otherwise programs like xclock wouldn’t be matchable. The role or title is currently represented by the group name in the keyfile. The keyfile is saved at ~/.cache/metacity/matching.conf.

The system stores the position and size of every window at the moment it was closed. There is no need to edit configuration files by hand.

There are inevitably some caveats:

There is a bug such that when windows are restored they are offset by the size of the top-left hand corner of the frame. (In other words, the coordinates are misinterpreted as the client window’s position, not the frame’s.)
I haven’t tested this for scalability at all. Keyfiles might be very inefficient when you have hundreds of records for all I know.
It doesn’t know about workspaces, and it should; this will probably be the next thing I add.
If your window was minimised or maximised, this will not be restored, and it should be. This will probably be the next thing after that.
It might not be the best idea to write out the keyfile on every window close. Probably better to keep it in memory until the WM exits.
It might be useful to have a switch on the window menu to lock the position and size so it restores the same way when you reload it, in case you move it. On the other hand, this sounds like crack.

Should this branch be merged when the bugs are ironed out? Should it replace WM-based session files? These are good and interesting questions and ones we should discuss. Tune in next time, gentle reader! Or better, comment below.

Photo © Bob Fornal, cc-by-nc-sa.

Notes from Gran Canaria

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.

In addition,

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.

Recent Mutter and Metacity activity

Here’s a quick roundup of recent happenings with Mutter and Metacity.

Sugar Labs want to use Metacity (and not Mutter) in Sugar, and ran into the problem that undecorated maximised windows are necessarily fullscreened. A patch was provided to turn this off.
Two on tabs:
- Sam H wants to integrate tabs into Mutter;
- Ivan Denker wants to know whether the browser’s tabs and other controls will compete with the desktop’s controls, now that Firefox is rethinking their tab support.
Thomas Thurman asked about changing the theme format.
Owen Taylor fixed a crash if Mutter started on the first workspace.

Photo © Fernando Ariotti, cc-by-nc-nd.

Vectacity as CSS

Davyd Madeley made an interesting suggestion for redesigning the theme format. Assuming, as seems likely, we end up using Clutter, there’s no need to specify the structure of a window, which would need SVG. After all, all windows have a basically similar structure. Instead, we could style any item on the window usinga CSS file, parsed by libccss.

Don’t want a titlebar?
#titlebar { height: 0; }

Want a red background on the close button?
button#close { background-color: red; }

And so on. I think this is an interesting idea because it seems comprehensive enough to capture all the problems we face in theme design. I’m wondering whether it’s perhaps more powerful than necessary and whether it could cause themes to be able to be disruptive, though.

Photo © Sarah G, cc-by.

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.

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

Squib of the day: read your email

Metacity’s window menu is less than cluttered; there’s room for a fair amount of extra options in there. One that was recently suggested is an option to take a screenshot of the current window. However, that can be done already using keybindings. What about more adventurous use of the menus?

GNOME bug 472370 makes the reasonable suggestion that Metacity should contain an IMAP client. It would be possible to read your GMail inbox right from the system menu of any window. After all, Zawinski’s law points out that programs which cannot read email are overtaken by programs that can, and if Compiz contains an email client, your chronicler has yet to hear of it.

This appears to be a perfectly sensible idea, and our prototype is demonstrated in this post. It will be included in the next unstable version. After we iron all the bugs out of this, we might deal with focus fixes if we have the time.

Squib of the day: gentle fade

GNOME bug 105188 suggests that prelighting– lighting up buttons when you hover the mouse over them to confirm that it’s okay to press them– should fade in from the non-prelit state. This was originally said to require a change to the theme format, but in fact I can’t see that it does: any theme which defines a prelit state for buttons can fade gently from one to the other.

Perhaps there should be an option to turn this on, or perhaps it should just be the default way to behave and stay there.

Photo © quapan, cc-by-nc.

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…

Squib of the day: make the menu shorter

Someone who believed the system menu should be shorter raised GNOME bug 126674. The basic idea is that the options in the system menu which move the window to adjacent workspaces and to workspaces given their number are unwieldy and complicated.

Since these options all move windows, and since there is an existing manual move mode on the menu, the reporter suggests removing the workspace entries entirely from the menu and replacing them with some keypresses in manual move mode. For example:

switching to manual move mode and then pressing F5 could move the window to workspace 5;
switching to manual move mode and pressing Ctrl+Right could move it one workspace to the right
and so on.

It would undoubtedly remove some complication in the user interface, and free up some space for useful other options (such as “screenshot this window”), but perhaps at the cost of making common operations prohibitively difficult to find. The bug suggests that a popup window like the Alt+Tab window might give instructions about example keypresses. This would also make moving windows to another workspace with the mouse more difficult, but perhaps people should be doing that with the pager anyway.

Squib of the day: quit timeout

When you click the close button on a window, the window can have a hint on it which tells the window manager not to close it immediately. Instead, it should ask the window to close itself, and if the window doesn’t respond within a certain amount of time, it should put up a dialogue box which asks whether to kill the process which owns the window.

At present, this amount of time is fixed in Metacity to 2.25 seconds.

GNOME bug 121934 suggests that this timeout could be different in some cases:

If the window usually takes “a long time to exit”. This would require window matching.
Generally, because 2.25 seconds is too short a time to wait. On the other hand, if it was much longer, the user might have forgotten closing the window and would be surprised by the “force quit” dialogue.
When the system is under heavy load, so the program is less likely to be able to respond.