GNOME Bugzilla – Bug 691636
Add support for Mission Control/Launchpad keys
Last modified: 2019-03-20 11:07:04 UTC
As used on Mac keyboards. The Expose key should probably toggle the overview, not sure about the Dashboard one.
What keysym do these use ?
I actually have "Mission Control" and "Launchpad" keys on my model of keyboard, and they generate: XF86LaunchA and XF86LaunchB On a Mac, the first key would be used to get an overview of the opened windows (-> Activities), the second one would show a list of applications to launch (-> Activities -> Show Applications). Given how generic the keysyms are, I'd be happy if we had at least the ability to control those from g-s-d through the shell's D-Bus interface.
Update for new keys: https://en.wikipedia.org/wiki/Apple_Keyboard#Apple_Wireless_Keyboard
Created attachment 308082 [details] [review] media-keys: Add support for machine specific media-keys This will allow handling keys in a specific way for Apple machines.
Created attachment 308084 [details] [review] media-keys: Add support for machine specific media-keys This will allow handling keys in a specific way for Apple machines.
Created attachment 308085 [details] [review] media-keys: Proof of concept support for Mission Control/Launchpad keys
Created attachment 308086 [details] [review] media-keys: Add more debug when received shell key events
This isn't exactly what we want because we also want the Apple keyboards to behave in the same way. So we'd need to either only capture keys for a particular keyboard (in which case, we might as well use that for the builtin Mac keyboard, instead of relying on the machine type), or we'd need a way to tell gnome-shell that we won't be handling this key and pass it on. Or we could always catch it, make sure to fallback to custom keys if the user set XFLaunchA to do something else on their machine...
(In reply to Bastien Nocera from comment #8) > Or we could always catch it, make sure to fallback to custom keys if the > user set XFLaunchA to do something else on their machine... Does it really need special handling? If we just add appropriate actions (with LaunchA/LaunchB as default bindings), users can unset or reconfigure it, and everything would just work, no? Or are there known keyboards that generate LaunchA/LaunchB for something else?
(In reply to Florian Müllner from comment #9) > (In reply to Bastien Nocera from comment #8) > > Or we could always catch it, make sure to fallback to custom keys if the > > user set XFLaunchA to do something else on their machine... > > Does it really need special handling? If we just add appropriate actions > (with LaunchA/LaunchB as default bindings), users can unset or reconfigure > it, and everything would just work, no? Or are there known keyboards that > generate LaunchA/LaunchB for something else? Plenty, it's the go-to keysym for "I don't know what to do with this". See /usr/share/X11/xkb/symbols/inet
*** Bug 742685 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/200.