Ok. It is 2015. A lot of things have changed. And I would like to ask...
Does anyone know the way to detect how the application was launched on OSX ?
Because I still don't have the answer...
I am talking about these cases that are important to me:
Regular launch by user (via selecting app from Finder, Launchpad, etc.)
Launch at login (automatic launch by myHelperApp on startup)
Launch by user selecting item in services menu ("Do something in MyApp") assuming my app wasn't launched before.
Right now I am detecting the launch-at-login with outdated GetCurrentProcess function, obtaining current process id and then looking up for a parent process info. In case parent process info is obtained (!) and bundleId is not equal to some list of strings (myHelperApp bundleId, com.apple.loginwindow, com.apple.coreservices.uiagent) (!) - then this is not launch-at-login case.
Yes, it works for now, but c'mon people, this is a completely outdated, not stable way to solve the problem!
And what is important - there seems to be no way to tell that my app was launched via Services menu!
Has anyone found something new on this topic?
Related
Many applications start at startup, however, some of them do not appear on the task manager startup tab. What is that due to?
Is there any way to do this with a program, for example, spotify?
What do I need to do in order for a program to start at startup, but not showing in the startup applications tab?
Setting it in HKCU/Microsoft/Windows/CurrentVersion/Run doesn't seem to work, as it starts, but still shows on the mentioned tab.
Thank you in advance.
Its mostly a factor of how the program itself is written. If its written to run as a service, or as a System Tray application, or otherwise.
I know there are wrappers for running any exe as a service NSSM being the main one I have experience with (but this is mostly for when there is going to be NO user interaction)
I do not know if there is anything that can allow an application to run in the system tray only, not in the taskbar, if it doesn't support it.
But since Spotify does support running minimized to the tray, it does seem like there are some ways to "start spotify minimized", Spotify or other applications might have command line options or other settings to tell them to start "hidden"
When I reboot my mac, if an application that I'm developing was running during reboot, macos starts that application right after restart with "-psn_0_65552" argument. I assume that this is related to "Reopen windows when logging back in" checkbox enabled on restart prompt. I tried to find any documentation about this argument, but failed. So, my questions:
Is this behavior documented somewhere?
Any other weird command-line arguments my application should be able to handle?
Can I avoid my application reopening after mac restart?
Nobody else has offered you anything yet so maybe this will help:
Is this behavior documented somewhere?
The state preservation and restoration mechanism is at least partially documented through the methods you can call to participate in it, e.g. NSWindow's restorable & encodeRestorableStateWithCoder:, NSWindowDelegate's window:willEncodeRestorableState:, NSApplication's restoreWindowWithIdentifier:state:completionHandler: etc. However how the various AppKit classes preserve and restore all the information is not publicly documented (there is a statement to that effect in the docs somewhere).
Any other weird command-line arguments my application should be able to handle?
Anybody's guess.
Can I avoid my application reopening after mac restart?
Maybe. Some apps don't restart on relaunch, whether their authors control this or its happenstance I've no idea.
Here's a suggestion: write yourself a very basic GUI app which just saves the arguments and environment (you can use NSProcessInfo to get them all) at launch time to user defaults. Lunch your app from Xcode, Finder and Terminal. Reboot while its open. Look at the user defaults (look in its sandbox and open the .plist in Xcode). Notice anything? Want to rely on it? Your call.
Can you think of others way to track your app launches and user-initiated quits? Maybe setting and removing a flag in user defaults? Have fun!
HTH
I am developing a macOS app which takes control of the cursor. I am using a CGEvent Tap and I am adding some arithmetic to the CGEvents in order to offset the final mouse position. Although the app is in principle working as expected, in some cases - more specifically: when running the app with certain popular illustration software and using a stylus pen - the app is producing some flickering 'ghost' positions for the mouse at its original location. The good thing is, this problem can be resolved when running the app while being logged in as root user. I have read quite some SO posts but this particular post addresses the issue best:
https://stackoverflow.com/a/9899901/5066660
As described in this post the issue is probably:
Unfortunately, the CGEventTapCreate() doc says:
Only processes running as the root user may locate an event tap at the point where HID events enter the window server; for other users, this function returns NULL.
Well the function is definitely not returning null because the tap is in effect. Also I tried all possible combinations of arguments for that function, but they all act the same. Further down in that post it is proposed to tackle the problem as follows:
Perhaps you can spin this functionality off into a separate process that has super-user permissions, leaving the rest of your app in normal user mode? I believe there's also a way to request root permissions for just a specific action taken by your program.
Now if this is a possible solution I would love to implement it! So my question is: how? I've stumbled upon running scripts with elevated permissions, but not just CoreGraphics code as for example an CGEventTap. Is this possible? Could anybody give me an example of how this could be accomplished, or any other solution to the problem?
All help is welcome, thank you very very much.
From Apple documentation:
Event taps receive key up and key down events if one of the following conditions is true:
- The current process is running as the root user.
- Access for assistive devices is enabled. In OS X v10.4, you can enable this feature using System Preferences, Universal Access panel, Keyboard view.
So giving the the application Accessibility rights solved it for me (no need to run as admin). This can be achieved System Preferences -> Security & Privacy -> Accessibility and add you program there.
I need to build an application on Mac OS X that runs on the background, windowless and provides a status icon in the top-right corner of the menu bar. It should launch on a specific action initiated by the user (not at system start up) and interact solely through the status bar icon.
On Windows this is very close to Services, on Unix - to daemons. What should i search for in Mac documentation? I just need a few keywords.
Nothing so strictly defined. Mac OS X considers the parts of your question to be separate concepts:
The icon on the right side of the menu bar (i.e., in the status bar) is a status item. Any application can create any number of them, using the NSStatusItem class.
An application with no Dock tile is usually an agent. An application with no UI at all is a daemon. A status item counts as UI, so an application with only a status item is an agent. The typical way to make an agent (with or without a status item) is to set LSUIElement to the string "1" in its Info.plist.
Having never programmed DOS or Windows, I have no idea what “resident” means to you. On Mac OS X, it simply means “in RAM”, which any running application at least partially is.
Services on Windows are not at all connected to this concept. A status item-only utility is the simile for something running solely from the system tray (like one of those delightfully useless nuggets that you get for seemingly every trackpad, audio card or GPU that you have the bad luck to be outfitted with). Services are just background programs a) without UI and b) that support or provide system or application functions. Dozens flare in and out of existence as you use Windows, mostly at startup, and most of them provide completely abstract functionality, such as providing network APIs for other services to use.
That said, Peter's answer is likely what you meant to find out, but I think it should be spelled out that it's not necessarily connected to the equivalent of Windows Services. (If you're looking to build such a thing on OS X, look up daemons and launchd.)
"launchd"
See http://en.wikipedia.org/wiki/Launchd
I'd like to get the list of running applications in the same order they appear when doing ⌘ + ⇥
I.e. if I use TextEdit, then Preview, then iCal, the order is
iCal
Preview
TextEdit
Using [[NSWorkspace sharedWorkspace] launchedApplications] does not work as applications are sorted by launch date/process id. Enumerating with GetNextProcess does not work either as it is also ordered by pid.
Registering for notifications and maintaining a list myself is not an option as I must know the list right after the application launches. Well, the first element of the list would be enough actually, but I think it is pretty much the same question.
Is there some API available to get this information?
Maybe something like this:
cd /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework
nm LaunchServices | grep __LSCopyApplicationArrayInFrontToBackOrder
It is impossible to get the list before your application launches. After you start the application though, you can just register for notifications and maintain your own array of applications.
The only solution is to start a background process at login using launchd that simply listens for applications.
You need to register for notifications when the active application changes, as outlined here: http://www.unsanity.org/archives/000045.php
Once that is done it is easy to maintain an array of active applications sorted by last active time.
Try enumerating the list of windows with the Accessibility or CGWindowList APIs. Apps aren't windows on Mac OS X, as I'm sure you know, but the front-to-back order of applications should be determined by the front-to-back order of their frontmost windows.
You will, of course, need to ignore processes you've already seen windows from (that is, only consider their frontmost windows).