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?
NW.js provides both sync and async file system operations. Basically it was a mistake that when making the NW.js plugin we used sync file system operations. We should have chosen async.
I'm not sure what you're trying to achieve with the other details about the File System plugin. I imagined most games would do something like write a handful of files for save data and that would be it. If you have complex use cases involving listing lots of files and passing data along with file system operations, what is it you're trying to achieve? It might be better to move to the forum to discuss this.
construct.net/en/forum/construct-3/general-discussion-7/filesystem-workflow-quite-184377
Thanks for listening :P