Wayland: support basic Drag&Drop

[SludgePhD]

• [x] Tested on all platforms changed
• [x] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• [x] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• [ ] Created or updated an example program if it would help users understand this functionality
• [x] Updated feature matrix, if new features were added or implemented

Closes https://github.com/rust-windowing/winit/issues/1881

[SludgePhD]

I've also pushed a commit that emits all appropriate cursor events, which should address https://github.com/rust-windowing/winit/issues/1550 at least on Wayland. Other platforms don't do this yet, so let me know if I should leave it out.

(though one issue I noticed is that some compositors send DnD events when the cursor is slightly outside the window (eg. hovering over its shadow only on KDE), which results in out-of-bounds cursor coordinates being sent to the app)

[kchibisov]

Could you test that it doesn't blow up in alacritty for example or when using https://github.com/smithay/smithay-clipboard ? I think gnome doesn't allow to have drag and drop and clipboard by using multiple data device managers. IIRC it uses just the last one, and that's the reason I haven't implemented drag and drop inside winit, since winit should support clipboard, otherwise registering clipboard via external crates will disable drag and drop from inside the winit.

The work to bring clipboard is #2156 , but I don't have that much time to work on it right now unfortunately, but I hope to go back to it soon...

[SludgePhD]

I've tested with Alacritty on KDE Plasma, and both Drag&Drop and clipboard access work fine with this patch applied.

If GNOME doesn't support this properly, that does seem unfortunate, but this PR will at least make apps work on other compositors, and also make apps work everywhere that only need Drag&Drop and no clipboard access.

Do you happen to know if GNOME's behavior is correct here or does the Wayland specification require compositors to support multiple data device managers?

[kchibisov]

Would suggest to test GNOME, since it's a major compositor and we can't break it even when it's a GNOME bug.

[SludgePhD]

Alacritty built with this patch running in a nested GNOME session does not crash or break when dropping a file, but Drag&Drop doesn't do anything (so behavior matches winit master). Clipboard access still works fine.

Amusingly, Konsole in the same nested GNOME session does crash when dropping a file from a Dolphin window in the same session. Additionally, closing the nested GNOME shell window made it abort with several assertion failures, so it looks like winit is miles ahead of the typical Linux-on-the-desktop experience already... sadly

EDIT: also tested my drag&drop example app in the GNOME session and it works fine!

[kchibisov]

The thing is that it'll work, but if you create another device manager the privious one (in winit here) would stop working. I do want to have drag and drop in winit Wayland, but I'm not sure whether I'll have time to look into it, given I think that clipboard issue should be resolved first, so we can have both at the same time without collapsing.

[SludgePhD]

Yeah, I understand (unless Alacritty somehow does something differently?). As far as I can tell, this PR does not regress anything even if applications do use another data manager for accessing the clipboard. Drag&Drop simply won't work, just like it does now.

[kchibisov]

I know what alacritty does and I know why the feature wasn't in winit, since I remember the GNOME bug given that it's quite easy to repro it. Besides that it's fair to assume that we can have drag and drop that way for now.

[SludgePhD]

Addressed your comments

[SludgePhD]

sway appears to (correctly) send CRLF-delimited URI lists, while GNOME and KDE only use \n as a delimiter. I've pushed a fix for that, which makes things work correctly on sway for me.

[kchibisov]

sway appears to (correctly) send CRLF-delimited URI lists, while GNOME and KDE only use \n as a delimiter. I've pushed a fix for that, which makes things work correctly on sway for me.

My problem that I don't see done event at all. It's not like something is crlf or anything. Also sway has nothing to do with crlf, that's what applications set. Could you try sway master branch?

[SludgePhD]

Huh, right, that must be thunar's doing then. I'll check if I can repro with sway master.

[SludgePhD]

Sorry for the confusion, it reproduces even with the release of sway that I was using, the \r issue just distracted me a bit.

I've patched sctk to pass the correct serial to the compositor but it still does not work (https://github.com/Smithay/client-toolkit/commit/bef07ea62c6b1367c2588bb2f3c4a0e31951fd39). The sway debug log is also not very helpful, it only contains this when I try to drag&drop:

00:00:59.201 [wlr] [types/data_device/wlr_data_source.c:189] Offering additional MIME type after wl_data_device.set_selection
00:00:59.201 [wlr] [types/data_device/wlr_data_source.c:196] Ignoring duplicate MIME type offer text/uri-list
00:00:59.201 [wlr] [types/data_device/wlr_data_source.c:189] Offering additional MIME type after wl_data_device.set_selection

[SludgePhD]

Sway also appears to send multiple hover enter events in sequence, which end up in the application as multiple HoveredFile events without any intervening HoveredFileCancelled or DroppedFile. I think this might be a sway or wlroots bug?

[kchibisov]

But it works for me with any other application, so it's confusing.