GNOME Bugzilla – Bug 701324
Cannot set shift ctrl alt up/down as shortcuts
Last modified: 2013-09-05 19:38:51 UTC
The classic keyboard shortcuts for moving a window to a workspace up or down were: shift ctrl atl up/down The classic keyboard shortcuts for moving to a workspace up or down were: ctrl alt up/down These seem to have changed. I tried to set the shortcut in settings > keyboard > shortcuts > navigation, but it doesn't accept the shift ctrl alt up/down shortcuts at all. Even when I try to assign it as shift ctrl alt up/down, it only takes ctrl alt up/down. I thought it could be the case that the limit is using 3 keys at the most, but there's a shortcut for moving to the left/right workspace (why?) which goes shift ctrl alt left/right. [asinha@localhost ~]$ rpm -qa \*control\* control-center-3.8.2-1.fc19.x86_64 telepathy-mission-control-5.14.1-1.fc19.x86_64 control-center-filesystem-3.8.2-1.fc19.x86_64 [asinha@localhost ~]$
there is two sets of bindings now: Shift-Super-PageUp/Down and Shift-Ctrl-Alt-Up/Down The control center only shows the first pair, but they both work (on my machine, at least). Because the second pair is also used, you can't assign that combination yourself.
shift ctrl alt up/down don't work on my system here. They only switch workspaces, they don't move windows to workspaces. Is there a gsetting or something I can check? It's a fresh f19 beta install up to date.
what do shift-super-page-up/down do on your system ?
also: what does gsettings get org.gnome.desktop.wm.keybindings move-to-workspace-down report ?
[asinha@localhost ~]$ gsettings get org.gnome.desktop.wm.keybindings move-to-workspace-down ['<Primary><Shift>Down', '<Control><Shift><Alt>Down'] [asinha@localhost ~]$ Since I've been tinkering with the keyboard shortcuts, this may not show the default values.. At the moment, shift-super-page-up/down do nothing. Thanks, Warm regards, Ankur
I reset the various settings: [asinha@localhost ~]$ gsettings list-recursively | egrep keybinding | egrep "workspace-(up|down)" org.gnome.desktop.wm.keybindings move-to-workspace-down ['<Super><Shift>Page_Down', '<Control><Shift><Alt>Down'] org.gnome.desktop.wm.keybindings move-to-workspace-up ['<Super><Shift>Page_Up', '<Control><Shift><Alt>Up'] org.gnome.desktop.wm.keybindings switch-to-workspace-down ['<Super>Page_Down', '<Control><Alt>Down'] org.gnome.desktop.wm.keybindings switch-to-workspace-up ['<Super>Page_Up', '<Control><Alt>Up'] [asinha@localhost ~]$ Now super-shift-page-up/down works as expected: moving the window to the workspace above or below. However, ctrl shift alt up/down does do this. It works like ctrl-alt-up/down and only changes workspace, without moving the window. Thanks, Ankur
I don't understand the problem here. Could you reset those gsettings keys and provide a clear reproducer of the problem and explain what you were trying to achieve?
(In reply to comment #7) > I don't understand the problem here. Could you reset those gsettings keys and > provide a clear reproducer of the problem and explain what you were trying to > achieve? I *just* fixed it with: $ gsettings reset-recursively org.gnome.desktop.input-sources I'm not sure how, but this was set: org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle'] Anytime I pressed ctrl alt shift, my input source would change, even when I have only *one* input source and therefore any command which required ctrl alt shift would not work. For the record, I wasn't trying to achieve anything. I selected English(UK) as my language, and that seemed to set my input source to English(UK) too. I corrected it, but this weird keyboard binding happened somehow. I'm still not sure how, since I didn't set it. You can close the bug if you're sure the random binding wasn't set by gnome somehow. Thanks, Ankur
(In reply to comment #8) > (In reply to comment #7) > > I don't understand the problem here. Could you reset those gsettings keys and > > provide a clear reproducer of the problem and explain what you were trying to > > achieve? > > I *just* fixed it with: > > $ gsettings reset-recursively org.gnome.desktop.input-sources > > I'm not sure how, but this was set: > > org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle'] This if Fedora 19 right? You probably set the option to switch keyboard layouts in anaconda which writes this out to a xorg.conf.d config file and then g-s-d picked it up from there. > Anytime I pressed ctrl alt shift, my input source would change, even when I > have only *one* input source and therefore any command which required ctrl alt > shift would not work. If you choose one of these "special" modifier-only keybindings for input source switching every other binding that includes those modifiers won't work since the X server sends a different keycode from them. > For the record, I wasn't trying to achieve anything. I selected English(UK) as > my language, and that seemed to set my input source to English(UK) too. I > corrected it, but this weird keyboard binding happened somehow. I'm still not > sure how, since I didn't set it. Where exactly did you select English(UK) ?
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > I don't understand the problem here. Could you reset those gsettings keys and > > > provide a clear reproducer of the problem and explain what you were trying to > > > achieve? > > > > I *just* fixed it with: > > > > $ gsettings reset-recursively org.gnome.desktop.input-sources > > > > I'm not sure how, but this was set: > > > > org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle'] > > This if Fedora 19 right? You probably set the option to switch keyboard layouts > in anaconda which writes this out to a xorg.conf.d config file and then g-s-d > picked it up from there. Fedora 19. Yes. > > > Anytime I pressed ctrl alt shift, my input source would change, even when I > > have only *one* input source and therefore any command which required ctrl alt > > shift would not work. > > If you choose one of these "special" modifier-only keybindings for input source > switching every other binding that includes those modifiers won't work since > the X server sends a different keycode from them. Ah. I'm not certain I picked any special bindings though. But I really can't remember, so I might just have. > > > For the record, I wasn't trying to achieve anything. I selected English(UK) as > > my language, and that seemed to set my input source to English(UK) too. I > > corrected it, but this weird keyboard binding happened somehow. I'm still not > > sure how, since I didn't set it. > > Where exactly did you select English(UK) ? I'm not certain. I've had this install up for a while now. I thought I selected it in either initial-setup or later, in settings. I don't think I chose it in anaconda. I do have this in xorg.conf.d: [asinha@localhost xorg.conf.d]$ cat 00-keyboard.conf # Read and parsed by systemd-localed. It's probably wise not to edit this file # manually too freely. Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "us" EndSection Since I don't have enough info to give you folks, it's going to be really difficult to do anything about this. I'll see if I can reproduce it sometime this week, otherwise I'll just close this bug. Thanks, Ankur
Hi, I am encountering the same bug : I just installed Fedora 19 and I am now unable to use Ctrl+Alt+Up and Ctrl+Alt+Down as shortcuts, they behave like Alt+Up and Alt+Down, as if the Ctrl key were not taken into account. However, Ctrl+Alt+Left and +Right (I use an extension that lets you have workspaces in a grid) are working ! I tried to follow what you did but it didn't solve the problem.
Ctrl+Alt+Up/Down are the secondary bindings for switch-to-workspace-up/switch-to-workspace-down and because of a bug in the keyboard panel handling of secondary bindings, they cannot be overriding. You can remove them from the bindings with gsettings on the command-line, look into the org.gnome.desktop.wm.keybindings schema. Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 673078 ***