lime
lime copied to clipboard
Implement `onDropStart`, `onDropEnd` for file dropping
currently' lime only has the onFileDrop
function for getting the name of the dropped file. ive added support for 3 more, but only implemented 2 of them:
-
onDropStart
- dispatches before any dropping of data -
onDropEnd
- dispatches after any dropping of data - ~~
onDropText
~~ - is implemeted on the native side, but only works for X11 on linux, so commented out on the haxe side.
thats so strange - CI fails when trying to install from haxelib. happened to me like 2 days ago too... what is going on?
thats so strange - CI fails when trying to install from haxelib. happened to me like 2 days ago too... what is going on?
thats so strange - CI fails when trying to install from haxelib. happened to me like 2 days ago too... what is going on?
thats so strange - CI fails when trying to install from haxelib. happened to me like 2 days ago too... what is going on?
No response from the haxelib server. Might be down.
it is working for windows tho 🤔 can you rerun CI @Dimensionscape?
Yeah, I'll try later, the haxelib server is just being slow/unresponsive at the moment.
Huh. I was expecting onDropStart
to be something like JavaScript's dragover
event, letting you know that the user is currently holding a file over the app. I guess I didn't pay enough attention to the name.
For the record, here's what actually happens. No events are dispatched while the user holds onto the file(s). Once they let go, several events are dispatched in succession: onDropStart
, followed by one or more onDropFile
s, followed by onDropEnd
.
Basically if you're collecting the files into an array, this lets you know where that array starts and ends. And you know what? That could be helpful for JS, which dispatches an array of file objects (despite the documentation saying the listener should expect a single String
).
Ok, I went ahead and implemented the JS fix, and it works pretty well. The question is, should it be part of this pull request? It's technically a breaking change, even though all it does is make JS match the documentation.
Ok, I went ahead and implemented the JS fix, and it works pretty well. The question is, should it be part of this pull request? It's technically a breaking change, even though all it does is make JS match the documentation.
actually, idk... we should probably ask the rest of the core team. should i ping them?
Nah, I already pinged Chris today. I'll just post it in Discord.
looks like CI failing on ios and getting stuck on android isn't something relate to my pr... is there a problem with the branch's lime version compiling to mobile?
Yeah, the latest hxcpp release broke those two specific tests.
Switching over to 9.0.0 so we can include HTML5 support at the same time. I guess we don't have to do it this way, but it feels wrong for a new feature to not work on a major platform.