Distribution with Electron
sklink opened this issue · comments
When I package up the application, if the user doesn't have Java installed gkm
won't run.
I've run into the same issue with gm
and have packaged a binary with Electron to distribute. I can then use their appPath
option to refer to the local gm instead of looking for a globally installed gm.
Here's the easiest place to check that out:
https://github.com/aheckmann/gm/blob/c1bef9d4fd21e34ef8138f44a85c342aeae1f174/lib/compare.js#L24
I was going to do the changes myself and create a pull request but I think it'll end up needing to change the way people need to implement gkm
in their project. What are your thoughts on this change?
First off, I think it would be best if electron offered such feature out of the box. Relying/Depending on java in a node application/context is pretty bad and gkm was more of a proof of concept than expected to be used in any production application to be honest.
Now, it is true that it would be relatively simple to modify
var gkm = spawn('java', ['-jar', path.join(__dirname, 'lib/gkm.jar')]);
such that it could receive any path to the java binary.
As a side note, gkm
could be modified to have start/stop
functions which would start/stop the spawned process (or simply drop events). It would make it possible to configure the path to java
before it is spawned (as the process is now spawned as soon as you require gkm
).
So, something like gkm.setJavaPath(path)
could be conceivable or otherwise a config object and a gkm.setConfig({javaPath: path})
method.
Seems like anything that occurs while Electron is focused is already covered. I'm not sure Electron could handle anything outside of the window. I'll make an issue for it over there but my guess is it'll be out of scope.
I could remove gkm
to avoid relying on Java but it's doing a lot to make the in-game overlay I'm building feel more reactive.
Something like this?
https://gist.github.com/sklink/e75a5ac546fefbe0796ac2009f0b0695
I don't know much about using and managing child processes. .kill('SIGINT')
was the first thing to pop up when I searched.
I agree with you that it is likely this is out of Electron's scope. NW.js however did implement something (see nwjs/nw.js#1735).
As for your gist, yes, something like that would work (don't forget to export setJavaPath). Furthermore, I think you'd want to call .kill()
(defaults to SIGTERM
) instead of .kill('SIGINT')
.
@tomzx How do you pack Java with the Electron package so you can use the Local Java path instead of using the Globally installed one?