Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change workspaces with Super + number #142

Open
fourstepper opened this issue Apr 6, 2020 · 37 comments
Open

Change workspaces with Super + number #142

fourstepper opened this issue Apr 6, 2020 · 37 comments
Labels
discussion enhancement New feature or request UX

Comments

@fourstepper
Copy link

fourstepper commented Apr 6, 2020

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

@mmstick
Copy link
Member

mmstick commented Apr 6, 2020

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

@mmstick mmstick closed this as completed Apr 6, 2020
@cassidyjames
Copy link

cassidyjames commented Apr 6, 2020

@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.

@fourstepper
Copy link
Author

fourstepper commented Apr 6, 2020

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

@mmstick mmstick changed the title [Feature Proposition] Changing workspaces with Super + number Change workspaces with Super + number Apr 7, 2020
@mmstick mmstick added discussion enhancement New feature or request labels Apr 7, 2020
@mmstick mmstick reopened this Apr 7, 2020
@mmstick
Copy link
Member

mmstick commented Apr 7, 2020

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

@mcaneris
Copy link

mcaneris commented Apr 7, 2020

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.

@leviport
Copy link
Member

leviport commented Apr 7, 2020

@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.

@fourstepper
Copy link
Author

fourstepper commented Apr 7, 2020

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

@mmstick
Copy link
Member

mmstick commented Apr 7, 2020

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.

@Kartonrealista
Copy link

Kartonrealista commented Apr 8, 2020

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

@WatchMkr WatchMkr added the UX label Apr 8, 2020
@WatchMkr
Copy link
Contributor

WatchMkr commented Apr 8, 2020

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.

@PhilippeNoel1
Copy link

PhilippeNoel1 commented Jun 30, 2020

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

@jabirali
Copy link

jabirali commented Jul 23, 2020

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 😉 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! 😄

@jmbuhr
Copy link

jmbuhr commented Aug 21, 2020

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']"

@RickDW
Copy link

RickDW commented Sep 15, 2020

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

@aaronjanse
Copy link

aaronjanse commented Sep 28, 2020

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

@leviport
Copy link
Member

leviport commented Sep 28, 2020

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.

@jabirali
Copy link

jabirali commented Sep 28, 2020

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.

@leviport
Copy link
Member

leviport commented Sep 28, 2020

Definitely a good thing to consider, thanks!

@jmbuhr
Copy link

jmbuhr commented Sep 28, 2020

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

@gasche
Copy link

gasche commented Oct 4, 2020

For anyone that would end up on this issue when trying to set workspace-switching shortcuts on Gnome: the gsettings invocations of @jabirali in #142 (comment) 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

@RickDW
Copy link

RickDW commented Oct 24, 2020

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?

@gasche
Copy link

gasche commented Oct 24, 2020

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

@RickDW
Copy link

RickDW commented Oct 24, 2020

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.

@SergejGorev
Copy link

SergejGorev commented Nov 30, 2020

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 1 switches to the first workspace as expected, but when I use 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.

@barestides
Copy link

barestides commented Dec 27, 2020

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>

@varac
Copy link
Contributor

varac commented Dec 28, 2020

Use wmctrl -s

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

@rdgh8
Copy link

rdgh8 commented Jan 24, 2021

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

@pm0u
Copy link

pm0u commented Feb 17, 2021

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']"

@antimoroma
Copy link

antimoroma commented Mar 26, 2021

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

@alonfnt
Copy link

alonfnt commented Jul 30, 2021

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.

@MikiVanousek
Copy link

MikiVanousek commented Sep 12, 2021

I feel like Pop!_OS need a config similar to i3's . See my post on Reddit if you want to know what I mean or want to support this idea and get this feature into the Pop!_OS!

@edumeneses
Copy link

edumeneses commented Nov 26, 2021

+1 for that. I love my Pop!_OS tiling experience, but as soon as I have more than 4 or 5 workspaces, it becomes painful to navigate and organize them.

@jofftiquez
Copy link

jofftiquez commented Feb 15, 2022

Can also be Super + Arrow Keys I liked it so much back in my Linux Mint days.

@arturi
Copy link

arturi commented May 30, 2022

Script for copy-pasting into the terminal, sets 9 workspaces and assigns switch to Super+N, move to Super+Shift+N:

sh << EOF
gsettings set org.gnome.mutter dynamic-workspaces false
gsettings set org.gnome.desktop.wm.preferences num-workspaces 9
for i in {1..9} 
do
  gsettings set "org.gnome.shell.keybindings" "switch-to-application-$i" "[]"
  gsettings set "org.gnome.desktop.wm.keybindings" "switch-to-workspace-$i" "['<Super>${i}']"
  gsettings set "org.gnome.desktop.wm.keybindings" "move-to-workspace-$i" "['<Super><Shift>${i}']"
done
EOF

@DrOptix
Copy link

DrOptix commented May 30, 2022

I have a similar issue. Before installing PopShell I was using Super+KP_Num to change workspaces and Super-Shift-KP_Num to move window to the workspace.

Yes for me makes more sense to use the numpad instead of the number's row.

Now since I installed PopShell even if num lock is on the KP_4, KP_8, KP_6 and KP_2 are acting like arrow keys. I have no problem for them to act as arrows as long the num lock is off.

Now my workflow is half good half bad :-D.

I looked in dconf for any keybinding config for PopShell, but I couldn't find anything. Any tips?

If this is hard coded, is it ok if I fix it and push a patch for my use case?

@DrOptix
Copy link

DrOptix commented May 30, 2022

Update. I've set those, but it seems that PopShell still uses <Super>KB_Down and the company somehow.

dconf write /org/gnome/shell/extensions/pop-shell/focus-left "['<Super>Left', '<Super>h']"
dconf write /org/gnome/shell/extensions/pop-shell/focus-down "['<Super>Down', '<Super>j']"
dconf write /org/gnome/shell/extensions/pop-shell/focus-up "['<Super>Up', '<Super>k']"
dconf write /org/gnome/shell/extensions/pop-shell/focus-right "['<Super>Right', '<Super>l']"

Those are all the keybindings I try to set, for now:

dconf write /org/gnome/shell/extensions/pop-shell/focus-left "['<Super>Left', '<Super>h']"
dconf write /org/gnome/shell/extensions/pop-shell/focus-down "['<Super>Down', '<Super>j']"
dconf write /org/gnome/shell/extensions/pop-shell/focus-up "['<Super>Up', '<Super>k']"
dconf write /org/gnome/shell/extensions/pop-shell/focus-right "['<Super>Right', '<Super>l']"

for i in (seq 1 9); 
    # Gnome Shell: Key bindings to move windows to workspaces
    dconf write /org/gnome/desktop/wm/keybindings/move-to-workspace-$(echo $i) "['<Ctrl><Shift><Super>KP_$(echo $i)']" 
    
    # Gnome Shell: Key bindings to switch to a workspace
    dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-$(echo $i) "['<Ctrl><Super>KP_$(echo $i)']"
end

@venkatesh-thirupathi-h
Copy link

venkatesh-thirupathi-h commented Sep 17, 2022

the alternative solution before pop shell officially supports workspaces like i3 is really helps me, I really like i3 but It annoys my coworkers, this is a great solution for now thanks everyone, especially for @gasche for pointing out that other things may be binded to #s, thanks you @gasche

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement New feature or request UX
Projects
None yet
Development

No branches or pull requests