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).
Related
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?
On Mac OS, I've seen a few application that manage to control the user interface elements of other applications in order to provide a new way to control them (via a track pad, for example).
Can anyone please tell me how that's done?
Some obvious (and non-hackish) ways to achieve that would include
Accessibility, or
Apple Script
Is there a way to get list of open or visible NSWindow from mac desktop?
Note that not all windows are necessarily NSWindows, and that NSWindow only provides an interface to windows in your own address space.
The supported way to access every window is the CGWindow API. Take a look at the Son of Grab sample code to see how it's done.
You can use the accessibility API (accessibility must be enabled under System Preferences for it to work) to get information on windows (and other UI elements) from other processes. This question might be just what you're looking for.
ALL running applications? No. You can only get the NSWindows of your own app. You may be able to use Universal Access or Core Graphics APIs to get some information about windows of other apps, but not full access.
Situation:
A GUI app contains functionality (off a menu option) that produces a frequently updated image to a directory.
A logged-in, running instance of the app is the ONLY source for this image (functionality 'reliant' on display device). I have researched this to death - it is a sad fact.
The GUI application offers COM interfaces, but none that generate the image.
GUI code cannot be change in the least (big surprise).
Requirement:
These current images are needed by other processes at various times.
Obvious solution:
A process that creates an instance of the GUI app and uses SendKeys to manipulate the controls to produce the image.
Roadblocks (do I need to elaborate)
Aside from the flakiness of Sendkeys - assuming that Sendkeys WAS reliable....
Sendkeys can't work when console session is locked (locked is production requirement)
SendMessage API can't send key combinations like 'shift/letter' (required to invoke menu option).
Questions
Is there any other way to programatically interact with the app when the session is locked?
Can a windows service unlock/lock the sesion at predetermined times - long enough to allow an image generation to occur.
I know, I know, its crap. ANY high level ideas and MOST opinions are appreciated ;)
Virtual PC.
Lock the host, not the virtual machine.
But to actually answer your question: i don't think you can send keys to a locked computer. Why? What if there are multiple logged in sessions; which one would it send the keys to?
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