Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distribution with Electron #4

Open
sklink opened this issue Jul 24, 2016 · 4 comments
Open

Distribution with Electron #4

sklink opened this issue Jul 24, 2016 · 4 comments
Labels

Comments

@sklink
Copy link

sklink commented Jul 24, 2016

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
Copy link
Owner

tomzx commented Jul 24, 2016

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
Copy link
Author

sklink commented Jul 24, 2016

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
Copy link
Owner

tomzx commented Jul 24, 2016

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').

@mmikhan
Copy link

mmikhan commented Sep 19, 2017

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

@tomzx tomzx added the question label Nov 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants