Is there anything similar to GetForegroundWindow on Mac OS X?
I've two apps one windowed (NSDocument based) and one command line I want to show an NSOpenPanel from command line tool and would like to make it model for the NSDocument based app but don't have the windowref for it?
There are a few problems with what you want.
First of all, applications on the Mac do not have window references. An application may have any number of windows. Second, access to other processes' windows is limited in Mac OS X. There are a few APIs for accessing them in different ways. At any rate, having a reference to another app's window will not allow you to throw up modal dialogs for that application.
What you want is to have the command line app communicate with the foreground app to tell it to show the open panel. You could either establish your own communications protocol (e.g. through Distributed Objects) or you could use Apple Events/AppleScript to communicate back and forth.
Related
I have a cross platform need to open a gui application programmatically, but keep it hidden from the user. Effectively, I want a command line driven interface to act as a wrapper over this gui app, and insulate the end user from seeing or interacting with it. The program is from a third party, I did not write it, and I can't edit it.
I can do this one way or another on Windows, on Linux, and (in theory) on older versions of Mac, but not the most recent ones. On Windows, I can use the native api ShellEx with a hide window parameter. It's very easy and straight forward. In Linux, I can can render a gui app to a virtual frame buffer (using xvfb).
On macOS, the open command has a --hide and --background option, but they don't have any effect (at least on this app...)
I tried changing the plist file and found that LSUIElement will hide the app from the docker, but it still shows up on the screen. LSUIPresentationMode=4 or 3 OUGHT to work for exactly this, but apparently that doesn't do anything anymore as of a few os versions ago...
I tried the approach of moving the .app off of the screen with AppleScript. That works, but you have to manually grant permissions for such a thing to occur via System Preferences. In prior versions of Mac, those permissions could be twiddled on the fly via sqlLite (so long as you had sudo rights), but now they blocked that too. You can only pull that off apparently through a process of disabling "SIP" and forcing a reboot. That is totally outside the realm of what I want.
I've tried using the xvfb approach on Mac (jumping through hoops to acquire the binary they use to include stock, and now dropped), but I'm not having luck with that. I don't think it's possible to direct a mac .app to another display is it? A .app does not render on X11 by it's nature right?
What other clever ways might there be to hide a third party app on a mac? (and that still works in most recent os versions!)
I want to develop a application like http://orbicule.com/undercover/ or
http://hiddenapp.com/.
I know how I could do that for windows but I have totally no clue, what kind
of approach I would need for mac os x, cocoa/xcode.
Is there anything I should be aware of when building applicatons / background services
with no GUI for mac os x?
The service will post data to the webpage with the usual data like geo location & IP
information about the machine so it should be able to access the internet too.
Please lead me to the right path.
It's fairly straightforward.
Go to:
Information Property List Key Reference
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Introduction/Introduction.html
in the Launch Services Keys, you will see one called "LSBackgroundOnly" simply define this in your Info.plist and set it to true.
<key>LSBackgroundOnly</key>
<true/>
From the documentation:
LSBackgroundOnly (Boolean - Mac OS X)
specifies whether this application
runs only in the background. If this
key exists and is set to “1”, Launch
Services runs the application in the
background only. You can use this key
to create faceless background
applications. You should also use this
key if your application uses
higher-level frameworks that connect
to the window server, but are not
intended to be visible to users.
Background applications must be
compiled as Mach-O executables. This
option is not available for CFM
applications.
Your application will be a background application.
Give System Startup Programming Topics a read. Create a command line tool project, not a Cocoa Application nor a Cocoa Document-Based application. To provide a GUI to interface with it you'll want to use a separate application (ideally one you don't have to install with the "hidden" app, since you seem not to want it to be easily discoverable).
With the exception of AppKit (UI) stuff, the rest of the basic Cocoa frameworks is still available to you via the command line. This means you'd write the main logic of your app (the non-GUI parts) the same as you would otherwise.
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.
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
If I wanted to write my own window manager for OS X (please dont respond with "whats the point"??), what APIs should I be looking at?
There is no such thing as a "window manager" in OS X, and no public interface to implement one. The functions that an X11 window manager would perform are split between the GUI toolkit (Carbon/Cocoa), the Dock application and the window server.
Your only real choice if you want to change OS X's windowing behavior is to patch individual applications, the Dock (which has a privileged connection to the window server) and/or the window server. It'd involve a great deal of reverse engineering and almost certainly break in 10.6, but it's certainly possible.
At the hardware level, write your own APIs.
Otherwise, there are various graphics architectures in which to plug in your window manager:
OpenGL
Quartz
Quicktime
X11