-
Notifications
You must be signed in to change notification settings - Fork 10
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Seems to even make the implementation here simpler!
I think you might have gone a bit too hard on the lockfiles though.
Yeah not sure what happened there. That was just the result of me running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, Zach! Thanks for going the extra mile and updating this API. Sorry I missed this reviewing it the first time around!
Will publish this once it is in 👍 |
Sounds good! I'll wait for this to pass CI and then I'll merge it in! |
|
Does that exist here? Using |
Hmm, I guess it doesn't. There's only one other sandbox here though, so just running |
No go 😕. The |
Deleting the lock directories and running |
I guess so. Weird. If any dependency had been updated to drop a bunch of dependencies I'd expect |
Published |
As discussed in revery-ui/revery#833, it makes sense to differentiate between events that carry a file/text/path and those that don't.
This splits
dropEvent
intodropEvent
anddropNotificationEvent
.dropNotificationEvent
is for when SDL is simply notifying that a drop is about to/has taken place through eitherDROPBEGIN
orDROPCOMPLETE
.dropEvent
is for when there is information about the actual items being dropped.This is a very simple change, but I definitely agree with both @glennsl and @bryphe that it improves clarity for these events!