Open BillyDM opened 3 months ago
Yeah, I think it would be a good idea to follow how the spec suggests handling it.
I'm okay with you working on it if you're inclined to do so.
I just finished rewriting the logic to use a specific enum to keep track of the XDND session state. :slightly_smiling_face:
Incidentally I ended up completely rewriting the drag_and_drop
file, and there isn't a single line of code remaining from winit
, so I removed the attribution and license header from that file. (It's still there on the get_property
file though, I haven't touched it.)
This commit should fix all of the issues I raised in my previous review. :slightly_smiling_face:
On top of making a merge commit to bring this up to date with
main
, I made a few fixes:XdndStatus
message, to make sure the source application receives it and keeps sending us position events.XConvertSelection
request, to make sure the source application receives it and sends us theSelectionNotify
reply.XConvertSelection
request logic to only send a request if we haven't requested the data yet, instead of sending a request if we haven't received (or successfully parsed) the data yet. This fixes an issue where multiple requests would be needlessly sent if we received a new position event before the transfer was complete.XdndPosition
event from which we made anXConvertSelection
request, and match it in theSelectionNotify
reply handler, to make sure we aren't reading stale replies.XdndEnter
event. This fixes some state/caching issues, but it is still a brittle fix that may cause issues if concurrent (or stale) drag sessions' events reach the application.For good measure, I've also updated the
femtovg
example, so that the little orange square that follows the mouse also updates drop DragEnter/Position/Drop events. :slightly_smiling_face: