Thomas Thurman – …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.

Moving to GSettings

In the beginning, Metacity stored keybindings in GConf. There was one GConf key for each action, and the string value gave the key bound to it. If it was undefined or “disabled”, there would be no key bound to that action.

In 2005, GNOME bug 164831 raised the point that other platforms used several keybindings for some of the actions. For example, the command to show the main menu is alt-f1 in CUA, but ctrl-Esc in Windows. We decided to find a way to support mulitple keybindings for the sake of people transitioning from these systems.

This posed a further problem. There is or was a principle that GConf configuration should be both forwards and backwards compatible. In other words, if you take a Metacity configuration from any point in time, it should work as well as possible with every other version of Metacity, both later and earlier. This meant that we couldn’t change the format of the single string keys. So instead we created two keys: one, the original key, took a single string, and the other, a new key, took a list of strings. This worked, but resulted in everything getting a lot more complicated. It’s not clear that it was ever widely used.

Now, in GNOME bug 621204, there is a laudable move to switch Metacity to using the new GSettings API. The dual nature of the keybinding settings makes this problematic. We could proceed by:

implementing it exactly as it is currently, even though it’s fiddly;
removing the ability to use multiple keybindings for the same action, even though that would break compatibility;
making all keybinding settings be lists of strings;
making all keybindings be represented by one very large settings, a list of pairs of strings.

Gentle reader, your thoughts on this are welcome, here or on the bug.

Photo © Matthew Boyle, cc-by-nc

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.

Are there any SDL people out there?

Back in 2005, a Metacity crash when running certain SDL apps was reported in GNOME bug 169684.

This bug remains at “critical”, but there has been no new comment on it for five years. Nobody appears to be experiencing the same problem now.

Gentle reader, do you have any experience in SDL? Can you tell us whether the problem is still present?

Photo © Ingy the Wingy, cc-by-nd.

Justified and ancient

Although it’s common for Metacity themes to have centred titles, there are still several themes which have the title justified to the left or right. GNOME bug 612940 makes the not unreasonable suggestion that the justification should be swapped when the system is running in a language such as Hebrew, Arabic, or Urdu which is written from right to left.

There is a patch supplied, but it swaps only the position of the text. This isn’t a problem when the titlebar’s decoration is symmetrical, but when (as in the case of Crux) it isn’t, the title moves without taking the decoration along for the ride. See the illustration on the right; the word “שלום” is written in white on the grey part of the titlebar instead of on the blue part.

The way forward from here might be:

to leave everything as it is
to commit this patch, and hope that people who speak these languages will avoid themes with non-centred window titles and asymmetrical titlebars
to mirror the entire window border decoration if we’re running in a right-to-left language. This may be non-trivial.

Your thoughts, gentle reader, are as welcome as they ever were.

Going back to the previous workspace

Eugeni Dodonov has asked for a keybinding to return to the previous workspace. For example, if you were on workspace 1 and switched to workspace 2, then pressing this key would jump back to workspace 1. Pressing it again would jump to workspace 2. Apparently this is a standard keybinding in xfwm4.

This is GNOME bug 618018, and there is a patch.

However, we believe this can be done adequately with an external EWMH-based script, although it’s a little more difficult than most EWMH scripts because it requires internal state.

Incidentally, this may be an interesting moment to discuss the question of whether Metacity should be able to make DBus calls on given keypresses as well as launching external scripts. Supplementing the EWMH controls with DBus is often suggested (see, for example, GNOME bug 531512 and ewmhbus) but perhaps we should instead be considering sending signals when windows are opened, hot keys are pressed, and workspaces are switched.

Photo © coffee bee, cc-by-nc.

Switching between workspaces

Metacity allows you to keep your windows on workspaces. You can have between one and 36 of them. (The number 36 is rather arbitrary; it’s described as “a fixed maximum to prevent making the desktop unusable by accidentally asking for too many workspaces.“)

You can switch between these workspaces either by using the switcher applet, or using directional keys (“move to the workspace below the current one”, and so on). You may also use specialised keys to jump to a specific workspace. For example, you might keep your email app open on workspace 7 all the time, and bind F7 to jump to that workspace. Each such specialised key is treated as a special case, and there are twelve of them.

GNOME bug 115584 makes the point that it’s inconsistent to allow three dozen workspaces and only allow keyboard switching for a dozen of them. There is even a patch to add twenty more special cases (your chronicler is not sure what happened to the remaining four).

It’s not clear that this problem needs to be solved at all, but if it does, adding a score of new keybindings is certainly not the way forward. A better solution would be to use GConf’s ability to store lists of strings. A single new GConf key could store a list of keybindings for the corresponding workspaces, and it could extend to whatever length made the user happy. The existing special-case keybindings would need to be retained for backward compatibility, but they could then be deprecated.

Photo © Josh Libatique, cc-by.

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.

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.

The positions of sounds

GNOME bug 616743 includes a patch which, if you have stereo speakers, will make the system bell move horizontally depending on which window it happened in. For example, if you’re editing a file in a terminal on the left of the screen, and the terminal bleeps, the sound will come from the left. If your mutt terminal is on the right of the screen, you will hear a bleep on the right when you receive new mail.

Sounds other than the system bell won’t be affected by this change. For example, music played by a music player will not be affected by the position of the window.

(The patch also appears to set the vertical position of the system bell according to the y-coordinate of the window. Your chronicler is having difficulty imagining the sound system where this would be distinguishable, but perhaps is not experienced enough in these matters.)

We are rarely minded to accept enhancement patches, since every new line of code is a line of code we have to maintain for ever. However, this one isn’t complicated, and appears to have a positively useful result.

What are your thoughts on the matter, gentle reader?