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

Super-left shortcut moves window, when it shouldn't (with ubuntu's vanilla-gnome-desktop) #233

Closed
njsmith opened this issue Jan 20, 2020 · 11 comments
Labels
fedora Issue occurs with Fedora's modified GNOME ubuntu Issue occurs with Ubuntu's modified GNOME

Comments

@njsmith
Copy link

njsmith commented Jan 20, 2020

I'm using paperwm on Ubuntu 19.10, with gnome-shell version 3.34.1+git20191024-1ubuntu1~19.10.1

Apparently in this distribution of gnome-shell, by default the Super-left and Control-Super-left keys are both bound to toggle-tiled-left, and Super-right and Control-Super-right are both bound to toggle-tiled-right:

~$ gsettings list-recursively | grep toggle-tiled
org.gnome.mutter.keybindings toggle-tiled-right ['<Super>Right', '<Primary><Super>Right']
org.gnome.mutter.keybindings toggle-tiled-left ['<Super>Left', '<Primary><Super>Left']

(Note: <Primary> is an alias for <Control>. Also note: these don't show up if I do dconf dump, which I believe means that they're coming from the application's default schema, rather than any local setting on my computer.)

This is problematic for paperwm, because it wants to take over Super+left and Super+right to change focus, while Super+Control+left and Super+Control+right are supposed to pick up the current window and move it. And as described in the paperwm README, this takeover system needs some tricky hacks, and can get confused if you have different keys bound to the same action. In my case, the symptom was: by default Super+right would shift focus to the right, but Super+left would move the current window to the left. Pretty confusing.

To work around this, I removed the extra keybinding:

~$ gsettings set org.gnome.mutter.keybindings toggle-tiled-right "['<Super>Right']"
~$ gsettings set org.gnome.mutter.keybindings toggle-tiled-left "['<Super>Left']" 

and then restarted gnome-shell. Now Super+left and Super+right work correctly in paperwm.

However, since this seems to be the default behavior in Ubuntu (and maybe all gnome-shell versions in the future?), it would be good if paperwm had a more robust way of handling it that didn't require all users to make these overrides.

@hedning
Copy link
Member

hedning commented Jan 20, 2020

Unfortunately, as far as I know it's not possible to disable a native mutter action without clearing the keycombo array (as described in the issue). It is possible to override what code is called when the action is triggered however, which is what we do currently.

In general I don't think it's good to mess with gsettings without the users consent, as it's not necessarily easily reversible. So, I'm guessing the best way to handle this is detecting these problems and asking the user if they'd like us to fix it. (probably makes sense to capture the previous state, leaving the user with the option to restore).

@hedning
Copy link
Member

hedning commented Jan 20, 2020

So, looks like it's specifically vanilla-gnome-desktop that ships with these weird toggle-tiled-left/right bindings. I'm guessing ubuntu-gnome-desktop might be a better package to use on ubuntu, though not sure 😆

@njsmith
Copy link
Author

njsmith commented Jan 20, 2020

Huh, interesting. It looks like they're specifically from /usr/share/glib-2.0/schemas/20_vanilla-gnome-default-settings.gschema.override, which is part of the vanilla-gnome-default-settings package.

If those aren't actually the correct default settings, then maybe this is a bug in that package, and it could be fixed upstream?

@hedning
Copy link
Member

hedning commented Jan 20, 2020

It's certainly strange that something that's called vanilla-gnome overrides the bindings used by upstream gnome shell, yes :) So I guess ubuntu might be open to change that.

@hedning hedning changed the title Super-left shortcut moves window, when it shouldn't Super-left shortcut moves window, when it shouldn't (when using ubuntu's vanilla-gnome-desktop) Jan 20, 2020
@hedning hedning changed the title Super-left shortcut moves window, when it shouldn't (when using ubuntu's vanilla-gnome-desktop) Super-left shortcut moves window, when it shouldn't (with ubuntu's vanilla-gnome-desktop) Jan 20, 2020
@njsmith
Copy link
Author

njsmith commented Jan 20, 2020

Do you know where upstream gnome shell sets those? I can open a bug with ubuntu, but it would be helpful to have a link I can give them to prove that the gnome defaults are different :-)

@hedning
Copy link
Member

hedning commented Jan 20, 2020

@njsmith
Copy link
Author

njsmith commented Jan 20, 2020

https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1860382

@hedning hedning added the ubuntu Issue occurs with Ubuntu's modified GNOME label Jan 21, 2020
@jtaala jtaala added the no longer valid? Issues that are suspected to be no longer valid label Apr 6, 2023
@jtaala
Copy link
Collaborator

jtaala commented Apr 6, 2023

I haven't seen this behaviour/issue in recent versions of gnome (although I've only been using / testing on Gnome 40+).

Please post if this is still a valid issue (given time since submitting and progress of PaperWM since then).

If not, will close this issue in a month or so.

@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2023

I haven't seen this behaviour/issue in recent versions of gnome (although I've only been using / testing on Gnome 40+).

Please post if this is still a valid issue (given time since submitting and progress of PaperWM since then).

If not, will close this issue in a month or so.

Scrap that - I observed this recently on Fedora 38 (Gnome 44) - see #516.

Resolution was the same, disabling default gnome super+left/right tiling keybinds.

@jtaala jtaala added fedora Issue occurs with Fedora's modified GNOME and removed no longer valid? Issues that are suspected to be no longer valid labels Apr 25, 2023
@jtaala
Copy link
Collaborator

jtaala commented May 27, 2023

Note that issue I mentioned above was fixed in #515 and #530.

@jtaala
Copy link
Collaborator

jtaala commented Nov 19, 2023

Closing as fixed (see previous comment)

@jtaala jtaala closed this as completed Nov 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fedora Issue occurs with Fedora's modified GNOME ubuntu Issue occurs with Ubuntu's modified GNOME
Projects
None yet
Development

No branches or pull requests

3 participants