Fix for touch window drag-and-drop #736
Conversation
|
Right now the window dragging works with this PR, but tiling scroll still gets stuck afterwards. Not sure what causes that. |
Thesola10
force-pushed
the
fix-touch-dnd
branch
2 times, most recently
from
b60442f to
acf4b47
Compare
Thesola10
changed the title
Thesola10
changed the title
|
Okay, this is weird. In my nested Shell, touch event coordinates match the global pointer exactly, but on my host Wayland session, it doesn't, which breaks everything. |
|
Okay, we may need to tell the stage to intercept all touch events to extract a facsimile of Most likely this means creating a broker object between |
This comment was marked as resolved.
This comment was marked as resolved.
Thesola10
force-pushed
the
fix-touch-dnd
branch
from
9bac039 to
eec4b6d
Compare
This is an incomplete solution, as the drag-and-drop event isn't properly finished in touch cases, requiring a trackpad swipe to "unlock" the situation. Also, while simple, moving the global pointer goes against expected touch behavior in GNOME, which is that touch events do not move the mouse. This could be adressed by memorizing and restoring the pointer as the event starts.
|
Actually, disregard the last commit message, any one event also "unlocks" the drag-and-drop event, so this is a reasonable fix -- at least it removes the softlock situation. |
…using PaperWM's built-in `warpPointer` method.
There was a problem hiding this comment.
Hey @Thesola10,
Looks good. I made a couple of small changes - mainly just a little linting/cleanup, and switched to using PaperWM's warpPointer util method (and improved it to made ripple animation showing optional).
Happy to approve this if you're happy with the changes.
Also a quick workaround to circumvent GitHub approval restrictions
|
yep, looks good to me! |
This fixes #735