shell icon indicating copy to clipboard operation
shell copied to clipboard

Change workspaces with Super + number

Open fourstepper opened this issue 4 years ago • 45 comments

Hello,

As generally to be seen in tiling WMs, the ability to switch between workspaces with a simple shortcut is very desirable due to speed.

Is this planned?

Thank you for the work

fourstepper avatar Apr 06 '20 08:04 fourstepper

This is already supported in GNOME. Super + Ctrl + Arrow

mmstick avatar Apr 06 '20 14:04 mmstick

@mmstick I think @RobinOpletal means something like Super+1 For the top workspace, Super+2 for the second, etc. Right now it looks like GNOME uses Super+Num to open apps on the Dash, though, so it would need to be something different.

cassidyjames avatar Apr 06 '20 17:04 cassidyjames

As @cassidyjames says, thaŧ's what I mean. Perhaps remapping those from the default shortcuts might be worthwhile, as this functionality is very essential for a quick-paced i3-like workflow, in my humble opinion

fourstepper avatar Apr 06 '20 17:04 fourstepper

@WatchMkr This would be very easy to implement. What do you think of switching workspaces with Super + Num?

mmstick avatar Apr 07 '20 02:04 mmstick

I think this is an essential remap as far as tiling goes. Using Super + Num to switch workspaces and Super + Shift + Num to send windows to workspaces is the default workflow in almost all tiling managers (see default configs for i3, bspwm, awesomewm, xmonad).

What's more, it is difficult to change the default GNOME keybindings for these keys. As @cassidyjames mentions, these keys are mapped by GNOME to opening apps on the Dash and the shortcuts are not displayed/editable under GNOME Settings. The user has to go digging into dconf to remap these. I think it would be very user-friendly (from a TM user perspective) to remap these keys by default to switching to and sending to workspaces.

mcaneris avatar Apr 07 '20 07:04 mcaneris

@mmstick Could we make this a setting in the extension's settings panel? I think overriding more default Gnome behavior will annoy more users than it will please. If it could be an option for those that want it, I feel like that would be best. Super + numbers to launch applications on the dash is something I use pretty regularly myself.

Those hotkeys may be default in conventional tiling WM's, but I think we should keep in mind that with the "Tiling by Default" setting turned off, this should feel as close to regular Gnome as possible. We will, after all, have far more users with only a Gnome background than we will users with conventional tiling WM backgrounds, and this extension (though not the tiling by default setting) will be installed and active by default.

leviport avatar Apr 07 '20 13:04 leviport

@leviport 's suggestion sounds great. At least an option for this would be greatly welcome

fourstepper avatar Apr 07 '20 14:04 fourstepper

I think it'd make sense for it to behave that way. The current behavior is very ill-suited for tiling, especially since we already have the launcher, and the dock is never seen unless you're in the overview.

mmstick avatar Apr 07 '20 14:04 mmstick

I think it'd make sense for it to behave that way. The current behavior is very ill-suited for tiling, especially since we already have the launcher, and the dock is never seen unless you're in the overview.

Unless you install dock to dash, as many users do. You also don't need to see the dock for the shortcuts to work, if you just remember the position of an app on it. I second @leviport suggestion, this would replace an useful feature with something that for many users isn't in any way practical to use

Kartonrealista avatar Apr 08 '20 18:04 Kartonrealista

Thanks for all the input. Let's give UX an opportunity to fully study this prior to introducing a behavior that's likely to change. With some creativity, I think we can cover both bases of quickly launching a list of personalized apps and switching to or moving windows to specific workspaces.

I anticipate this UX review and work going into the next major pop-shell release.

WatchMkr avatar Apr 08 '20 18:04 WatchMkr

I could be a great improvment. I used i3wm since 5 years now and talk a lot with the community on reddit. Workspaces are often used to separate applications. Concerning myself, I place my "systems" terminals on workspace 1. Emacs on 2, Firefox on 3, etc ... It is part of learning and muscle memory to store applications where it seems logical to us. Ultimately, a user knows that by typing SUPER + 3 he can use his browser

Qwarctick avatar Jun 30 '20 14:06 Qwarctick

Dear all,

First of all, thanks for making Pop Shell! As someone who loves the i3wm/sway way of working, but also enjoy the convenience of a full desktop environment, I recently switched to PopOS specifically because of Pop Shell. I agree with the posters above that this is an essential feature for a tiling window manager — since windows can't overlap, I typically actively use 4-6 workspaces when using a tiling window manager, in which case the default Win + Ctrl + Arrow keybindings become inadequate. Note also that this is more consistent with apps like Firefox and Nautilus, where Alt + number jumps straight to the corresponding tab.

As for how to implement this feature, here is what I've done myself. First, enable a static number of workspaces (e.g. 8 or 10):

gsettings set org.gnome.mutter dynamic-workspaces false
gsettings set org.gnome.desktop.wm.preferences num-workspaces 8

Then unbind all the GNOME default keybindings for switching between applications:

gsettings set org.gnome.shell.keybindings switch-to-application-1  []
gsettings set org.gnome.shell.keybindings switch-to-application-2  []
gsettings set org.gnome.shell.keybindings switch-to-application-3  []
gsettings set org.gnome.shell.keybindings switch-to-application-4  []
gsettings set org.gnome.shell.keybindings switch-to-application-5  []
gsettings set org.gnome.shell.keybindings switch-to-application-6  []
gsettings set org.gnome.shell.keybindings switch-to-application-7  []
gsettings set org.gnome.shell.keybindings switch-to-application-8  []
gsettings set org.gnome.shell.keybindings switch-to-application-9  []

Rebind them to switch between workspaces on Win + number:

gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-1  "['<Super>1']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-2  "['<Super>2']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-3  "['<Super>3']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-4  "['<Super>4']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-5  "['<Super>5']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-6  "['<Super>6']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-7  "['<Super>7']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-8  "['<Super>8']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-9  "['<Super>9']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-10 "['<Super>0']"

In addition, it's convenient to have Win + Shift + number move a window between workspaces:

gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-1  "['<Super><Shift>1']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-2  "['<Super><Shift>2']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-3  "['<Super><Shift>3']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-4  "['<Super><Shift>4']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-5  "['<Super><Shift>5']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-6  "['<Super><Shift>6']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-7  "['<Super><Shift>7']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-8  "['<Super><Shift>8']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-9  "['<Super><Shift>9']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-10 "['<Super><Shift>0']"

The above gsettings commands reimplement the workspace keybindings of i3wm and sway in GNOME; anyone else who are interested can of course just copy-paste these :wink: I have tested these on PopOS 20.04, and it works well. As suggested by the commenters above, it would however be useful to have a simple switch for turning this on and off in the Pop Shell settings.

Moreover, I think it would be useful if the adjustment mode (Win + enter) were to have keybindings for moving a window between desktops (e.g. just pressing 1, 2, 3, ... to send the currently active window to the workspace with the corresponding number). That is however something that would have to be implemented in Pop Shell itself, I can't do that with gsettings alone I believe.

It would be very useful for other users if a simple checkbox for toggling these settings could be integrated in Pop Shell! :smile:

jabirali avatar Jul 23 '20 15:07 jabirali

For some reason, using gsettings didn't work for me. However, directly using dconf did. If you have the same problem and don't want to jump into the dconf editor, here is the script that does the same as above:

dconf write /org/gnome/mutter/dynamic-workspaces false
dconf write /org/gnome/desktop/wm/preferences/num-workspaces 8

dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-1 "['<Super>1']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-2 "['<Super>2']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-3 "['<Super>3']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-4 "['<Super>4']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-5 "['<Super>5']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-6 "['<Super>6']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-7 "['<Super>7']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-8 "['<Super>8']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-9 "['<Super>9']"
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-10 "['<Super>0']"

dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-1  "['<Super><Shift>1']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-2  "['<Super><Shift>2']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-3  "['<Super><Shift>3']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-4  "['<Super><Shift>4']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-5  "['<Super><Shift>5']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-6  "['<Super><Shift>6']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-7  "['<Super><Shift>7']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-8  "['<Super><Shift>8']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-9  "['<Super><Shift>9']"
dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-10 "['<Super><Shift>0']"

jmbuhr avatar Aug 21 '20 10:08 jmbuhr

Has any progress been made on this feature or the UX review?

RickDW avatar Sep 15 '20 20:09 RickDW

Implementing this feature would be a great step. I found Pop!_OS while looking for something like Ubuntu (where the OS provides nice features like notifs, wifi menus, etc) but with support for tiling window management. I'm going to try the comments sent above, although I'd love to see numbered workspaces implemented officially so that I don't have to keep track of personal customizations :-)

Those hotkeys may be default in conventional tiling WM's, but I think we should keep in mind that with the "Tiling by Default" setting turned off, this should feel as close to regular Gnome as possible. We will, after all, have far more users with only a Gnome background than we will users with conventional tiling WM backgrounds, and this extension (though not the tiling by default setting) will be installed and active by default.

Would it be possible to have the numbered workspaces hotkeys enabled by default, but only when tiling is also enabled? Sounds like the best of both worlds, unless I'm missing something

aaronjanse avatar Sep 28 '20 11:09 aaronjanse

Just wanted to float an idea here to see what people thought. What if we leave the Super + 1 through 9 hotkeys alone, but instead use Super + F1 through F12 to switch to workspaces 1 through 12?

Pros:

  • No need to override current Gnome defaults (as far as I can tell, Super+F# keys are unbound).
  • Two additional workspaces we can switch to compared to normal number keys (maybe even more if you got one of these babies).

Cons:

  • Not exactly the same as i3.

leviport avatar Sep 28 '20 15:09 leviport

Just wanted to float an idea here to see what people thought. What if we leave the Super + 1 through 9 hotkeys alone, but instead use Super + F1 through F12 to switch to workspaces 1 through 12?

Pros:

  • No need to override current Gnome defaults (as far as I can tell, Super+F# keys are unbound).
  • Two additional workspaces we can switch to compared to normal number keys (maybe even more if you got one of these babies).

Cons:

  • Not exactly the same as i3.

Possible downside: this becomes e.g. Super + F1 on most desktop computers, but Super + Fn + F1 on many but not all laptops, where the Fn key sometimes even moves around between laptops. For people that love keyboard-driven workflows and use multiple computers daily, having different keyboard shortcuts on different machines is a bit problematic with respect to muscle memory. Super + # avoids this problem, as the number keys tend to stay in the same place.

jabirali avatar Sep 28 '20 15:09 jabirali

Definitely a good thing to consider, thanks!

leviport avatar Sep 28 '20 15:09 leviport

Plus, Super+F-Keys is more of a stretch for the fingers than to the number row.

jmbuhr avatar Sep 28 '20 15:09 jmbuhr

For anyone that would end up on this issue when trying to set workspace-switching shortcuts on Gnome: the gsettings invocations of @jabirali in https://github.com/pop-os/shell/issues/142#issuecomment-663079699 work well, but I had an issue on my machine (default Gnome on Fedora 32), below is the explanation and a fix.

On my system, the <Super>$n shortcuts were already used for something else (for example Super-7 would start the Software application). Unlike the "keyboard shortcuts" GUI, using gsettings will not notice the conflict: it sets the shortcut for the new action, but the other action keeps the same shortcut, and the new setting does not take effect (the shortcut remains on the previous action).

The only fix I found is to manually unset the actions with the conflicting shortcuts before setting switch-to-workspace-$n.

# those keybindings use <Super>1, etc. by default, and they need to be disabled explicitlyx
gsettings set org.gnome.shell.keybindings switch-to-application-1 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-2 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-3 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-4 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-5 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-6 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-7 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-8 "[]"
gsettings set org.gnome.shell.keybindings switch-to-application-9 "[]"

To locate which actions were responsible for the conflict, I used gsettings list-recursively to see all settings, and then grep.

gsettings list-recursively | grep -F "<Super>" # all shortcuts that contain Super
gsettings list-recursively | grep -F "'<Super>7'" # all Super7 shortcuts

gasche avatar Oct 04 '20 16:10 gasche

I'd love to be able to use the better workspace switching, so I've tried the manual setup from this thread. I can't get it to work however. I've tried it using both gsettings and dconf, and both do not throw out an error but refuse to change some of the settings. The things that I have been able to change are the static workspace setting, the number of workspaces, and the workspace switching and moving, but that last bit was only successful for workspaces 1 and 2 for some reason. Does anyone have a clue what might be wrong?

RickDW avatar Oct 24 '20 20:10 RickDW

Have you looked for other actions that would conflict by using the same shortcuts?

gasche avatar Oct 24 '20 20:10 gasche

It's sticking to the default ubuntu behaviour, so the conflict would be launching/opening applications that occupy the dock. I did run the provided code that sets switch-to-application-# keybindings to nothing, but that doesn't seem to work.

Other than that, I'm assuming ubuntu doesn't come with conflicting defaults and I know I haven't done any customization myself, so the switch-to-application keybindings should be the only conflict.

--edit If it is any help I've manually checked the output from 'dconf read .../switch-to-application-#' and all of them return '@ as []' at the moment (the same goes for the move/switch-to-application-# settings, and I've doubled checked all of them with gsettings as well). However, the weird thing is that <Super>1 switches to the first workspace as expected, but when I use <Super><Shift>1 it launches the first application in the dock anyway. It seems to be accepting my settings selectively for no reason at all.

--second edit It might be part of another problem I've been experiencing every now and then for the past few months. Sometimes super+q doesn't close a window, even though the keybinding is properly set up in ubuntu's settings. What it does do, is show the dash with numbers over the applications without launching an application. So it seems like super+q was somehow remapped to super+ a number higher than the number of applications that I have in my dash. I haven't been able to figure out what might be causing it, so far it seems like random behaviour. I'll open another issue if I find out more.

RickDW avatar Oct 24 '20 21:10 RickDW

It's sticking to the default ubuntu behaviour, so the conflict would be launching/opening applications that occupy the dock. I did run the provided code that sets switch-to-application-# keybindings to nothing, but that doesn't seem to work.

Other than that, I'm assuming ubuntu doesn't come with conflicting defaults and I know I haven't done any customization myself, so the switch-to-application keybindings should be the only conflict.

--edit If it is any help I've manually checked the output from 'dconf read .../switch-to-application-#' and all of them return '@ as []' at the moment (the same goes for the move/switch-to-application-# settings, and I've doubled checked all of them with gsettings as well). However, the weird thing is that <Super>1 switches to the first workspace as expected, but when I use <Super><Shift>1 it launches the first application in the dock anyway. It seems to be accepting my settings selectively for no reason at all.

--second edit It might be part of another problem I've been experiencing every now and then for the past few months. Sometimes super+q doesn't close a window, even though the keybinding is properly set up in ubuntu's settings. What it does do, is show the dash with numbers over the applications without launching an application. So it seems like super+q was somehow remapped to super+ a number higher than the number of applications that I have in my dash. I haven't been able to figure out what might be causing it, so far it seems like random behaviour. I'll open another issue if I find out more.

I just would like to add some other issues i encountered with shortcuts. Moving a window to different monitors is a problem sometimes as well. Not every time though, really weird.

Back to main topic. I was not able to change the key mapping in any way. I would love to be able to Super + num my workspaces for faster workflow...

EDIT: After multiple trying i was able to change these settings. Probably GNOME Tweek Tool was the issue here - probably it has overridden the short cuts settings. I removed it, and was able to change shortcuts. Except of Super + 4 and Super + 7 And I am also not able to detect, where the override comes from.

SergejGorev avatar Nov 30 '20 15:11 SergejGorev

I was able to manually create shortcuts using wmctrl. https://askubuntu.com/questions/41093/is-there-a-command-to-go-a-specific-workspace

Use wmctrl -s <workspace-number>

barestides avatar Dec 27 '20 19:12 barestides

Use wmctrl -s

wmctrl seems to be X11 only, and won't work on wayland ?

varac avatar Dec 28 '20 23:12 varac

The first 4 workspaces can be bound in the settings:

  1. Open settings
  2. Go to the "Keyboard" menu on the left side
  3. Under "Keyboard Shortcuts" click "Customize Shortcuts"
  4. Search for "Move window to workspace" to enable/rebind moving windows between the first 4 workspaces
  5. Search for "Switch to workspace" to enable/rebind switching between the first 4 workspaces

rdong8 avatar Jan 24 '21 23:01 rdong8

i just made a little script that i ran once (i wanted 10, set whatever you like):

gsettings set org.gnome.mutter dynamic-workspaces false
gsettings set org.gnome.desktop.wm.preferences num-workspaces 10
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-1 "['<Super>1']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-1 "['<Super><Shift>1']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-2 "['<Super>2']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-2 "['<Super><Shift>2']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-3 "['<Super>3']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-3 "['<Super><Shift>3']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-4 "['<Super>4']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-4 "['<Super><Shift>4']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-5 "['<Super>5']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-5 "['<Super><Shift>5']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-6 "['<Super>6']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-6 "['<Super><Shift>6']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-7 "['<Super>7']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-7 "['<Super><Shift>7']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-8 "['<Super>8']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-8 "['<Super><Shift>8']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-9 "['<Super>9']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-9 "['<Super><Shift>9']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-10 "['<Super>0']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-10 "['<Super><Shift>0']"

pm0u avatar Feb 17 '21 04:02 pm0u

No news on this? Is (for me) the only nice things missing :(

antimoroma avatar Mar 26 '21 11:03 antimoroma

For anyone still wanting to recreate i3 behaviour. In addition to the mentioned shortcuts, I've found that removing the workspace switcher popup with this extensions: No workspace switcher popup and have an indicator of the workspaces on the top bar Workspaces bar helps inmensively. It would be nice to be also included with the shell.

alonfnt avatar Jul 30 '21 21:07 alonfnt