Switching – …for the adult in you

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.

Photo © Kevin Dooley, cc-by.

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.

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.

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

Squib of the day: Window paths

It’s suggested in GNOME bug 82567 that Metacity could allow a left-click on the titlebar to launch a menu which allowed the user to navigate to the parent, grandparent, or further ancestor of the window. This would only make sense where the window could represent a container which itself was contained in some other container hierarchically (which amounts to the file manager, pretty much).

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.

Squib of the day: Workspaces should switch instantaneously, or not

When GNOME bug 86590 was born, it was a request to make workspaces switch instantaneously when you panned around them using the workspace switcher with ctrl+alt+arrow.

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:

Switch when they let go of the keys, as we used to.
Switch after a delay, as suggested above.
Maybe it’s fast enough these days and nobody cares any more.
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.

Squib of the day: Drag and drop should work properly

In GNOME bug 80984 (closely related to GNOME bug 76672), someone is asking for the window manager to help out with drag-and-drop. The problem is that a drag-and-drop operation should not raise the window it begins in, because raising that window could obscure the window you’re planning to drop the object into.

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.

Squib of the day: keys for windows

GNOME bug 97725 raises the interesting idea of associating keys with windows. Two differing approaches have been advocated:

Have a set of keys which work to “bookmark” windows, and a corresponding set of keys which mean “jump to bookmark n“.
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.