Distribution with Electron

[sklink]

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?

[tomzx]

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.

[sklink]

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.

[tomzx]

I agree with you that it is likely this is out of Electron's scope. NW.js however did implement something (see https://github.com/nwjs/nw.js/pull/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').

[mmikhan]

@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?