We process "super-press + super-release" to show the overlay, and attempt to pass through super-press + anything else.  But, this only works for focused windows.  If gnome-do is trying to do its own XGrabKey as seems likely, than that will fail.  

I think we have to do some sort of special handoff outside of the X event model for this.  The simplest to implement would be to just broadcast a dbus signal with whatever extra key was pressed.  If org.gnome.Shell is running, gnome-do knows to listen to that.

Hmm actually...I wonder if it'd be possible for both gnome-shell and gnome-do to use the gnome-keybinding shortcut infrastructure.  Needs investigation, e.g. I don't know if it's going to handle the "pure modifier" press+release.

Well, a lot of apps use the same approach as Do, since it's all just copied from libtomboy.  I know GNOME 3 is a time where it's ok to break stuff, but still...grabbing an entire key seems a little extreme.  Do you guys think a key combo is too complex?

Anyway, this really should be configurable.

I forgot there is a GConf key for this "/apps/metacity/general/overlay_key", it comes from mutter.  But I'd rather not have users having to poke around in GConf or (worse) apps automatically changing GConf.

Also I think it would be unfortunate to give up on press-release super model by default if you don't have say Do installed.  For Do which this bug was filed about, a possible solution would be to have GNOME Shell detect that Do is running, and give it the Super key.  Then inside Do, have an "overlay" action.

For other things I'd like to look at specific cases.  It may be possible for example to bind "new tomboy note" globally to Super+N, but how many people do that?  And even for those kinds of cases, we can change applications to use something better than XGrabKey.

There is also an entire GNOME keybindings infrastructure; on my system it's /usr/share/gnome-control-center/keybindings/.  We should probably consider integrating with/improving that.

I encountered this, but as the overlay functionality really is a replacement for Gnome Do, its fine by me... for now at least. If there were a critical application that couldn't be summoned correctly... That would be irksome, so perhaps this should be fixed sooner than later.

For Gnome-Shell to capture this whole key is not a good idea at all.
Using a shortcut like control-super is a much, and I can't stress this enough, much better solution than having it consume the whole super key.
Pressing ctrl + super or alt + super is as effortless for the user as pressing super alone.

And along with that. All keybindings for Gnome-Shell should be easily configurable trough an interface.

To me gnome-shell should react on super alone only. This is, it should allow others to bind to super-ctrl, super-space, super-q or whatever.

This is pretty similar to what windows does with its start menu btw. It's just that our own "menu" is the overview.

That is, it would be better if it allowed being configured...

Yeah, pressing super key alone provides much better user experience than a ctrl+super or any other key combo.

I've switched to GNOME Shell just a week ago and really loved it ! (Hail to GNOME Shell Developers and thanks a lot !) It's so pleasant to complete background tasks (window switching, application launching, etc) by a single mouse click, button click, even mouse moving without clicking. (I now that one can achieve most of it in Compiz, but in GNOME Shell it's out-of-the-box. Neat and handy.)

And I vote for making hot-keys bindings controlled by GNOME keybinding infrastructure all over the GNOME (maybe a UI for key-bindings customization should be improved also). It's a little bit irritating from a user perspective to have hot-keys binding customization scattered all over the system causing hidden conflicts etc..

(In reply to comment #6)
> For Gnome-Shell to capture this whole key is not a good idea at all.
> Using a shortcut like control-super is a much, and I can't stress this enough,
> much better solution than having it consume the whole super key.

Why?

> Pressing ctrl + super or alt + super is as effortless for the user as pressing
> super alone.

And not discoverable.

>> Pressing ctrl + super or alt + super is as effortless for the user as pressing
>> super alone.

>And not discoverable.

Do you mean that it is not a key that the user can hit by mistake while ie playing a game or operating any other software such as blender that requires the user to use shortcuts. It is a very common issue under the outdated Windows platform that full screen applications gets tabbed down when the super key is pressed.

Would you also argue that the commonly used application switcher should be mapped to Caps Lock instead of alt-tab so that it's easy to discover?


The solution for the issue you are describing is not making one key for each function of the Shell. Instead we should use the great toolsets that exist in the shell to provide some sort of tutorial. After the user has used the shell for a short time maybe a small notification telling the user that "Pressing Alt-Tab will bring up the application switcher". Tough that could be annoying.

Maybe a tutorial in it's true form, an icon on the new Gnome-Shell desktop that launches a voiceover along with captions telling the user to press the alt and the tab key at the same time. Once the user has pressed these keys and triggered the application switcher the tutorial continues. If the user does not succed after let's say 30 seconds, a picture of a keyboard should appear showing where the alt and the tab-key is located.

Super should absolutely not do anything when pressed on its own.  It's a *modifier* key -- it *modifies* other keys.  It should be safe to press alone without disrupting the user.  That's practically promised by its position between Ctrl and Alt.

This drove me absolutely batty in Windows; I'd hit Super or Alt either accidentally or because I change my mind halfway through a keystroke, and then my focus is stolen by a menu I didn't want.  I had to get in the habit of using Ctrl-Esc instead so I'd be less inclined to ever press Super.  The accessibility shortcuts (e.g. "hold RShift for five seconds") likewise triggered dozens of times when I didn't want them to.  OpenOffice.org's Alt behavior is still regularly frustrating, even now.

You may notice that some modern keyboards have gone so far as to have a physical switch to turn off Super because of its irritating behavior in Windows.  But the problem isn't configuration; the problem is that having the system listen for a lone modifier keypress is broken behavior and should not be the default.  OS X and KDE don't do anything like this; the Windows behavior is an unfortunate relic.

Is discoverability really a concern?  People who use Windows shortcut keys will look for a list of GNOME shortcut keys when switching; platforms do different things, and different platforms always have different WM-level shortcuts.  People who don't use or know about Windows shortcuts will have no inclination to press Super to see if it does anything, any more than they would press Ctrl or Shift alone and expect something to happen.


In fact, it might be a good idea to just use Super-Space.  Shell provides much of the same functionality as launchers, after all -- if you install Do (which should of course win out) then you're probably less interested in using Shell.  It's consistent with OS X's Spotlight, it's similar enough to Windows, it parallels Alt-Space, and it's easy to hit.

I can understand that there are a lot of strong feelings around this issue.  However, our use of the "Windows" key is consistent with versions of Microsoft Windows since Windows 95.  And it is for this purpose that Microsoft encouraged adding the key at all.

http://en.wikipedia.org/wiki/Windows_key

It is important for Windows Shell to have a set of hot keys that can be solely for its own use.  See:
http://en.wikipedia.org/wiki/Windows_key#Microsoft_Windows_shortcuts

And it is similarly important that the GNOME Shell have access to a set of shortcut keys-combos that applications won't use.

Consistency is important.

Furthermore, the crazy amount of keyboard shortcut configurability that we had in GNOME2 makes it almost impossible to write good guidelines for application authors.  We can't even begin.  It is a free for all.  Let's start cleaning up the mess here.

With respect to the "Windows" key, the graphical shell should have ownership.  I think if it is somehow extended to delegate this authority it is another matter.

(In reply to comment #12)
> I can understand that there are a lot of strong feelings around this issue. 
> However, our use of the "Windows" key is consistent with versions of Microsoft
> Windows since Windows 95.

I'm not entirely sure about that. In my Windows days I had no trouble creating keybindings that included the "Windows" key.  I do not know whether or not Explorer.exe was somehow responsible for this, though.

> 
> http://en.wikipedia.org/wiki/Windows_key
> 
> It is important for Windows Shell to have a set of hot keys that can be solely
> for its own use.  See:
> http://en.wikipedia.org/wiki/Windows_key#Microsoft_Windows_shortcuts

This is a fair argument.

> Furthermore, the crazy amount of keyboard shortcut configurability that we had
> in GNOME2 makes it almost impossible to write good guidelines for application
> authors.  We can't even begin.  It is a free for all.  Let's start cleaning up
> the mess here.
> 
> With respect to the "Windows" key, the graphical shell should have ownership. 
> I think if it is somehow extended to delegate this authority it is another
> matter.

I think the main frustrating thing here is that "Super" was the only key left with which you could safely make simple two-key global shortcuts.  Ctrl and Alt are too frequently needed by the current application.  Using Ctrl+Alt+<key> may work, but it has become a common thing on the Linux desktop to use Super+<key> instead, for more comfortable global keybindings.

I can sort of see the argument for gnome-shell being responsible for all Super-related keybindings.  But I really don't see any reason why this can't all be handled by the GNOME keybinding infrastructure, and editable by  users in gnome-keybinding-properties.

(In reply to comment #12)
> However, our use of the "Windows" key is consistent with versions of Microsoft
> Windows since Windows 95.  And it is for this purpose that Microsoft encouraged
> adding the key at all.
I've yet to meet anyone who knows of the lone Super behavior on Windows and doesn't find it intrusive.  Consistency with a popular platform is a fine goal, but contrived keypress acrobatics are going a bit too far.

> Consistency is important.
Yes, and Super remaining a modifier is consistent with the other 3+ modifiers, every OS besides Windows, and past GNOME behavior.  ;)

> With respect to the "Windows" key, the graphical shell should have ownership. 
> I think if it is somehow extended to delegate this authority it is another
> matter.
Are you saying that Shell deliberately steals (or should steal) all control of Super?  From comment #1, I was under the impression that the problem was a consequence of trying to listen for a lone modifier keypress -- hence objecting here instead of filing a new bug.

Hi Jon, while I understand the importance of the key itself for gnome-shell, I agree with Sandy here when he says there's no reason the shell should prevent installing Super+key from within itself, as it does in Windows.

I don't have really any strong preferences wrt. how much such a behaviour should be customizable, but it would be nice if i.e. gnome-do, or a similar feature, could be developed as a shell plugin and activated from the shell itself upon pressing of e.g. Super+Space.

*** Bug 617057 has been marked as a duplicate of this bug. ***