wry
wry copied to clipboard
tauri-apps
Undecorated window doesn't support resizing using touch
Is your feature request related to a problem? Please describe. The custom_titlebar example does not handle window resize when dragging the window borders using touch events. (It handles windows move using touch or mouse, but resize only using the mouse.)
Describe the solution you'd like Resize window using touch-drag of windows borders.
Would you assign yourself to implement this feature? Don't know what is needed.
Additional context Tested on Fedora Linux 34, with Gnome/Wayland desktop. See issue #397.
@PerBothner Can you test this PR https://github.com/tauri-apps/wry/pull/402 and see if resizing using touch works properly ? I don't have a touch screen to try unfortunately.
Works great. (Hover-on-mouse also works good now, but I assume you've been able to test that.) Thanks!
@PerBothner would love to hear from you on discord about this https://discord.com/channels/616186924390023171/731495028677148753/881293004114116618
Idon't have a discord account and not sure I want to create one. Any way you can summarize or send me the text?
One of our team members tested the PR on his fedora gnome and recorded a weird behavior, and was wondering if you also have that. here is the video
https://user-images.githubusercontent.com/48618675/131231990-58530e32-658d-4ae0-8bbb-71f6384d6a17.mp4
Not seeing that. The border follows my finger until I raise it.
I'll be mostly busy until tomorrow evening.
Since it works smoothly on my laptopn (a newer Lenovo running Fedora/Gnome), I would suspect a problem with the hardware or device driver. I might be able to test it on an older HP laptop, though probably not today.
One other thing to do (if you haven't already) is ask your team-member to test dragging-by-touch on other applications on the same laptop: Gnome apps, KDE, Electron, etc. And of course Wry examples without custom-titlebar.
I'm the one you're talking about :P
I already did that on Linux and Windows. I haven't found any other app that behaves like this (yet). Decorated tauri/wry apps work fine too.
Edit: Whoops i'm sorry lol, i tested electron apps only on KDE where they behave normaly, but on Gnome they aren't movable/resizable at all (which kinda feels better than the behavior shown in the video). Gonna test the wry example on KDE later today...
Edit2: Yeah, the custom_titlebar example works absolutely perfect on KDE. So Gnome doesn't like my device i guess 🤷
Edit3: Okay i tested some more distros with gnome on live usb and almost all work as expected. No idea what makes some broken. Especially since the fedora installation in the video is actually a fresh install which doesn't work, while a fedora live usb works... So imo we can just call this implementation generally working (although it would be nice to see some other devices tested). Maybe it's just one (system-)dependency or whatever, which is broken on like one exact version 🤷
Given the situation, one option is to just merge the change, as it doesn't appear to break anything, and fixes an actual bug in at least many (but not all) situations. But I understand it is frustrating to have someone that mostly works but sometimes fails for reasons not understood.
One possibility is this is a Wayland vs X11 issue: When running KDE I believe you are running on a traditional X-server, while with Gnome you are running Wayland (along with XWayland). Though that doesn't explain live usb vs actual install.
Another possibility is there is some driver glitch or instability that some ways of programming are more susceptible to. One idea is to look at the source code for some Gnome application with custom title bar (for example Gnome Terminal or Gedit or Epiphany) and see how they handle border-drag, comparing it with logic in the patch.
Finally, one could do a modified version of the custom_titlebar example with event handlers for every possible relevant event, where the handler does nothing but write to the console. Comparing the output for when things work vs when they don't may be enlightening.
Given the situation, one option is to just merge the change, as it doesn't appear to break anything, and fixes an actual bug in at least many (but not all) situations. But I understand it is frustrating to have someone that mostly works but sometimes fails for reasons not understood.
We are probably gonna merge it as it works good enough but we are in a code-freeze phase right now until our security audit is finished, so it will take a while to get merged.