Runtime environment for libui-node #113
Description
I think that one of the biggest problems with libui-node is that it lacks a proper runtime environment. Right now the only way to run a libui-node application is to create a wrapper script which basically runs "node path/to/script.js". This is problematic especially on Windows, because you get a console window.
I've been experimenting with the following solution:
- compile Node.js as a shared library, node.dll
- compile libui as libui.dll
- create a wrapper executable, let's call it shell.exe, which links to both node.dll and libui.dll
The differences between shell.exe and regular node.exe are as follows:
- it's a Windows application, so there's no console
- it can be run without any arguments, and it will automatically pass the path to the application script (for example, <exe_path>/app/main.js) to node::Start(), so no wrapper script is necessary
- it can report fatal errors using uiMsgBox() instead of printing them to the console (similar to how Electron handles fatal errors)
In that configuration, the nbind.node library from libui-node will not work "out of the box", because it tries to link to node.exe, not node.dll. But it can be rebuilt by running auto-gyp with the --nodedir option. This is pretty much how native dependencies are recompiled by electron-builder to work with Electron which also uses a node.dll.
I think that this is the bare minimum to have a runtime environment for libui-node, especially on Windows, but this probably applies to other platforms as well. I was able to create and successfully run a proof of concept, but I would like to discuss and hear your opinion before I continue working on this.
The next step would be to integrate libui-node into shell.exe as a built-in module. Then, at least in theory, it would be possible to integrate the libui main loop with Node.js main loop, and possibly eliminate the async hooks and other hacks.