rust-windowing
Support drag and drop on wayland
Drag and drop window events are currently not supported on wayland.
I wonder how it is possible to implement it considering smithay-client-toolkit contains some helper for it: DataDevice.
Can we use https://github.com/Smithay/wayland-rs i.e. wayland-client for implementation? Smithay's wayland client toolkit builds on top of it, so it should be a seamless integration.
The wl_data_device_manager might be what we need to implement drag and drop in wayland: `https://smithay.github.io/wayland-rs/wayland_client/protocol/wl_data_device_manager/index.html
The DataDevice helper can be used by itself too. smithay toolkit isn't an all-or-nothing kind of thing; it's perfectly feasible to cherry pick individual helpers.
@WhyNotHugo gnome breaks if you bind multiple data devices(it'll use only one of them), so unless winit has clipboard adding drag and drop is not possible.
Upon further inspection (I was trying to use DataDevice directly in my application) it seems that it's been dropped in sctk-master anyway, so it's best not to rely on it.
I'm not sure what the correct behaviour is when binding to a global twice, but I'm pretty sure it's not something that should be done anyway.
I'm not sure what the correct behaviour is when binding to a global twice, but I'm pretty sure it's not something that should be done anyway.
If something is missing is stck master, it's only because it wasn't ported yet. SCTK had abstractions for dnd and clipboard(it's the same thing) for a long time. We have a PR adding DND already for Wayland, it just breaks clipboard on gnome, because gnome doesn't allow client to bind multiple times to data device.
Data device support is specifically one of the blockers for the next release of sctk. There's a PR for it: https://github.com/Smithay/client-toolkit/pull/301
I'm not sure what the correct behaviour is when binding to a global twice, but I'm pretty sure it's not something that should be done anyway.
Good question. Maybe the Wayland protocol spec could use some clarification on this? Normally binding something multiple times is perfectly fine and works correctly (and may be needed when multiple libraries are making Wayland calls), so without text in the spec about this the Gnome behavior sounds incorrect.
Good question. Maybe the Wayland protocol spec could use some clarification on this? Normally binding something multiple times is perfectly fine and works correctly (and may be needed when multiple libraries are making Wayland calls), so without text in the spec about this the Gnome behavior sounds incorrect.
That works fine on sway for example, it just gnome is special and doesn't bother to fix anything. I bet it still sends modifiers events incorrectly and I have to carry workarounds for gnome to ignore its non-compliance to wayland protocol.
Ah, thanks for pointing out the new DataDevice implementation in sctk, I'd missed it. This seems to bind the data device global only once for both clipboard and drag-and-drop, so should be usable here, right?
Looks like the GNOME bug was fixed: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1253 https://gitlab.gnome.org/GNOME/mutter/-/commit/7e4e3714663952a69ba0a26662841fc5c0cb266c
This seems to bind the data device global only once for both clipboard and drag-and-drop, so should be usable here, right?
I believe the issue is that winit doesn't currently provide clipboard support (https://github.com/rust-windowing/winit/pull/2156). It looks like toolkits and such in Rust are currently mostly using smithay-clipboard (directly or via a crate that abstracts multiple platforms). But another library like that will bind its own copy of the data device.
So I guess to fix it on the version of Mutter with this issue, it would be necessary to also add clipboard support to winit, and then software updating to the new version of winit would need to update their clipboard support to use winit's implementation. Which for the most part is probably how it should be done anyway.
Though maybe not an issue if it was fixed in Gnome a couple years ago? Not sure what release it made it into of if it was backported. Or if this is any issue in any other compositor.
GitLab indicates that the fix made it to the gnome-3-36-backport branch: https://gitlab.gnome.org/rmader/mutter/-/commit/1ec91cc8eef1db353d852fc4c212cae3a9cb1aee
Okay, so that should be on Ubuntu 20.04 (the previous LTS) and the like.
That sounds like it should generally cover current Gnome users that are using Wayland.
Any updates regarding this? Or better said, is there any blocking instance left?
#3367 is completed as of almost a year ago. Would it be possible to note the latest blockers to fixing this issue?
I tried applying #4009 and it seems to fix the problem in my example application.
Anything new on this? We need this in the upcoming Graphite Desktop App. Are there any blockers or anything else we might be able to help with?
The question is whether you'd need it in winit 0.30 or 0.31. Assuming that we're talking about dnd in the form it is right now which is very limited.
Depends on the timeline for 0.31. Will the dnd system be reworked in 0.31? If yes, does that mean Wayland support will not come in 0.30 because you prioritize the long term solution?
We are trying to release soon, but Linux/Wayland features missing will not be blocking.