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

Fix Electron-app root path detection #34

Merged
merged 2 commits into from
Nov 11, 2017

Conversation

jeffbargmann
Copy link
Contributor

@jeffbargmann jeffbargmann commented Jul 21, 2016

I don't know if there's a more elegant way to do this, but our app was detecting the unix executable within the app package using this module when built for distribution.

The added line resolved, so that the app package itself was always selected.

@jeffbargmann
Copy link
Contributor Author

(Bump)

@smithalan92
Copy link
Contributor

Hey @JBLatenight , sorry for taking so long to get around to looking at this. Can you give us a bit more information so we can try figure out why the wrong executable was being detected? For example your Electron Version, The original app path that was being detected and how or what you are using to built your app would be a great help.

@jeffbargmann
Copy link
Contributor Author

Hey @smithalan92 I've been on another project sorry, sure yes these paths turn up the wrong path. Am I missing something perhaps?

/Applications/APP NAME.app/Contents/MacOS/APP NAME
/Applications/APP NAME.app/Contents/Frameworks/APP NAME Helper.app/Contents/MacOS/APP NAME Helper

Each of these should resolve down to

/Applications/APP NAME.app

Otherwise the startup path will point at the MacOS binary (instead of the app), resulting in a variety of bad things.

Thoughts?

@adam-lynch
Copy link
Contributor

@JBLatenight thanks for that.

resulting in a variety of bad things

Please list some. Thanks.

@fritx
Copy link

fritx commented Oct 25, 2016

Btw, when I electron app my app.
node-auto-launch would pass in something like

{ path: '/Users/xxx/d/vuee/node_modules/electron-prebuilt/dist/Electron.app/Contents/MacOS/Electron' }

But what we expect is

// with a trailing arg
'..../Electron.app/Contents/MacOS/Electron app'

Otherwise, a default electron app would be opened.
I don't know is it possible to pass such a command instead of an absolute path though.

@adam-lynch
Copy link
Contributor

As far as I know, it's fine to start an app using its inner executable

@sidneys
Copy link

sidneys commented Feb 27, 2017

@adam-lynch @JBLatenight

This is a great request, as using the inner executable results in the macOS Login Item Preferences showing the inner executable instead of the legit application, which also has the deleterious side-effect of not displaying the icon within the list like all native apps.

This is a usability issue when users want to remove the login item using system preferences.

@johnryan
Copy link

Any update on this getting merged? ended up here from #28

@popthestack
Copy link

+1 for seeing this merged in. Right now MacOS launches the terminal on login to start my electron app.

@lucasbento
Copy link

Since this is opened for more than an year I have forked @JBLatenight project and added the build to github so for those in need of it right now it's possible to do yarn add lucasbento/node-auto-launch (located in https://github.com/lucasbento/node-auto-launch) and use the package normally.

@Alex-D
Copy link

Alex-D commented Nov 7, 2017

What's up @adam-lynch?

@adam-lynch
Copy link
Contributor

Apologies, we've neglected this project a little bit. We're going to fix that though, see #64. I'm going to put in some time this Saturday. If there's any additional information that would make this easier to test / merge, let me know 👍

@adam-lynch adam-lynch merged commit c64219f into Teamwork:master Nov 11, 2017
@adam-lynch
Copy link
Contributor

💥 thanks for that!

@JBLatenight @lucasbento I don't know if you saw #64 but we're looking for people to help out with:

  • Improving documentation.
  • Troubleshoot, triage, and reproduce issues on your machine.
  • Fix bugs.
  • General maintenance (dependencies, etc).
  • Suggest & add features.
  • Review, test, and merge pull-requests from other contributors.
  • Anything else you can think of which would help.

Would you be open to that? I can give you access.

@lucasbento
Copy link

@adam-lynch: thank you for the proposal and it does seem good but I don't think I'm on my best to help much, so sorry.

Thanks for the work on it, hopefully some good devs will come to help with it as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants