In the above image some processes have "icons" beside their names. What characteristic must a process meet to have an "icon" beside its name? Note the defining characteristic is not simply being in the Applications folder since several processes location in the Applications folder don't have the icon.
In addition how can I check if a PID meets the defining criteria in Objective-C? (Using Cocoa on OSX)
I think only applications that appear with their icon in the dock when you open them do have an icon in the activity monitor.
Applications that have "checked in" with Launch Services as a UI app get icons. Technically speaking, anything that ends up calling LSApplicationCheckIn will get one, but that's not a call you can make yourself.
If you run a standard NSRunLoop, or even initialize NSApplication ([NSApplication sharedApplication]) you should get it.
My question is: what are you doing that you're not getting it?
Related
In my OSX Project I want to:
identify the Desktop (one of the expose Spaces) where a NSWindow resides;
open a NSWindow in a determined Space, not only on current Space.
Is there a way to do these simple tasks?
Exploring the documentation (NSWindowController, NSWindow, NSScreen) I can't find anything regarding multiple Desktop Management.
Thanks in advance!
You'd think there would be some API for working with Spaces, but there really isn't. You can use CGWindowListCopyWindowInfo to determine which Space a particular window is on, but there's no easy way to open a particular window on a specific space.
There is private API to move windows between spaces, of course. Whether you want to use this in your application depends on your needs - you couldn't use it on a Mac App Store application, obviously.
Found a copy-of-a-copy of the reverse-engineered header I was looking for:
https://gist.github.com/rjw57/5495406
Here's a though question:
I need to find out when the user double-clicked the OS X desktop, but not icons on it.
Now, I have thought of the following solutions, though I am not sure if they are doable:
Using desktop icons position (not sure how to get them), and the size of the desktop icons, we could theoretically check once the user double-clicks on the desktop, if it is inside one of the icon areas. Contra: Might not be flawless as some icons might be transparent or not taking up the entire icon size.
Maybe there is a variable that tells us if a icon from the desktop has been clicked? Then we could just check if that variable has been activated when the user double-clicked the last time the desk.
I am certainly still open to other (better) solutions, but they need to be sandboxable for the Mac App Store.
This is probably not going to be appropriate for the Mac App Store, for a number of reasons.
First, how are you going to intercept clicks outside your window? There are a few different mechanisms for this (e.g., event taps), but none of them are allowed in sandboxed apps. And that's intentional, and for a good reason—you're not supposed to be interfering with other apps or with the OS.
On top of that, it's hard to imagine that whatever you're trying to do wouldn't count as non-standard UI/HIG stuff, which is another reason for rejection.
But, assuming none of that were a problem, and you could intercept clicks on the desktop, there's no documented way to get all the icons on the desktop, so you have to read the .DS_store file directly, which means relying on private implementation information, which is another thing you're not allowed to do.
Finally, you have to get access to that .DS_store file. Unless you're expecting the user to drag the (invisible) file or its parent directory to your app or select it in an NSOpenPanel or something, the only way to get such access from inside the sandbox is via a temporary exception entitlement. Which you can't use unless you can justify to the reviewer why you need it as a workaround for a bug or limitation in the OS. So, what's your justification going to be?
Is there a way for one Cocoa application to attach drawer-like windows to another application? We might for example want a terminal drawer that followed around a particular Finder window.
There is a program called DTerm that opens little transparent windows over Finder windows, but one might prefer persistence.
You may want to checkout SIMBL. It allows you to write nifty bundles that are loaded into the application your targeting. If you go along with it I'd reccomend using class dump to gather more information on the application your working with (although Im not sure it would work with Finder)
How do I get a process list (in a popup button), and then when the user selects the application, can I hide/kill/minimize/quit the application?
-[NSWorkspace runningApplications] will give you an NSArray of NSRunningApplication instances representing currently-running processes. I'm not exactly sure what causes a program to be excluded from that list, but it does include any application that the user has launched from the Finder. It also includes a couple of things (the Finder itself, and the loginwindow process) that you don't want to mess with, as well as faceless applications.
You can filter those out using filteredArrayWithPredicate:; the objects you want to keep have an activationPolicy of NSApplicationActivationPolicyRegular.
Once the array is filtered, you can search it, using bundleIdentifier, bundleURL, or localizedName to find the app you want. Then send hide or terminate as you like to that NSRunningApplication instance.
Apple has a sample project that demos all this, called AppList.
Is there a way to determine whether the active window (not of my process, but a different application) is resizable?
Edit: I would prefer to do this without applescript as it then depends on the application being scriptable.
Use Accessibility. Once you find the window you want to examine, test whether it has the kAXGrowAreaAttribute attribute (the value for which would be the grow area itself, a.k.a. the “size box” or [the Windows term] “resize handle”). A window that has one is resizable; a window that doesn't have one is not resizable.
The user will need to have access for assistive devices turned on, but making that happen is easier than scripting unscriptable applications.
Edit from the year 2011: Lion killed off size boxes, so now you'll need to test whether the window's size attribute can be changed.
Yes, you can check if the "frontmost window" of the target application is resizable! You can perform the scripting request via applescript, scripting bridge or a third party framework!
However, in any case, it's needed that the target application is scriptable and you can access to the "resizable" property (of the "frontmost window" object) via a scripting request!
Depends on how you're getting access to the window. There's a property in AppleScript on Window objects, resizable, that indicates this.