Overhauled macOS support; Save/load animation editor color palettes; Loads more.
I saw that you guys were planning on phasing out NW.js, so I decided to try and support Webview2 on my main project.
I assumed it would be pretty easy, since I secluded all of my addon events to one event sheet. But I ran into some difficulty with file operations. I normally use NW.js file operations, so I tried to switch them with the FileSystem plugin.
It was more complicated than I thought. Why is it that with NW.js, I can easily check if a directory exists, easily create/delete files, and easily read them... but with FileSystem the process is so much more tedious? I have to list the contents of a specific folder first, then check if a subfolder exists... then list contents for the subfolder, etc etc. (I can't just do "folder/subfolder"?). And all of these actions are async, so what was once one or two events spans into a whole event trigger sequence.
Is there any chance the FileSystem workflow can be a little easier in the future?
I'm afraid file system operations must be asynchronous to support both browsers and wrapper extensions.
For what it's worth, pretty much all modern storage APIs are asynchronous, so it is normal that doing something like file system access is asynchronous. Synchronous operations for that kind of thing have poor performance and can heavily jank the game, or in some cases cause it to freeze for periods of time.
I understand the async bit. I'm actually curious why NW.js wasn't async.
But regardless, I still think the workflow can be easier! Is there any chance, for example, that listing contents doesn't have to be necessary for pre-given picker tags, like "<documents>"? Why can't I get the name of a file, or it's location, after a "File operation complete" trigger? Is using tokenat() on a file tag the only way to send data with a read file request?