-
Notifications
You must be signed in to change notification settings - Fork 130
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
Comments
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). |
So, looks like it's specifically vanilla-gnome-desktop that ships with these weird |
Huh, interesting. It looks like they're specifically from If those aren't actually the correct default settings, then maybe this is a bug in that package, and it could be fixed upstream? |
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. |
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 :-) |
👍 this is where it's done in mutter: https://gitlab.gnome.org/GNOME/mutter/blob/master/data/org.gnome.mutter.gschema.xml.in#L145 |
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 |
Closing as fixed (see previous comment) |
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:
(Note:
<Primary>
is an alias for<Control>
. Also note: these don't show up if I dodconf 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:
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.
The text was updated successfully, but these errors were encountered: