search

revery-ui / esy-sdl2

Esy-enabled build for SDL2
zlib License
5 stars 9 forks source link

SDL_DragEvent: Add SDL_DragEvents #13

Open zbaylin opened 4 years ago

zbaylin commented 4 years ago

These closely mirror the Drop events, specifically with BEGIN and COMPLETE. When dragging n files, 1 BEGIN, n FILE and 1 COMPLETE events are sent per mouse movement.

Note that currently only the macOS implementation works, but the scaffolding is there for easy Windows/Linux additions!

bryphe commented 4 years ago

Awesome!

Just to solidify my understanding of the API:

When dragging n files, 1 BEGIN, n FILE and 1 COMPLETE events are sent per mouse movement.

Does this mean, for every mouse-move, we would get a BEGIN - FILE - COMPLETE set of events?

I wonder if we could simplify and just use a single event (either DRAGFILE or DRAGTEXT - containing the mouse coordinates) - and worry about the complete set of files once the 'DROP' occurs? Is there a use case for sending the full list of files for each drag-movement?

bryphe commented 4 years ago

Trying to fix up the CI here: https://github.com/revery-ui/esy-sdl2/pull/14 - the 10.13 macOS image is no longer supported by Azure Pipelines. Also deleted the duplicate pipeline

zbaylin commented 4 years ago

Awesome!

Just to solidify my understanding of the API:

When dragging n files, 1 BEGIN, n FILE and 1 COMPLETE events are sent per mouse movement.

Does this mean, for every mouse-move, we would get a BEGIN - FILE - COMPLETE set of events?

I wonder if we could simplify and just use a single event (either DRAGFILE or DRAGTEXT - containing the mouse coordinates) - and worry about the complete set of files once the 'DROP' occurs? Is there a use case for sending the full list of files for each drag-movement?

This is correct. I did this for two reasons:

  1. It mirrors almost exactly the drop API -- I know this isn't a great reason in and of itself, but I think it's helpful to understand if you understand the drop API.
  2. There are reasons you would want to know what files are being dragged over -- for instance, what if you had a drop target that you wanted to only have accept .png/.jpg files. If you didn't carry the file names being dragged with you, there would be no way to visually identify that dragging, for instance a .gif is unintended behavior.

There are probably other reasons as well, but that was the main one I thought of. Let me know if you can think of a way around this -- I agree that it's pretty convoluted!

bryphe commented 4 years ago

Cool, those seem like reasonable considerations to me - thanks Zach!

You might want to merge master and I think the build should be green now. Otherwise, looks great!

zbaylin commented 4 years ago

Interestingly enough it looks like Wayland responds to all those X events I set up! So Linux is done in theory 😄

bryphe commented 4 years ago

That's awesome, @zbaylin !