SDL_DragEvent: Add SDL_DragEvents

[zbaylin]

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]

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]

Trying to fix up the CI here: #14 - the 10.13 macOS image is no longer supported by Azure Pipelines. Also deleted the duplicate pipeline

[zbaylin]

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]

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]

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

[bryphe]

That's awesome, @zbaylin !

[glennsl]

This assignment seems unnecessary, and a bit confusing. I'd expect posted to be read from again later, but it isn't. So it would be simpler to just check the result directly I think:

Suggested change

	posted = (SDL_PushEvent(&event) > 0);
	if (!posted) {
	return 0;
	}
	if (SDL_PushEvent(&event) == 0) {
	return 0;
	}

[glennsl]

posted is an ambiguous name. It's not immediately obvious whether it refers to a boolean or a count of items posted, for example. Therefore I prefer using isPosted for booleans.

[zbaylin]

Sounds good. All the variable names I used I either borrowed from other functions (see SDL_dropevents.c) or modeled them closely after others. In this case it doesn't matter because I can remove the posted reference altogether though!

[glennsl]

Same here:

Suggested change

	SDL_bool dragging;
	SDL_bool dropping;
	SDL_bool isDragging;
	SDL_bool isDropping;