January 2010 – …for the adult in you

Alt-Tab over all workspaces

At the moment, when you press alt-Tab, you cycle through a list of windows on the current workspace. People use workspaces in many ways, though; some people keep only one application maximised on each workspace. Very many people have asked for the ability to alt-Tab between windows on all workspaces, not just the current one.

There have been many bugs raised about this matter. One approach, taken in GNOME bug 577699 by Alexander Larsson, is to add a new keybinding called switch_windows_all, which can then be re-bound to alt-Tab. This is certainly a possibility, but adds a new keybinding and a new GConf setting. It is apparently how Compiz solves the problem.

A different approach was suggested six years ago by Havoc in GNOME bug 143511. The window list in the panel has the option of toggling between a list of all windows and only the windows on the current workspace. It is contrary to the principle of least astonishment if the windows listed in the alt-Tab display are not the same as those listed in the panel.

Therefore, the window manager should detect this setting in the window panel list and behave accordingly. This could be done simply by reading the setting out of GConf. A more portable way would be to have a new EWMH hint on the root window; however, this was raised on the wm-spec-list in 2007 and was not well received. Generalising GNOME’s panel to all environments may be tricky.

Again, anyone wishing to work on this will have abundant help available; otherwise we will get to it when the bug queue is reduced a little. GNOME bug 143511 is the one to follow.

Photo © Scott Ableman, cc-by-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.

Snap

There has been some discussion on the last post about implementing functionality similar to Microsoft’s “Aero Snap”. Your chronicler has never used Windows 7, but the idea is demonstrated in this video. It appears to mean that:

when a window is dragged to the left or right of the screen, it is vertically maximised, and resized horizontally to half the screen width;
when a window is dragged to the top of the screen, it is maximised;
there are hints elsewhere that dragging to a corner minimises, but this is unconfirmed at present.

There are apparently several people who would like this implemented on the free desktop.

One option is to do it with an external tool. This is the route taken by this tutorial by gotsanity. It’s a simple matter of monitoring the root window for configure events; the link goes to a program which will demonstrate the general principle. Making that program into a daemon which will solve this problem is only a matter of adding code to detect a window crossing screen borders, and some kind of payload for when one does.

The advantages of this approach are:

that it will work with any window manager, and
that we have previously said that almost anything which can be implemented externally should be, to preserve the lightweight nature of Metacity.

The disadvantages, however, are:

the need to keep a separate daemon running; this is a good deal more of a long-term problem than launching one-shot processes on a keystroke,
the difficulty in adding the grey box that tells you you’re about to trigger the effect (though this is certainly not impossible with such a method), and
the change in the moment of triggering from after you release the button to during; this is a side-effect of the modern ability to drag a window itself rather than a wireframe. It would be hard to solve in any way that didn’t feel like a hack. strokinder points out why this is problematic.

The ability could also be implemented within the window manager itself. The advantages and disadvantages of this plan are mirror images of those of the other plan. It may, however, be worth the added complexity. Additionally, the loss of the portability inherent in using an external script may not matter: if this was implemented in Metacity itself, it would presumably be fairly easy to carry it over to Mutter, since in this area the systems differ little. Porting to Compiz may be more of a difficulty.

If anyone with a little programming experience would like to volunteer to work on this, abundant help can be provided; otherwise we will see about dealing with it when the bug queue is reduced a little. Please follow GNOME bug 607694, where this issue is being discussed.

Photo © Darwin Bell, cc-by.

Expansion and external tools

In GNOME bug 517722, a new keybinding is suggested which will make the focussed window take up as much space as possible without covering any other window. If applied to all windows, it would make Metacity behave like a tiling window manager.

The main problem with this idea is the same one we were discussing almost a year ago: the same action can fairly easily be done using an external script and the EWMH. So on the face of it there doesn’t seem to be much reason to add it into the window manager as well.

Of course, this could also be said of several of the less-used bindings, such as “move to southwest corner”. Indeed, some have called for major keybindings such as alt-Tab to work this way. The problem here is that external scripts are slow to start when the computer is overloaded: it’s important that alt-Tab keeps working even when the system load is high. The same thing can’t be said of “move to southwest corner”, though.

Window managers which incorporate a programming language don’t have this issue, since a keybinding can be easily written to reconfigure a window in any way the user pleases, assuming the user is a programmer. But Metacity aspires to be a lightweight window manager, and so does not provide this.

Both of these are reasons why your chronicler is not minded to accept this patch. Perhaps both of these are arguments for moving keybindings such as “move to southwest corner” out to an external script as well, although we could say they are grandfathered. Perhaps also there should be a general policy against anything that can be done in an EWMH script being accepted into Metacity in future.

The number of external EWMH scripts to do this kind of thing continues to rise. Mikkel Kamstrup Erlandsen has been working on putting a number of them together, including one to expand windows, and calling it WinWrangler.

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

Border widths under user control

At present, the width of a window’s border is decided by the current theme. However, some people find it harder either to see thin borders or to click on them. They would prefer thicker borders than most people want.

In addition, Metacity measures border widths in pixels. The higher the resolution of a display, the thinner the borders will appear, exacerbating the problem.

Of course, since borders are under theme control, one solution is to make a new theme; this is after all what we do for users who need high-contrast window borders. However, this modification will need to be made for every theme a user wants to use. Furthermore, the Metacity theme format is not easy for the general public to modify.

CSS themes would circumvent the problem by allowing widths to be specified in millimetres, rather than pixels. However, this is not currently supported by the underlying libraries, and even if it was, the problem of themes which still used pixels would remain.

GNOME bug 496536, which mirrors Launchpad bug 160311, discusses this issue. Two suggestions are made:

A setting to allow the user to override the width of borders. There is a patch to allow this, but it has not yet been committed. For example, here is the Crux theme with the border width set to 100 pixels.
Make “the mouse stick to the border”. If this means making the cursor pause briefly while moving over the border of a window, it may pose a problem with implementation.
A third suggestion, not made on either bug, is that the clickable area of a border should be a few pixels wider than its visible area.

Your chronicler would like to hear from readers who have this difficulty, particularly because of an accessibility problem, as well as your opinions on what should be done about the matter.

Photo © Lauren Marek, cc-by-nc.

Metacity Journal 2010-01-18

Thomas has been working on Metacity this past week, supported by Collabora Ltd. Thanks, everyone!

A. Last week. Work on Metacity has fallen into three parts over the last week:

A1. Routine work such as reviewing patches. This included

GNOME bug 598231 (null dereference in visual bell).
GNOME bug 336750 (potential DoS on shift-printscreen). This patch looked correct, but in testing it didn’t solve the problem; I am still trying to find out why.
GNOME bug 604897 (session management issue)
GNOME bug 592940 (markup in translatable strings)
GNOME bug 530702 (Metacity stops Compiz from starting up). This appears correct, and certainly fixes a bug, but I cannot test whether it fixes the presenting problem; can someone confirm?

A2. Cowbell (CSS themes). I have been working on merging the cowbell branch with the main branch, but this has been slow going. I am wondering whether it would have been better to move all the Cowbell-specific code out to a separate library so that it could be called from other window managers as well; it would be quite a challenge to make it abstract enough.

A3. GNOME bug 531512 (EWMH and D-Bus). What began as a brief comment to a bug turned into a blog post, which turned into a script, which took a fair chunk of the day to get working. But it does demonstrate that the idea is sound, and I’d rather have working code than hand-waving any day.

B. Going forwards.

B1. Bugs. There are still more bugs than can be reasonably dealt with by your chronicler. This is important, because it looks like Metacity is here to stay after all. Therefore:

Most of all, I need your recommendations as to which bugs should be dealt with first. Obviously there’s the bug’s priority to decide this already, but I know there are many little things that get under people’s skin (Launchpad bug 160311 springs to mind). I’d like people to nominate their least favourite bugs.
Also, I would like some help with patch review and the very inglorious Bugzilla work. If anyone’s feeling like volunteering, let me know.
I plan to work out some kind of GNOME Love-type mentoring scheme where people get help learning to keep a project going.

B2. Cowbell: separate library? I’ll think about it. If you know someone from another WM who would also be interested in integrating such a library, let me know. If you believe it would be better for the spec to be shared but not the code, let me know as well.

B3. EWMHbus: worth extending to a full set of EWMH abilities? Worth rewriting in C? Would anyone really use it?

C. Other things

I used to have a script which wrote most of the Metacity Journal for me, and it would include mentions of Metacity on blogs, and translation commits, and so on. That script has rusted, which is a shame; maybe I should bring it back and generalise it so other projects could use it. Several translation commits were made this week, anyway. Thank you all.

Window managers and D-Bus

D-Bus is the standard way for applications to communicate with one another. But the EWMH, supplemented for our purposes by libwnck, is the standard way for applications to communicate with the window manager. GNOME bug 531512 raises the suggestion that even window manager communication should be done over D-Bus, or at least that D-Bus should be an alternative to the EWMH.

There are two main questions to answer before we make any decision here:

Does this buy us anything? Are there people whose lives will be made easier if they can do what they want over D-Bus, without having to include X libraries to use the EWMH? Is this enough to justify the additional complexity in each window manager?
Can we keep this standard? EWMH works with almost all window managers. Switching to a D-Bus-based system brings the risk of fragmentation.

A third option: We could have a separate application which provided a D-Bus service that knows how to send and receive EWMH messages. Such an application could be run in conjunction with any EWMH-compliant window manager. Here’s a quick proof-of-concept your chronicler threw together in a few hours in Perl; let us know, gentle reader, whether you believe it’s worth developing any further.