search

rust-windowing / winit

Window handling library in pure Rust
https://docs.rs/winit/
Apache License 2.0
4.8k stars 899 forks source link

Support drag and drop on wayland #1881

Open gui1117 opened 3 years ago

gui1117 commented 3 years ago

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.

tfachmann commented 2 years ago

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

WhyNotHugo commented 1 year ago

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.

kchibisov commented 1 year ago

@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.

WhyNotHugo commented 1 year ago

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.

kchibisov commented 1 year ago

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.

ids1024 commented 1 year ago

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.

kchibisov commented 1 year ago

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.

WhyNotHugo commented 1 year ago

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

ids1024 commented 1 year ago

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.

WhyNotHugo commented 1 year ago

GitLab indicates that the fix made it to the gnome-3-36-backport branch: https://gitlab.gnome.org/rmader/mutter/-/commit/1ec91cc8eef1db353d852fc4c212cae3a9cb1aee

ids1024 commented 1 year ago

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.

tfachmann commented 9 months ago

Any updates regarding this? Or better said, is there any blocking instance left?

kchibisov commented 9 months ago

After #3367.