search

astroidmail / homebrew-astroid

Homebrew tap for Astroid
10 stars 5 forks source link

Astroid.app or other way to launch from spotlight? #20

Closed hgvhgv closed 6 years ago

hgvhgv commented 6 years ago

Thanks so much for the homebrew formula, which I just got up and working!

One question though: While I don't mind keeping a particular iTerm session just to run Astroid, it would be nice to have a .app or something like it to launch from Spotlight/Alfred. To launch Astroid without a running terminal, I tried creating an Alfred workflow as well as wrapping a launch script into a simple "app" package (see https://mathiasbynens.be/notes/shell-script-mac-apps). But while I got Astroid to launch with these, these instances of Astroid couldn't do some basic things, such as run hooks or the poll script (I think because those themselves are child processes). Moreover, whenever I quite Astroid it gives me the "quit unexpectedly" notice.

Any suggestions? Anything that can use the desktop entry on macos? Obviously not a priority, but would be nice.

gauteh commented 6 years ago

There was a similar issue on main astroid tracker, closed bug, recently, on Debian I think. Maybe there is a solution there.

søn. 21. jan. 2018 kl. 18:56 skrev hgvhgv notifications@github.com:

Thanks so much for the homebrew formula, which I just got up and working!

One question though: While I don't mind keeping a particular iTerm session just to run Astroid, it would be nice to have a .app or something like it to launch from Spotlight/Alfred. To launch Astroid without a running terminal, I tried creating an Alfred workflow as well as wrapping a launch script into a simple "app" package (see https://mathiasbynens.be/notes/shell-script-mac-apps). But while I got Astroid to launch with these, these instances of Astroid couldn't do some basic things, such as run hooks or the poll script (I think because those themselves are child processes). Moreover, whenever I quite Astroid it gives me the "quit unexpectedly" notice.

Any suggestions? Anything that can use the desktop entry on macos? Obviously not a priority, but would be nice.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/astroidmail/homebrew-astroid/issues/20, or mute the thread https://github.com/notifications/unsubscribe-auth/AADd-1QHlLVD1zr1P8ObY2rqoRXMMlKKks5tM3pCgaJpZM4Rl5xK .

hgvhgv commented 6 years ago

Thanks! The issue is https://github.com/astroidmail/astroid/issues/450 and definitely points in the right direction, though I have yet to solve the issue on macos. I'll close for now and comment if I solve it. Other ideas of course welcome!

c-alpha commented 6 years ago

As @gauteh pointed out in astroidmail/astroid#450, the environments are typically quite different between an interactive shell session and something invoked from a window manager or desktop. Typically, environments are much more restricted in the latter case; hence things like e.g. msmtp may not be found, or astrtoid may be trying to write logfiles into the root directory (/), which of course fails.

The one true way to make astroid int an app bundle for macOS would be to include all libraries and executables from other projects in (notmuch, xapian, msmstp, etc.) in the app bundle itself, and instead of getenv() use FileManager to retrieve the Application Support path for the app, and keep all mail directories, logfiles, etc. in there.

Plus, on macOS an app bundle (which is essentially what you are asking for) needs special permissions to start things outside its own bundle. These permissions are recorded in the code signature which an app distributor generates when he builds the app. This scheme allows for two basic use-cases:

  1. You have downloaded Xcode, and are building the app for yourself. In this scenario, you would use the Xcode command line tools to generate the code signature. Such an executable will only run on systems that have been switched to "developer mode", and when the user account you are using is linked to the same Apple ID you used when signing the app bundle. In practical terms, you compile it for yourself, you must have Xcode installed, and only you will be able to use the executable.

  2. You are a registered Apple developer, and sign the app bundle with your Developer ID. In this case, anyone who have set their Gatekeeper preference to "app store and identified developers" will be able to use the executable.

For distribution of astroid in binary for, the first scenario clearly won't work (too many if-s). The second scenario would require someone who is a registered developer, to act as a distributor of astroid, which implies that he/she takes responsibility for the case that the app should have any adverse effects on the Apple ecosystem. Probably easier said than done.

Some may respond that an app bundle can be very easily done, if you turn off system integrity protection in macOS. This would mean that the OS will not perform any code signature checks whatsoever. This would mean that we'd have to tell people that they can of course install astroid on macOS, but in exchange they'd have to allow all malware and viruses to take full effect by default. Not a message I would like to be giving...

hgvhgv commented 6 years ago

Thanks v. much for the informative answer! Definitely not asking for any extra work along these lines, just learning as I go. Though I do think overall that Astroid, as the only (?) notmuch GUI frontend, should dream big---but such an app is a long term thing.

gauteh commented 6 years ago

I think that we can make it a goal to make some kind of .app, perhaps that will take care of the dependency mess that homebrew is - it would require us to bundle:

bunch of other libs?

c-alpha commented 6 years ago
  • notmuch
  • webkit
  • astroid
  • msmtp
  • offlineimap
  • gmailieer ?

mbsync! fetchmail?

What about post-poll tagging? afew? procmail? Self-made perl/python/ruby/... scripts?

There seem to be too many choices for a couple of tasks. To make an app package, we would need to pick one option for each task. IMO not very likely that our selection will meet the needs of the vast majority. And even if it did, what about those, whose needs our selection doesn't meet?

gauteh commented 6 years ago

Hm, ok. I guess I don't really know how packages work - you can't call programs outside the app?

c-alpha commented 6 years ago
  • you can't call programs outside the app?

Correct. On macOS, everything runs it it's own sandbox by default. There are of course ways to invoke stuff in /usr/bin, /usr/local/bin, and the likes, but these ways depend on code signing (see my comment above).