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.

Photo © Telstar Logistics, cc-by-nc.

Of course again we could solve this simply with an external script, and I’m wondering whether there should be a Bugzilla status for RESOLVED CANFIXWITHASCRIPT.

More seriously, perhaps there should be a collection of these scripts and a master script which listed them all in a dialogue box and modified the user’s GConf settings according to which ones were turned on.  (I wonder whether the control-center people would object to having this in an “Advanced” button somewhere, or whether that’s too bells-and-whistly.)

Update: Since the script was so simple, I spent twenty minutes writing it and closed the bug.  I think this demonstrates that we need a Perl module called X11::Protocol::Extended which knows about the EWMH, so these scripts are even easier to write.  Maybe I’ll write it.

Photo © Heated Ground Photography, cc-by-nd.

Of course, you can already do this by disabling the ordinary alt-tab action and then assigning superswitcher to be one of the custom commands, but I think they want it shipped that way by default. I suppose it might be interesting to be able to have alt-tab in a separate process, if you wanted to save memory and your computer was fast enough that it wasn’t too slow to start up.

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

To play with the script:

1. Download the current version from GNOME bug 152661.
2. Put it in your path as metacity-direction.
3. Install X11::Protocol by typing:
   sudo cpan X11::Protocol
4. Open gconf-editor and set /apps/metacity/keybinding_commands/command_n, where n is any set of four unused values, to:
   metacity-direction e
   metacity-direction s
   metacity-direction w
   metacity-direction n
5. Set /apps/metacity/global_keybindings/run_command_n to an appropriate set of values, like “<Shift><Alt>Right”, etc.
6. Enjoy.

The algorithm is supposed to be the same as fvwm’s, but if you have suggestions for tweaking it, let me know.  The program should also demonstrate how to do fun EWMH things from Perl.

Photo (c) Katie Sutton, cc-by-nc-sa.

I really don’t see why this feature would be useful to anyone.  Would anyone care to try to justify its inclusion before I close the bug?

Photo © lavalen, cc-by-sa.