GNOME Bugzilla – Bug 610987
right windows key doesn't move to activities overview
Last modified: 2021-07-05 14:30:26 UTC
While the right windows key successfully exits the activities overview, it doesn't seem to take me to it. Both the left windows key and alt-f1 do take me to the activities overview, though.
If we just totally removed "overlay-key" from mutter, and just intercepted Super ourselves from gnome_shell_plugin_xevent_filter(), we could fix this and also maybe fix bug 641117 more cleanly. (Not to mention getting rid of a lot of gunk in mutter to deal with the one very special keybinding that isn't like the others.)
If we ever want to support <super>key key bindings, then I think it has to stay in Mutter. Broader I want to do all passive grabbing in Mutter - be able to define custom key bindings and then install custom key binding handlers for them by name (as you can do now for the standard key binding handlers.) But I'm not sure we can do that with <Super> because it is special - though I suppose if we added the generic facility we could generically deal with modifier key bindings. The more we can centralize passive grabs into one entity, the better off we are in my opinion.
(In reply to comment #2) > If we ever want to support <super>key key bindings, then I think it has to stay > in Mutter. Well, we could just have gnome_shell_plugin_xevent_filter() do what keybindings.c:process_overlay_key() does now. (Well... except for the part where it doesn't work.) > But I'm > not sure we can do that with <Super> because it is special - though I suppose > if we added the generic facility we could generically deal with modifier key > bindings. I can't imagine you'd ever want to bind something to just Shift, Ctrl, or Alt. But then, I'm generally dubious of the idea of a key being both a modifier and not a modifier. (OOo opens the File menu if you just press and release Alt, and I manage to accidentally trigger that every time I try to use it for more than a few minutes.) And if we don't have the general case, then we just have what we have now, which is a piece of gnome-shell that was stuffed into mutter for technical reasons.
*** Bug 648581 has been marked as a duplicate of this bug. ***
*** Bug 649192 has been marked as a duplicate of this bug. ***
*** Bug 657107 has been marked as a duplicate of this bug. ***
*** Bug 674598 has been marked as a duplicate of this bug. ***
Just wanted to say I ran into this bug too and agree it needs to be fixed. My ergonomic keyboard has a right super key only. This was very confusing because I didn't know it was "right" super key, just that gnome appeared to have a bug. I think a status change of the bug from unconfirmed to New is in order.
I noticed this after getting a new keyboard with two super keys. The left opens the overview upon key_up, the right only works as a modifier. Anyone know where abouts in the code this stuff is?
See https://bugzilla.gnome.org/show_bug.cgi?id=697116#c18.
*** Bug 697116 has been marked as a duplicate of this bug. ***
Thanks Florian. Having just looked over the code briefly, is this not simply a case of adding a `#define KEY_SUPER_R 0x86` and also checking for this where we check for `keys->overlay_resolved_key_combo.keycode` (which presumably is equal to 0x85). I assume it can't *actually* be that simple!
Created attachment 327843 [details] [review] Untested concept patch Heres a patch that simply defines KEY_SUPER_R and checks for it in process_overlay_key() I'm still compiling gnome, so I've yet to do any testing/debugging/playing but I thought I may as well get some feedback on my initial direction (it may even work - who knows!)
Ok finally got jhbuild to work... In answer to my earlier question: no, it is not that simple. The callback that handles keypresses only gets called for certain keys (like SUPER_L) and I have yet to work out where this is decided (I can't see anything obvious in keybindings.c).
*** Bug 767541 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.