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.

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.

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.

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.

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.

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.

Photo © Glenn Loos-Austin, cc-by-sa; thanks to Katie Sutton for choosing it.

This would require a new window hint in order to work. It would replicate behaviour that is generally the province of toolbars and appears to have WONTFIX written all over it.

This is similar to a more useful and general recent suggestion that windows should be able to add a draggable icon in the titlebar, as is done on OS X.  Your chronicler would like to see this done, but is aware that the obstacles between there and here are formidable.

Photo of Jackson the dog © ItsGreg, cc-by-nd.

Then that was fixed, and someone else complained that it was too slow, and inconsistent with the alt+tab popup, which doesn’t switch until you let go of alt.  They asked for it to be reverted.  Someone else suggested a compromise: if the user pauses while moving through workspaces, flip to that workspace without removing the pager.

Of course, then we’d have to consider whether we should do that with alt+tab, too.  It’s possible that the two cases are different enough that there’s no good analogy here, though:  workspaces can be named, for example.  It’s possible as well that they’d become different enough for there to be no good analogy here if we had thumbnails of the workspaces instead of the icon-based boxes we have now.

So the options now are:

1. Switch when they let go of the keys, as we used to.
2. Switch after a delay, as suggested above.
3. Maybe it’s fast enough these days and nobody cares any more.
4. We could keep all the windows on all the workspaces mapped all the time, like Compiz does, which would make things a lot faster anyway, and would reduce to the previous case.

Photo © Matsatsinis Fragiskos, cc-by-nc-nd.

This is a reasonable and important request.  It is, however, not at all simple.  Metacity is the program which decides whether to raise the window, and there is currently no way for Metacity to know you’re about to start a drag-and-drop operation.

One rather crappy workaround is to tell it by holding down Super or AltGr.  This works, but it’s not elegant.  The system should be able to know.

This is not what raise_on_click does.  Please forget about raise_on_click.  It won’t solve your problem.

The correct answer is fixing this in the EWMH.  Luboš had an idea about this back in 2004 called _NET_WM_TAKE_ACTIVITY, and Elijah improved on this later with a more complicated idea called _NET_WM_MOUSE_ACTION.  Getting this into Metacity is GNOME bug 152952.  Whatever happens, it’s going to need changes to GTK and to various applications, particularly including Nautilus (the file manager).

Far more of a detailed writeup, including feedback from some of the people involved, is found in this entry. Your chronicler believes that implementing this is worth the fairly considerable effort to fix.

Photo © wili-hybrid, cc-by.

1. Have a set of keys which work to “bookmark” windows, and a corresponding set of keys which mean “jump to bookmark n“.
2. Have a keystroke which means “bookmark this window using the key I’m about to press”, and allow users to press bookmark keystrokes in the alt+tab window.

It is of course important that the bookmarks are associated with a given window indefinitely, otherwise they become a lot less useful.

As a step towards the second option, I’ve written a very quick and hacky script called metacity-bookmark.  The name is a little misleading, because it should work with any EWMH window manager; it uses the window matching technique described in this post.  As usual, you’ll need X11::Protocol installed from CPAN (“sudo cpan X11::Protocol“).

Bind the program to some key or other, which we’ll call Bookmark from now on, and then you can do:

• Bookmark + key — jump to the window identified by key
• Bookmark + Space + key — identify the current window by key

Feel free to play with this and let me know what you think.  I’ve made little windows pop up to tell you the program was running, inspired by the “Compose” indicator that used to appear onscreen on old DECs, if my memory serves.

One obvious limitation of the current script is that when it activates a window, it doesn’t switch to the workspace which the window’s on.  I may fix this another day when I fix all the other problems with this script, but if you fancy diving in and fixing it yourself, it shouldn’t be too hard.

As a possible extension to this, windows could also have bookmarks automatically associated with them from their creation, based on their name– for example, the first GIMP window could automatically be given “G”.  And either kind of bookmark could be displayed in the Alt+Tab switcher next to the associated window’s preview or icon.

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