Created attachment 150141 [details]
Extension for this.

in overlay mode press <Ctrl>+C.
Near windows will appear id.
If Enter one of this id(then press <Enter>), windows with it will be activated.
In my opinion, This is much faster then <alt>+<tab> or select window from panel.
(Like in vimperator "follow links").

I have in mind something similar to the "Scale" Compiz addon (http://wiki.compiz.org/Plugins/Scale) where windows are visualized as small preview and one can use keyboard arrows to move around.

Cool to see that the extension system can be successfully used for this!  The tricky point here is how would the user know to press Ctrl-C?

If I was going to design this, one thing I'd love to have is the ability to use Super-<keybinding> to do various shell actions.  For example, Super-N would be new workspace.  In this case, I could imagine Super-[1,2,3..9] being "switch window on current workspace".

Even better if holding down super, you saw possible keybindings pop up in tooltips.

What do you think about doing a patch like this (just Super-[1,2,...9] for window swtiching) for the core?  I'd definitely like to see better keybinding stuff integrated.

Thanks a lot for looking at this!

Created attachment 150203 [details] [review]
Patch for this bug

Bind Super-[1,2,3..9]  "switch window on current workspace".
If holding down super, tooltips for keybinding will appear.

Review of attachment 150203 [details] [review]:

Neat!  This is a good start.  Just trying the patch:

Two smaller comments:

* We should start from 1 instead of 0; pressing Super-1 is doable with one hand (and the other on the mouse).
* The number tooltips clearly need some visual design input

This is harder, but what I'd expect is that if I press+hold Super, the overview would start transitioning, and then after a timeout (2 seconds?), the tooltips would appear.  We want a more general tooltip class, as well as a more general accelerator framework too, but these don't have to block the patch.

I think to get this one in, we could skip the tooltips and leave it as a hidden feature until we land a more general/fleshed out tooltips and keybindings work.

(bugzilla spam: populating the new "extensions" component with bugs discussing features that are not part of the core spec, but could be implemented externally once the extension system is done.)

Created attachment 152059 [details] [review]
Allow keyboard selection of windows and workspaces in overlay mode

Bind alt-[1,2,3..9]  "switch window on current workspace"
Bind ctrl-[1,2,3..9]  switch workspace
Bind ctrl+alt+[right/left] switch workspace

> but what I'd expect is that if I press+hold Super, the overview
> would start transitioning, and then after a timeout (2 seconds?), the tooltips
> would appear.

For doing this, Need some changes in mutter.

Note that part of this got committed in bug 613101

Created attachment 165896 [details] [review]
Allow keyboard selection of windows and workspaces in overlay mode

Merge with HEAD

Created attachment 178186 [details] [review]
Allow keyboard selection of windows and workspaces in overlay mode

merge with HEAD.

Should it be extension?

dunno... I'm working on overview keynav (for a11y) now and was thinking that it might make sense to add some direct keybindings for some things (like add/remove workspace). Of course, Ctrl+number to pick a window wouldn't work for blind users since the number mappings wouldn't be stable and so they'd have to walk the list of windows first anyway.

(In reply to comment #11)
> dunno... I'm working on overview keynav (for a11y) now and was thinking that it
> might make sense to add some direct keybindings for some things (like
> add/remove workspace).

Adding/removing workspaces should be done automatically according to the vertical-workspaces mockups, so whether a keybinding makes sense depends on whether we can implement this in time (I have started some work on it, but I'm not confident yet to make a proper estimate how long it will take me to get it done).

(In reply to comment #12)
> Adding/removing workspaces should be done automatically according to the
> vertical-workspaces mockups

"automatically" when? We're talking about non-mouse users here, so if it involves drag and drop, then that's not sufficient

(In reply to comment #10)
> Created an attachment (id=178186) [details] [review]
> Allow keyboard selection of windows and workspaces in overlay mode
> 
> merge with HEAD.
> 
> Should it be extension?

If possible to do as an extension, this seems like an extension to me. Experimental UI that some people will find really cool, not a primary way to use the shell. We can add hooks to the core to enable such an extension.

Created attachment 178455 [details] [review]
extension: Allow keyboard selection of windows and workspaces in overlay mode

patch for gnome-shell-extensions

Comment on attachment 178455 [details] [review]
extension: Allow keyboard selection of windows and workspaces in overlay mode

Pushed to gnome-shell-extensions, with some fixes.
Cursory testing showed a bug in workspace changing code - works only the first time, the second time focus is on the search box and binding has no effect.

Comment on attachment 178455 [details] [review]
extension: Allow keyboard selection of windows and workspaces in overlay mode

Cursory testing showed a bug in workspace changing code - works only the first time, the second time focus is on the search box and binding has no effect.
Anyway, due to the nature of gnome-shell-extensions, you can push it once you fix configure.ac (add the id to ALL_EXTENSIONS) and metadata.json (uuid needs to contain also "@gnome-shell-extensions.gnome.org")