Mac app issues
@pico, about that, figured out how to reproduce the problem. If I download the agent from the Internet, then run it, the first time it runs, it hangs and I have to force-quit it.
I actually implemented the LSUIElement change you suggested (which worked great btw), but I had to undo it because you can't force-quit an application if it doesn't have a dock icon. I had to kill the pid from a terminal shell.
I'm still working on fixing that first launch after downloading from the internet issue.
EDIT: I fixed the first launch issue. Thanks for all your suggestions @pico!
Dewi Morgan last edited by
Just a flyby 2c: I think Mac users are in general familiar enough with command shell, ps and kill (you kind of have to be if you have a mac), so as a tradeoff, fixing the two big bugs is worth the inconvenience, particularly since force-killing TC isn't something I've ever needed to do.
@dewi-morgan, these problems are fixed now in the latest version. Let me know if find out they're not fixed.
Pico last edited by Pico
This is great! Sorry I didn't get back sooner, I didn't have email notifications turned on and I hadn't checked back on this post until today. But, I just turned on email notifications for new posts so I'll see this stuff sooner from now on
I just installed the latest version and it launched just fine on first run after download.
I wanted to be sure everything worked properly for new users so I deleted the app and all the trigger command config files to see a true first run with the token prompt and all... It worked perfectly!
I did find a new interesting bug though...
When I quit the app with the "GUI Command Editor" window open, the window is closed but the app doesn't quit. All attempts to quit the app after that don't work as well.
I had to Force Quit the app. As an aside, you can Force Quit headless apps through the GUI with the Activity Monitor app. In Activity Monitor you can select the app and then click the "Stop Sign with an X" icon in the toolbar and there is a button to Force Quit. Also, from the command line, you can use "killall TRIGGERcmdAgent" so that you don't have to fuss with finding the PID. But I find sometime I have to run "killall" multiple times to make it work.
With more testing, this seems to also happen if I open the "GUI Command Editor" and then close it manually and then try to quit... the app still doesn't quit.
I found that this doesn't appear to be an issue if the "Text Command Editor" window has been opened or if no windows have been opened. In those cases the app quits properly.
Just noticed that when I trashed the app and re-installed it, the app added itself to the Login Items multiple times.
@pico, is it possible you have two Login items because you added one, and the app added another one? I tried and I wasn't able to re-produce the problem.
@russ I was just able to reproduce it again doing the following steps...
Remove TRIGGERcmdAgent from Login Items
Launch TRIGGERcmdAgent (which adds itself to the login items).
Trash TRIGGERcmdAgent (but the references stays in Login Items).
Reinstall TRIGGERcmdAgent from .dmg and launch it.
In the end, I have two references to TRIGGERcmdAgent in my Login Items.
Shouldn't it not matter how TRIGGERcmdAgent was originally added to the Login Items though? The app should just check whether or not it is already in there no matter what.
Is there different code for adding itself to Login Items on first run vs other launches? Cuz the app doesn't keep adding itself to Login Items on every launch.
@pico, I was able to reproduce it this time. I'll fix it soon. Thank you for telling me.
I published a new version. I made it so it only adds a Login item the second time you run it. That should avoid the duplicate.
The downside is now you don't get a Login item the first time you run it.
For some reason the first time you run it after downloading, it can't determine whether there's already a Login item, so added one anyway. All I could think of was to disable adding one if it's the first time running after downloading.
@russ I know it's been months, but I was recently working on an unrelated app and have realized a likely reason why TriggerCMD login item would get added on first run even if the app was already in the login items.
The first time a Mac app runs when its been downloaded from the internet, it is quarantined by the system.
An app can check if it's running in quarantine because its execution path will include a folder called "AppTranslocation".
A simple fix could be to detect if the app path is in this qaurantine folder and, if so, check if the app exists in /Applications. If it does, then use the /Applications path instead of the path the app returned for itself for the login item.
If for some reason a user didn't install it in /Applications then there's no loss in falling back to waiting until the second run.
@pico, that's interesting. I'll experiment with that. I hope it works. Thanks for the suggestion.
EDIT: I worked on it for a while and didn't get it working. I couldn't get it to add the Login item while it's quarantined. I think that's a mac security feature for apps downloaded outside of the app store.