Letters – …for the adult in you

Come calm content serene and sweet

Most themes place the icon of the current application somewhere on the titlebar. Some operating systems (notably OS X) allow you to drag this icon as if it was the very file which is being viewed in that window.

This behaviour has been suggested for Metacity in the past. One of the two main problems with implementing it is that we have no way to identify the document being viewed in a window; we only barely have a way to identify the application.

In a blog post last week, Michal Hruby suggests a new window property to indicate the URI of a window’s current document. This spilled out onto wm-spec-list this morning. (“NEW” in the title is a typo for “NET”.)

Such a property is a matter for the toolkit to set, rather than the window manager. But if it was available, it would make the lives of window managers a little easier: not only would it make the window icon dragging possible, but it would also allow window matching by document or even document type, as well as by application.

Photo © Glamhag, cc-by-nc-sa.

The order of windows in alt-tab

When you press alt-tab under Metacity, the windows you see in the switcher are displayed in most-recently-used (MRU) order, except that minimised windows are always sorted to the end, and urgent (“needs attention”) windows are sorted to the beginning. A comment in the source describes this as “Windows sellout mode”.

In a recent blog post, Aza Raskin suggests using Markov modelling to learn which applications you commonly switch between, so that they will be in the right place when you need them. For example, if the system learns that you most often switch between gedit and firefox, then when you are using firefox, gedit will be the first application in the list.

Your chronicler believes the readership of this journal may be interested in discussing the idea. Anyone who wishes to implement it may count on all the help and advice they need from the Metacity maintainers.

Thanks to Arun Raghavan for bringing this to our attention.

Photo © Kevin Dooley, cc-by.

Setting the button order

Ubuntu Lucid Lynx was released last week. It modifies the order of the titlebar buttons so that they all appear on the left-hand side. Some people would like the buttons in another order.

This post explains how to change the order of the buttons.

Firstly, decide which buttons you want:

Here are your choices.
Only the top four are available in every theme. Themes which support all the button types include Crux and Bright.

Take all the names and separate them with commas. However, for the gap in the middle where the title goes, use a colon. Thus for the traditional order:

menu:minimize,maximize,close

Now open a terminal, and type:

gconftool-2 --set /apps/metacity/general/button_layout --type string menu:minimize,maximize,close

or whatever order you prefer.

It has also been suggested that we might allow button order to be set by the theme, so the default theme in Lucid has the buttons on the left and the other themes have them in the traditional order.

Photo © Debora, cc-by-nc-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.

Tabs

In the comments to a previous post, we were asked about implementing tabs in the window manager. Calum pointed out that the HIG recommends against applications adding their own document-level tabs on the grounds that this is a job for the window manager. Yet the window manager has never risen to the challenge, and very many applications do in fact implement document-level tabs.

Implementing this will fall into three parts:

there must be a way of identifying groups of windows which may be tabbed together (we might, for example, use WM_CLASS);
there must be a display listing all tabs in the window border below the title (in a first revision, this could perhaps be done using the system menu);
there must be a mechanism for unmapping all but the selected window, and, when appropriate, for reconfiguring the unmapped windows to match the mapped window (that is, when the mapped window is resized or moved).

There have been some volunteers willing to do the work in the past, but no word yet of working code. It should be a large piece of work, but not a monumentally huge one. Again, if anyone wants to help now, abundant assistance is available; this may be something the maintainers could work on, but not until the bug queue has been reduced a little more.

Photo © emdot, cc-by-nc-nd.

Future directions of Cowbell

Future directions. Here’s where Cowbell is going next:

The existing functionality is going to be moved into a library called libcowbell. Very little will be changed at this point from what we already have. (But there will be some extra tests.)
A release of the metacity-cowbell branch will be made that can use libcowbell.
A release of real Metacity will be made that can use either libcowbell or conventional themes.
Development of libcowbell can continue. (I expect pseudoclasses to be among the first things added.)

More more cowbell. Iain has pointed out an existing GNOME-based project called cowbell. I hope the fact that this project will be libcowbell will be enough to avoid confusion.

Feedback on feedback. Screwtape has reviewed the existing cowbell documentation in a web page here. Here is my feedback on the feedback:

§3: I did start out by showing the structure as pseudo-XML, but people commented as if the window borders were the result of rendering that XML (as if it were XUL, or something similar), so I think it may be misleading.
§3: I dithered over using the ID or a class for this sort of thing for quite a while. In the end I went with a class because we use classes for buttons (since they may repeat) and it seemed as well to use the same design for areas, and because you may have more than one content area visible at once, even if they are on separate windows. But I may have been wrong, and I invite opposing opinions.
§3: buttongroup: I really like this idea. But AFAIK libccss doesn’t yet support last-child etc (see next…)
§3.1: I want our CSS support to be up to level 3 wherever possible. However, we are constrained partly by what libccss is currently capable of. Of course we can patch libccss too! Backgrounds and Borders is largely supported by libccss, though.
§3.2: Unpainted areas are transparent (though if the frame is opaque, you’ll just see the frame through them).
§3.3: font-size is important; what should the interaction be between the font size set in Metacity gconf and the font size in the theme? Just use the theme font size for scaling as in v2?
§3.3: button heights: I think I didn’t explain myself properly here. You can (should) set height and width on buttons. But these only serve to establish an aspect ratio. The height is always calculated from the titlebar height at present. Perhaps this is overly confusing.
§3.5: :focus pseudoclass: perhaps this should be set on all elements in a focused window. Or perhaps just the frame and we can use the descendant selector.
§3.5: :disabled — hadn’t thought of this, good idea. TMTOWTDI.
§3.5: I’m not sure libccss supports :not() (but maybe it does!) If so, yes, we should use it. It’s far better to work the way people expect us to work.
§3.7: I hope we support SVG too. It would be extra nice if it could be styled with the same CSS somehow.
§3.8: I really want mm and em as well as px. I’m not certain libccss knows how to do this, but I will check.
§4: Nobody’s really tried to put Dublin Core data in CSS before, and I’m probably not doing it the best way. I worry that including a required custom XML file will be slipping back into using custom formats, though. Maybe we should use an @rule. Or specially-formatted comments. Or maybe we should give up on the whole required metadata idea.
§4: I like the idea of specifying alternative stylesheets, though metadata in the stylesheets themselves could also do this.
§6.1: yes, we really need a default stylesheet. I’m not sure what should go into it. I will think about this and include it in the first libcowbell release.
§6.2: okay, we’ll avoid data: URLs.
§6.2: let’s implement the single file doctrine by allowing any file in ~/.themes/ThemeName/cowbell/ThemeName.tar to be treated as if it was in ~/.themes/ThemeName/cowbell/. I think we can get that in the first libcowbell release too.
§6.5: I really like Firebug. Are you thinking we could use Firebug itself, or just copy its UI?
§6.11: Maybe we could also modify hue/saturation/value directly in the URL thus: url(‘file:fred.png?hue=#f00’)?
§6.13: I was thinking of themes which, say, repeat a pattern an integral number of times on the otherwise empty part of the titlebar, scaled to fit; this wouldn’t be possible using border-images, but would work fine with filler. On the other hand, perhaps this is overkill.

Feedback from everyone reading this, on the above and on the original document, is very welcome.

Maybe we need to take over a little piece of live.gnome.org to hash all this out. Or maybe we need a mailing list. I’ll wikify all this tonight and then post about it here.

Photo © Honza Soukup, cc-by.

Apologia for CSS

This blog is not about to become devoted to the single topic of experimental CSS theming, but some interesting points were raised in the discussion yesterday, which spilled over to Slashdot. We should have emphasised the experimental nature of the CSS subsystem in its name: perhaps “CSS On Window Borders Experimental Layout Language”.

Why? Some people have asked why anyone should be interested in CSS theming, given the existence of a stable and mature theme description format. The answer is that there are perhaps a couple of hundred people in the world who understand the Metacity theme format, and its complexity presents a significant barrier to entry for anyone else attempting to learn it. By contrast, millions upon millions of people have a basic understanding of CSS.

Efficiency. Some have pointed out that using CSS may cause great increase in memory footprint or execution time. Both of these are of primary importance to us. Furthermore, we know just how fast every theme renders using the standard engine. We are not prepared to introduce a new theme engine unless it is at least as efficient as the old one.

Mismatch. Some complain that the lists we gave of things we would need to ignore and things which would need to be added proved that there was a mismatch between CSS and what was needed. This is based on a misunderstanding of CSS as a language to style HTML. In fact CSS is a general-purpose styling language, and there are only a few places where it does not quite meet our needs. Even in those places the design is flexible enough to accommodate us.

The balance of power. Ray asked whether the structure of the window should be under theme control, as well as the styling. Some ask how we decide what is under the control of the CSS. We always need to find a balance between giving power to themes and giving power to users. Some things should be under theme control and some under user control, but it’s not trivial to decide which. Here are some examples:

Justification of the text on the titlebar. Currently this is entirely under theme control; the user can’t change it. Some people would like this to change.
The arrangement of buttons on the titlebar: which are on the left, which are on the right, and which aren’t shown at all. This is currently entirely under user control; the theme can’t change it. (This means that themes which attempt to look like OS X have to ask you to reorder your buttons so that close is on the left, since they can’t do it themselves.)
The font on the titlebar. Currently this is entirely under user control; the theme can’t change it. This among other things is something we’d need to reexamine with a CSS theming engine.

(“Under user control” means set in GConf and, generally, modifiable in the control panel. Some of these options cannot be set in the control panel at present, but that’s a separate problem.)

It may be true that windows should have a more flexible structure, and the ability to have the titlebar elsewhere is certainly something that’s been asked for from time to time. But assuming we should add such abilities, should the decision to use them be made by the theme, or should it be something selectable by the user in the control panel? These are deep questions.

Co-operation with GTK CSS theming. Yes: a good idea. Whatever they’re doing, we should probably try to share in it.

Complexity. Some have said that CSS is a complex system, and that anything implementing it will therefore also be complex and difficult to implement. This is an unwarranted assumption. Take a look at the table of contents of the CSS specification and see how little of it actually applies to a fully-functional system for description of window borders:

Syntax and basic data types; Selectors; Assigning property values, Cascading, and Inheritance; Media types: all handled for us already by libcroco.
Box model: we would need to implement this. Not terribly complex because we have a simple and unchangeable layout model.
Visual formatting model; Visual effects: these are complex, and we can ignore them entirely, since our layout needs are simple and unchangeable.
Generated content, automatic numbering, and lists: we would need to implement basic generated content (the easy part); we have no content to be numbered, and no lists.
Paged media: does not apply to us.
Colors and Backgrounds: the most complex part which we would need to implement.
Fonts; Text: partially applies to us (since some of it isn’t theme-controlled); mostly involves passing things into Pango.
Tables: doesn’t apply to us; we have no tables.
User interface: this is about setting cursors and things, and doesn’t apply to us.

Finally, we should probably reiterate that:

this is still an experiment, and not an official direction which Metacity is taking;
even if it ever happens, there’s certainly no decision to use WebKit.

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.

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.

meta_warning() and dialogue boxes

meta_warning example I didn’t expect to get useful suggestions from the Linux Haters’ blogs, but here’s something that might fly: they point out that warnings from the window manager end up in .xsession-errors where nobody ever sees them. But now that we’re using Zenity for dialogues throughout, there’s no reason why we can’t adapt meta_warning() to put up a dialogue every time a warning is issued, which might alert users to useful things, such as why they can’t bind the keystroke they want. Having a way to turn this off might also be helpful.