-
Notifications
You must be signed in to change notification settings - Fork 131
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
Conflicting keybindings are not working in gnome 43 #533
Comments
Ha, that is strange. I can confirm that those keybinds work fine on gnome 44 (with/without the gnome system clashes). Could you test something for me? If you're on Gnome 43.5, could you confirm the issue doesn't occur of We backported the keybind changes from Gnome 44 to Gnome 43 branch, so if the above tests works okay, then it must be something else in Gnome 44 branch ( In any case, I don't have Gnome 43 to test (and hence won't be able to reproduce/fix gnome 43 issues any longer), and there's no guarantee that future PaperWM changes in Gnome 44 won't break things in Gnome 43 (or 42, 41, or 40), hence, we've created the |
I'm of a mind to remove Gnome 42, 43 support in the develop branch |
That does seem reasonable if you run on e.g. Archlinux. But my guess is that distros like Ubuntu are still most commonly used (although I don't know if that is also true for PaperWM users). If possible, I think we should continue to support the last Ubuntu LTS (which at the moment is Ubuntu 22.04, which still have Gnome 42). Also I think it is nearly impossible to install newer gnome versions on older Ubuntu distros. But maybe I'm a bit biased because I have to use Ubuntu 22.04 at work^^ And unfortunately there also won't be an update to Ubuntu 23, since it is not LTS. But I'm totally fine with removing anything older than 42. Also it may be easier to backport the changes separately to gnome 42, instead of maintaining it all on one branch. |
The main issue I find I have is that I don't run gnome 43, 42 (or 41, 40, 3.38, etc.).. and if I don't run them I can't test them... if I can't test them, I can't fix them... if I can't fix them then I can't really maintain them. For example, I find I can't really do much with reports like "the current develop branch doesn't work on gnome 43 properly... or gnome 42 properly) - other than maybe "you could try this..." or "please just use the gnome-43 branch please since it used to work". In order to support prev gnome versions - other than keeping the branches that worked on those versions - we need developers who use those versions and can test and backport fixes etc. where needed (or fix issues on still on those versions). I'm happy to keep the "43", "42" in the metadata.json, but all I"ll be able to say is --- "please fix that in that older gnome version and submit a PR". E.g. it'll be up to others to submit PR's to fix issues in those gnome versions for I think a much better alternative given these issues is for users of older gnome versions to use the associated branch (e.g. gnome-42, gnome-43) and if there are issues they find (in those branches) then to fix them and submit PRs (or if they identify a fix in current |
I just set up a Ubuntu 22.10 VM (with gnome 43.1). There on the Regarding how to handle gnome 43 and 42 testing. I would am willing to test changes for gnome 43 in a VM (like I did for this). But since I also no longer actively use gnome 43, I probably won't create backports or fixes myself. Since I still use gnome 42 actively I might then create backports/fixes for the gnome-42 branch. I've come around on the idea of setting the |
Confirm that @Lythenas's PR also fixes a similar keybinding bug that was tripping me up the past few weeks.
On With the PR, the keybindings work as expected 🥳 |
Found it. So, interestingly, it's this line that breaks keybinds in Gnome 43 & Gnome 42 (basically prior to Gnome 44) and is only need on Gnome 44: Line 245 in 9a1611a
In Gnome 44 the return was changed to 3 arguments. I just tested in Gnome 43 (did the same with a VM). This means that we just need to revert keybind backports from Gnome 44 in Gnome 43 etc. |
Or in other words, just revert that line (removing the 'ok'). |
Hey all, big thanks to @Lythenas for testing this out and creating some PRs. I've now implemented a multi-gnome version fix/PR that should fix this once and for all - see #539 for details. @lediur, @Lythenas can you please test this PR/branch. I've testing on Gnome 43 (just bit the bullet and installed a 43 vm) and also Gnome 44.
and then logout/login. Thanks |
Just tried out the branch. Keyboard shortcuts appear to work as expected. Thanks for your work on this fix! |
… earlier) keybind clash detection (#539) See #537 #538 PR's which reverts changes that were backported to Gnome 43/42. This PR is a replacement for these individual reverts PRs. This PR implements a fix which first checks the number elements returned from Gtk.accelerator_parse (whether 2 or 3) and assigns them correctly. This is a much better/robust fix that means that this should now work regardless of what gnome version is used. Fixes #533, #536. The issue was caused by Gtk.accelerator_parse result changing in Gnome 44. There is confusion about when this change occurred, e.g. [GJS porting guide](https://gjs.guide/extensions/upgrading/gnome-shell-40.html#gtk-accelerator-parse) suggests this change occurred in Gnome 40, however actually testing in Fedora 37 (and purportedly in other Gnome 43, 42) versions it's still returning 2 elements instead of 3. This PR addresses both cases.
Hey all, This should now be fixed in |
Interesting! I'm coming around also to the idea that there might be a chance (and we should at least try a bit more) to have What about this?:
Anyways, just thinking out loud. Btw, I've created #540, which aims to help this a bit (at least with the keybinds which should work on 44 and previous versions). Aiming to merge that in |
I would be ok with either approach. But we should clearly communicate which versions are supported. |
#540) This PR relates to #539. #539 implemented a previous-gnome version backwards compatible change for keybind clash detection. Closes #533. Gnome 44 changed `Gtk.accelerator_parse` result, that originally broke keybind clash detection. The result of `Gtk.accelerator_parse` differs in Gnome 44 and previous gnome versions. To make matters worse, there is some confusion about when this change occurred, e.g. [GJS porting guide](https://gjs.guide/extensions/upgrading/gnome-shell-40.html#gtk-accelerator-parse) suggests this change occurred in Gnome 40, however actually testing in Fedora 37 (and purportedly in other Gnome 43, 42) versions, this change wasn't Gnome 43, 42, 41, or 40... but is in Gnome 44. In any case, this change implements a fix that will work in all gnome versions (or more specifically, will work correclty with the different `Gtk.accelerator_parse` results. In essence, it checks the output and correctly assigns the result elements (regardless of gnome version). This PR is largely aimed at users that want to use (and test) the current `develop` branch with older gnome versions. Ideally, we would like to have `develop` branch compatible with previous gnome versions. This PR at least fixes one issue and brings us closer to that ideal.
Okay, if you've been using Gnome 42 fine on |
Will do up a PR for that today to get others' thoughts. |
See #542. |
Describe the bug
Conflicting keybindings (e.g. Super+Shift+Left/Right to navigate monitors) are not working if they are also bound in gnome itself.
To Reproduce
Steps to reproduce the behavior:
Note that not even the action it is bound to in gnome is executed.
Removing the conflicting keybinding in gnome fixes this issue.
Expected behavior
PaperWM keybindings should take precedence.
Screenshots
If applicable, add screenshots to help explain your problem.
System information:
Please execute
./gather-system-info.sh
in you PaperWM clone and paste the output below.Additional context
Note that the commit is from PR #532 which is one commit ahead of
develop
.@jtaala you recently made changes to fix the issue of conflicting keybindings on Gnome 44. Could this have broken the behavior on Gnome 43?
Also note that I am now updating to Gnome 44 and now have only a machine with Gnome 44 and Gnome 42 to test. But I wanted to put this up. In case it is easy to do, I think we should fix this. Otherwise, I think the gnome43 branch works fine.
The text was updated successfully, but these errors were encountered: