GNOME Bugzilla – Bug 711682
Keybindings capture bugs
Last modified: 2014-12-19 13:14:26 UTC
In bug 707095, we created new keybindings that behave slightly differently for when in the lock/unlock screens, and allowed the power key keybinding to be used in the login screen. However, that brought up 2 bugs in gnome-shell: - you can't capture the same keybinding for 2 different modes (so g-s-d would know that it's in the lock screen and make sure not to show polkit or interactive dialogues in the lock screen) - when in gdm, the keybinding mode is LOCK_SCREEN instead of LOGIN_SCREEN When those 2 bugs are fixed, it should be possible to shutdown the machine by pressing the power button in the lock screen after having changed the button's behaviour: gsettings set org.gnome.settings-daemon.plugins.power button-power "shutdown" And ditto in gdm: # cat >/etc/dconf/db/gdm.d/01-power <<EOF [org/gnome/settings-daemon/plugins/power] button-power="shutdown" EOF # dconf update
Hi, Poking at this bug on a 3.10 box and it appears to still be a problem at the gdm screen. Do you know if there was any progress on this - glancing through the code even on master branch I don't see anything but I could be overlooking it.
Created attachment 282149 [details] [review] ScreenShield: remove obsolete comment and hack We don't need to wait to until the stage window is mapped to take the modal grab, because that code now runs in a startup-prepared signal handler, which in turn runs some time after the mainloop has started and well after the stage window is mapped.
Review of attachment 282149 [details] [review]: OK.
Attachment 282149 [details] pushed as cd4eda8 - ScreenShield: remove obsolete comment and hack
Are you sure this fixes both the bugs I brought up?
No, keybindings can still only be grabbed once, independent from the mode flags. But maybe it is easier anyway to just handle it differently according to the "Mode" property on org.gnome.Shell?
(In reply to comment #6) > No, keybindings can still only be grabbed once, independent from the mode > flags. But maybe it is easier anyway to just handle it differently according to > the "Mode" property on org.gnome.Shell? Not that much easier. gnome-shell already allows us to capture keys with a particular mode, I would expect each of the captures to be separate, each of those with its own ID. Also, using this command, I don't see the mode property changing when locking the screen for example: gdbus monitor --session --dest org.gnome.Shell Is it only expected to switch between user and login?
(In reply to comment #7) > Also, using this command, I don't see the mode property changing when locking > the screen for example: > gdbus monitor --session --dest org.gnome.Shell Right, turns out the property shows the mode Shell was started in[0], not the currently active one. [0] https://git.gnome.org/browse/gnome-shell/tree/js/ui/shellDBus.js#n236
(In reply to comment #8) > (In reply to comment #7) > > Also, using this command, I don't see the mode property changing when locking > > the screen for example: > > gdbus monitor --session --dest org.gnome.Shell > > Right, turns out the property shows the mode Shell was started in[0], not the > currently active one. > > [0] https://git.gnome.org/browse/gnome-shell/tree/js/ui/shellDBus.js#n236 Adding a Mode flag to the AcceleratorActivated signal would fix it. Should we do that?
(In reply to comment #9) > Adding a Mode flag to the AcceleratorActivated signal would fix it. Should we > do that? That would be very non-intrusive on the mutter/shell side, so if you're fine with this on the gsd side I'm all for it.
(In reply to comment #10) > (In reply to comment #9) > > Adding a Mode flag to the AcceleratorActivated signal would fix it. Should we > > do that? > > That would be very non-intrusive on the mutter/shell side, so if you're fine > with this on the gsd side I'm all for it. Can you look into that? I can take care of the gnome-settings-daemon changes.
Created attachment 290544 [details] [review] shellDBus: Add mode parameter to AcceleratorActivated signal This will allow g-s-d to handle actions differently based on the current mode - namely, allow the power button when locked, but make sure to never show any dialogs in that case.
I wonder if we should change the signal signature to 'ua{sv}' instead, so we can extend it more easily without requiring updating g-s-d and g-s in lock step.
(In reply to comment #13) > I wonder if we should change the signal signature to 'ua{sv}' instead, so we > can extend it more easily without requiring updating g-s-d and g-s in lock > step. Would be great, so we only break it once...
Meh. You're still breaking API by having different keys in the a{sv}. What happens if the key is missing? I'd rather just have an API break when the API actually breaks.
(In reply to comment #15) > What happens if the key is missing? This obviously assumes that g-s-d deals gracefully with this case.
Created attachment 290545 [details] [review] shellDBus: Change AcceleratorActivated signature Adding new parameters to the signal currently will break keybindings until gnome-settings-daemon is updated to the new API as well. Put additional parameters into a dictionary instead to make future extensions easier. For what it's worth, here's a patch for using a dictionary
Created attachment 290546 [details] [review] shellDBus: Add mode parameter to AcceleratorActivated signal Updated attachment 290544 [details] [review] for the dictionary change (not obsoleting the existing patch until we decide on the approach).
Attachment 290544 [details] pushed as 6803528 - shellDBus: Add mode parameter to AcceleratorActivated signal Attachment 290545 [details] pushed as 2aa4fb0 - shellDBus: Change AcceleratorActivated signature Attachment 290546 [details] pushed as 6803528 - shellDBus: Add mode parameter to AcceleratorActivated signal