Add a window selector applet you your gnome-panel, or set the preference on the
window list applet to show windows from all workspaces, and you'll be able to
switch between all windows on all workspaces.  But honestly I don't see having
tons of different ways of cycling windows to be a very feature and smacks of bloat.

Certainly we're not going to be able to add custom window-cycling functionality
to metacity.

Though perhaps a metacity-extensions feature would be possible, akin to epiphany
extensions.  But I simply don't have the time to try to implement such a thing.

Thanks for your reply.  Its sounds reasonable, but I fail to see how this helps
me now to bind keys to focussing specific windows?  How did you manage to bind your
keys/accels?

    $ LANG=C /usr/lib/gnome-panel/wnck-applet --version | p
    Gnome Window Navigation Applets 0
    17:26:53 janneke@oliebij:~
    $ LANG=C /usr/lib/gnome-panel/wnck-applet --help | grep version
        --version                              2.6.1

You must be using a newer/another window list applet than I?
[I did set

    gconftool-2 -s /desktop/gnome/interface/can_change_accels -t bool true
]

Or do you mean that this we should refiled this bug against
wnk-applet/gnome-panel, asking for key bindings?

Btw, I did not mean to imply that should implement it and I'm sorry if
you got that impression.  However, your tight control makes me want to
be very very sure that a solution won't be vetoed before sending a
patch.

The panel applet won't give you keybindings, but it does provide the ability to
focus windows on other workspaces.

The idea of implementing keybindings for specific windows has been proposed
before and the biggest problem with it is that it will sort of necessarily be
confusing and coming up with a UI for it is decidedly non-trivial.

The extensions mechanism is an entirely separate issue, and this would be
extremely complicated to get right.  I'm not opposed to that idea, however.

If you want to implement a separate program to provide this functionality such a
thing should be possible.  It will just require that you use libwnck, since the
EWMH hints will provide everything necessary.  devilspie is a libwnck standalone
add-on to metacity which may be a good place to start.

I've written a small program to investigate the `separate program'
possibilities, see

   http://mail.gnome.org/archives/gtk-app-devel-list/2004-May/msg00282.html

But my biggest problem remains: how do I get [Metacity to setup] a keybinding
to popup the window list?

[is this more on toping for the desktop-devel-list?]

I've thought before about having a shortcut number/letter by each item in the
Alt+Tab popup, so you could do something like "Alt+Tab 3" to go to the third
window in the list, or something like that.

I don't know if it would really be useful though, I haven't thought through all
the details.

I'm looking for some kind of keyboard driven, intuitive, yet highly predictable
way of window selecting, but I'm also not sure what the best solition would
look like.  That's why I tried to describe a number of possible solutions
in my initial bug report.

I tend to use only about four applications most.  While this selection is
highly personal, I suspect that this goes for more people.  While hacking
on LilyPond, I use:

   [KP_1]  cycle Emacsen  (hacking, email, run lily)
   [KP_2]  cycle Terminals
   [KP_3]  cycle Viewers (Xdvi, gv: view lily)
   [KP_4]  cycle Browsers

When I find that I have more than 10 applications open, ALT-TAB becomes
guesswork, whereas I *know* that I want to switch to Emacs, Xdvi or Galeon.

The idea of my silly keywise.c hack is that a user should be able to predefine
window classes and accelerators, ie HYPER-TAB `2' always selects the list of
terminals, eg.

My .02 would be that if the user has to explicitly set things up, it's not a
very good solution - maybe a few percent of users at most will do that. And
there's no way to present the setup that doesn't require people to know about
weird implementation details like window class, I would guess.

I would rather see something that can be learned "as desired" sort of like key
shortcuts in menus, if that makes sense.

To me there are already at least three ways of switching among tasks:
Alt+tab/windowlist, switching workspace, and switching tabs in all the multitab
applications out there. On a daily basis I get confused about this - find myself
switching spaces to go back to the previous task, when the previous task is on a
tab, or in another window, for example.

So adding another concept of how to group tasks seems like the wrong approach.

I can imagine some crack like the following: there's a history of the last few
tasks always visible on the panel (ideally as thumbnails, sadly X is too slow
for this), with a single-keystroke shortcut visible next to each one, and when
you press the key (say F9 through F12 for 4 item history?) you jump to the right
workspace and window. To make this really crazy fun it should list tabs in the
history too... that would need some engineering.

Another solution would be to maybe just change the taskbar to have visible key
shortcuts to jump straight to each item...

Of course a menu with groups is fully possible to implement using libwnck as well.

Don't know. It's probably a reasonably intractable problem on some level, once
you have a ton of windows you're sort of hosed when it comes to quickly finding
the right one.

See also bug 152661 for another suggested way that we could provide for
navigating windows on the desktop, which doesn't require figuring out how to
group windows (however, it would only be useful for visible (i.e. mapped and not
obscured) windows).