Fixes: add Gnome 44 support #515
Conversation
…eplaced with new clutter grabs.
Window.clone undefined exception during testing.
|
Fiddlesticks... so, I've run into deadends with the grab and drag windows for Gnome 44. They removed the ability (as far as I can see) to stop a gnome grab operation (which was previously done with Gnome did this since now it does it all internally and automatically now... which is simpler... except if you don't want to do grab/drag operation and want to do your own (PaperWM wants to do this). As mentioned in this PR - it works... but the grab operation is still running after we finish our grab/drag operations... and we then need to "click" again to stop the default gnome drag operation. It's annoying, but I'm not sure how to (or if we can) fix that in Gnome 44. Hopefully, we can find another way to end the default grab op before we do our own. The method/functionality is still there but I haven't found a way yet to access it. If anyone has any ideas here - either how to stop the default gnome |
…uped other polyfills.
…eration to force `end_grab_op`.
Huzzah! so I've implemented a fix for the "needs a second click after pointer grab/moving a window" issue. Spent a few days trying to regain access to the In the end "if you can't beat em, join em"... we now embrace (lol) the new grab behaviour and then generate a "click out" event automatically to force an internal |
|
To all gnome-44 PaperWM users - could you please test this branch out and report back how it's working for you? It's working well now in Fedora 38 for me. and do a logout/login etc. |
|
@Lythenas, if you're on 44, give this a test. If you're on 43 for your main setup (like me) please test this out (in principle, this PR won't impact/change gnome 43 behaviour as the main changes are polyfills and if |
|
I updated On a relate note, is this still relevant in |
|
Okay, this is now fixed - now using Clutter.virtualInputDevice - which is safe for X11 and Wayland. |
… grab operation to force `end_grab_op`." `gi.Atspi` appears to have severe issues in Wayland - was getting gnome shell hard crash in wayland with this (X11 is fine). This reverts commit 566f628.
…t" of pointer grab operation to force `end_grab_op` Now using Clutter virtual device to "click out" - safe to use in X11 and Wayland.
|
I'll be running the latest commits for the day today. So far so good. Though I wasn't hitting the drag/drop issue and am not clear whether it could be reproduced to test. I don't think I use the mouse enough. |
…an cause holding onto titlebar and maximizing window). Moved click out to main loop after activate.
…ion. Also moved to Meta.LaterType.BEFORE_REDRAW for safety.
|
I'm seeing some very weird issue which is both hard to describe and hard to reproduce. Sometimes when I use my mouse to cycle between opened windows (by clicking on the edge), the WM starts to act as if I started to drag a window. Once I hit this it is very difficult to get out of it - it makes things quite unusable. Last time it happened I just started clicking around and mashing some keys on the keyboard and eventually I managed to get out of it. Very frustrating. EDIT: Got triggered again simply by pressing Win+Right to switch the active window. Ugh. Think I'll revert to 43 for now. |
Yes, I hear you. Unfortunately, Gnome 44 completely removed the ability to stop using their new grab/drag Clutter grab actions. This has left us with really no good option. We're trying to work around this, but it has impacted various things in PaperWM with mouse clicking - I hadn't seen the one with clicking on window previews. All, unless we can find stable workarounds - I'm starting to get the sinking feeling that the only real option is to fork mutter and re-add the ability to end / disable gnome's default grab/drag actions (which was previously available publicly). Hopefully we don't need to go there as it's seems crazy just to restore the ability to |
Sinking feeling indeed! This would also complicate matters for anyone already using a patched mutter. Probably a small number - I'm using https://copr.fedorainfracloud.org/coprs/calcastor/gnome-patched/. Though tbh I'd prioritise PaperWM over it. |
|
Hey all, I've now implemented some fixes/changes - could you give this one a test? (apologies for lots of test requests - this gnome 44 changes has thrown us for a loop). Latest changes in this PR seems to be behaving better in my (brief) tests - but others running it for a day (@crispinb, @paradajz etc) would help confirm. |
Thanks - that looks fine. Assuming you logged out / logged in again after switching branches etc. Any logs output would be appreciated too (just output from |
Here: #515 (comment) |
|
I really don't know how to reproduce. It happens randomly. I just clicked onto a window and the dragging operation started. |
|
I've disabled the extension, run the journalctl, enabled PaperWM, switched to the window and the dragging occurred instantly. Nothing special in the log: |
|
Hmm - yeah, nothing in the logs there. I just want to rule out branch issues, if you haven't already done so, if you're on the branch, can fully logout/login (or even reboot - gasp) - you're probably aware but disabling/enabling isn't enough after a branch change. After this, just for testing, I'll get you to fully disable window dragging and see if you're still getting that issue. |
|
I did log out, no worries, I actually performed system upgrade, pulled the changes, then restarted my PC. |
A few other things to check,
if still no luck, can you disable these lines (comment out or delete) in tiling.js: https://github.com/paperwm/PaperWM/blob/fixes-gnome-44-support/tiling.js#LL1669C1-L1672C67 Then logout/login (or looks like you're on X11 so can do a |
|
Just want to double-check, if you're still getting drag issues after that last one then there's something else going on. |
I've had one issue but no idea how to reproduce it. Got stuck in a state where the scroll wheel would switch between windows horizontally and nothing else. Escape wouldn't get out either, and ultimately had to reboot. Happened once in a whole day. |
org.gnome.desktop.wm.keybindings switch-group org.gnome.desktop.wm.keybindings switch-group-backward org.gnome.desktop.wm.keybindings switch-to-workspace-left org.gnome.desktop.wm.keybindings switch-to-workspace-right
|
Okay - did a total reinstall - wiped everything and started from scratch - so far so good. Hope it stays that way. :) @jtaala your work is unbelievably appreciated here. |
|
I've been f/t on the penultimate commit (477e87a) for the last couple of days. All's been good for me (though I only tend to use the mouse to arrange windows in the scratch layer, so may not come across infrequent dragging problems). |
This is interesting, @paradajz, could you give us a bit more info on the reinstall - you didn't have to reinstall the OS did you? Was it just a reinstall of PaperWM? (and if so how did you do that - delete the extension (just click the What's interesting, is that (I believe) you previously tried this branch on an older commit - and then reverted back to Gnome 43 (since we were still trying to figure out the grabbing issues). If that's the case, it seems that a checkout of that older commit was still symlinked to Oh, did you wipe/reset the paperWM gnome settings (in like dconf or something?). Appreciate any info here so we can record and try to avoid this happening again for others. |
mismatch on Gtk.accelerator_parse.
|
To be honest I'm not sure what happened in my setup but I did had two PaperWM versions in extensions directory - the one from this repo and the other one from your redux fork. Right now I'm not sure what was active. I've removed symlinks for both of them and then reinstalled the extension (not the entire OS :)). So far everything working fine - didn't run into dragging issue since yesterday. |
|
Happy to confirm that PaperWM works really well again thanks to all the work you put into this branch and also thanks to all the contributions in forms of feedback and bug reports. I am on Fedora 38 and run Gnome 44 on Xorg. No dragging issues, keybindings work reliably, it's a real pleasure to use it (again :D)! |
…keybinds that used to clash before fixing keybind clash detection). Also renamed parameter for keybind fix to reflect Gtk documentation name better.
|
Big thanks to everyone for helping with Gnome 44 support in PaperWM. It was quite a bit more work than first envisioned (those Clutter grab changes threw us for a loop!). Much appreciated all. |
|
Thanks @jtaala! p.s. : |
jtaala
removed
the
merging soon
This PR fixes reported issues in Gnome 44: fixes #494, fixes #495, closes #490, fixes #523.
Note: these are compatibility fixes to support Gnome 44 in develop branch (i.e. Gnome 43 should still work fine with these changes).
Gnome 44 has a new (improved?) mechanism for grabs (e.g. grabbing and moving windows), and no longer uses
end_grab_op.This PR also adds a polyfill to support Gnome 44's removal of
Meta.later_add(which is replaced withglobal.compositor.get_laters().add(...).Note: GJS porting guide suggests using
Meta.Laters.addbut in testing the latest Gnome 44 (and what was released in Fedora 38), this was not present. The implemented approach is used heavily in the latest/official gnome-shell source code (which is why I moved to using that).Note2: for the first fix (fix now implemented for this ✔️end_grab_op) - it still not quite perfect, it seems to require a second click to activate a window (after moving a window) - but at least it doesn't completely/irreversibly lose mouse click control.Will look at this and see how to improve here.