I'm in the situation where I love the Terminal.app of the mac, but I would love to add some further enhancements, like split views, terminal sets, etc.
Basically I tried to rebuild the Terminal.app with an NSTask/PseudoTTY approach which basically works but just doesn't feel and behave like the beloved Terminal.app itself. There's also no need to reinvent the wheel, I think.
So is there any approach to start an cocoa application (b) from another cocoa application (a) and manage the window or view of b from a? Like I have a ManageTerminals.app that start 6 Terminals and puts the views of them fullscreen in a grid, every instance being a fully working Terminal.app?
I found the SIMBL that basically allows to do something like that. At least the website says so. But there are no manuals or documentation available.
Does anybody have an idea how to accomplish this? I don't want to change an App, I just want to manage the size and appearance of the window/view on the screen.
Thanks for any ideas or concepts!
-- EDIT
I tried Apples ScriptingBridge now which almost does the job. There's just one little last step missing that might be a show stopper. Right now I have the following:
terminal = [SBApplication applicationWithBundleIdentifier:#"com.apple.Terminal"];
[terminal activate];
if([terminal isRunning]){
TerminalWindow *terminalWindow = [[[terminal windows] get] objectAtIndex:0];
view = (NSView*)[terminalWindow contentView];
}
Of course it's giving me an unrecognized selector, because there's no method to retrieve the view from the terminalWindow in the Terminal header. But if that was possible I could create x instances of my application and replug the view of the terminals to an own window that manages only the views.
Does someone know how to accomplish this, or do you think it's totally capsuled away?
You can launch an application with [[NSWorkspace sharedWorkspace] launchApplication:#"iChat"]. However you can't manage views. Youre only allowed to change the windows frame. AppleScript might help you here out. I've never used SIMBL before but theres a [wiki page][code.google.com/p/simbl/w/list]
You should probably take a look at iTerm which is an open-source terminal emulator for Mac OS X. You might be able to modify it to your needs, or at least see how a terminal emulator works via Cocoa.
Otherwise, you can use the Accessibility framework to control the position of other apps' windows. The user has to specifically allow this via the "Allow access for assistive devices" preference in the Accessibility pane of System Preferences.
Doing much more than that becomes more complex. Apple Events/AppleScript may give you the tools you need. I know Terminal has an AppleScript interface but I'm not sure how complete it is. I really don't recommend using SIMBL. This does allow you to inject your code into another app's memory space but since you would need to reverse engineer the other app you cannot guarantee stability.
Related
I use Mac OS X 10.10 and I would like to write a program that looks continuously for a window analyzing all the names of the opened windows. When the windows appear, I would like that the program will look for a button with a specific label and once found it, the app should send it a "pressed message".
I would be able to do it under windows, but I am not so familiar with Mac.
I have found a question related to mine (How do I get a list of the window titles on the Mac OSX?), but I think the most difficult part is finding the button and sending it a "pressed message".
Thank you in advance!
What you are looking for is the Accessibilty APIs. These are mostly Core Foundation style C APIs and typically prefixed with AX.
You might also want to consider additional identifiers beyond window title as window titles are not necessarily unique.
Using the AX APIs is not easy and is extremely verbose. You can use them to explore the UI and find things and interact with them but you might have more limited success observing user interaction. That might require a more fragile combination with event monitoring using NSEvent globalMonitor or CGEventTap depending on the UI widgets involved.
Also note that using the AX APIs to control anything outside your app is not sandbox capable.
I want to observe any window on OSX if it is moved. I don't own the windows so i can't get to it directly so I think I have to use the Accessibility APIs. I found a solution for the current active Application here: How can my app detect a change to another app's window? but I can't figure out how I have to modify this that it works for any window which is open. I hope anybody could give me a hint in which direction I have to look.
As I mentioned in the comments, people usually only want to detect window-move events on focused windows. (As unfocused windows seldom move.) If you want to detect application switches, you can poke into this sample project by Apple that shows how to update iChat status with the frontmost application’s name. And as you said, there’s already a solution for an active window.
I need my application to launch in a specific display (assuming there's more than one display) and go to full screen. The app itself is a Flash app, but I can write a native executable for the mac to launch it, I just don't know how to dictate which display it opens in. This is a fairly simple thing to do in Windows, I was hoping there's a mac analog.
[EDIT] poking around COCOA app development seems to suggest that the NSScreen object is the way to go here.
Take a look at the documentation for CGDisplayBounds, CGDisplayCapture and CGGetOnlineDisplayList. With these functions you can get the list of displays, find the display bounds to create your window. And even capture the display so only your app can use it.
I'm writing a Cocoa application that installs itself as an menulet in the menu bar (i.e. like the volume or battery icons). When the program crashes, it isn't possible to use the Force-Quit dialog, because it doesn't show up in the list. Of course, I can still kill it using the command-line, but my users don't know how to do that. Is there any way to fix this, say by making the program show up in the Force-Quit dialog?
(Note: the app is Leopard only).
To be honest, the proper solution is to make sure your app never hangs or crashes for users. This should be your #1 priority, rather than figuring out how to let users deal with crashes and hangs. Obviously it isn't always possible to make sure your app never breaks in these ways, but it should definitely be the exception rather than the rule.
On another note, MenuExtras is a private API which I hope you aren't using to create your "menulet". Rather, the public class NSStatusItem (part of Cocoa) is the Apple-approved, recommended way to install icons into your menu bar.
Not really an answer, but hopefully helpful still ...
I think that most people who know how to force quit also know they can kill a process in the activity monitor. Just make sure it's not named '93AZkZ' or something.
You could provide a PreferencePane for your application that can send the proper signal to it, if you want to allow users an easy way to shut it down or restart it. This is the pattern that MySQL uses on OS X.
Using the Apple OS X Cocoa framework, how can I post a sheet (slide-down modal dialog) on the window of another process?
Edit: Clarified a bit:
My application is a Finder extension to do Subversion version control (http://scplugin.tigris.org/). Part of my application is a plug-in (a Contextual Menu Item for Finder); the bulk of my application, however, is in a separate daemon proces. For several reasons, we've chosen to put virtually all the code into the daemon; the plug-in only defines the menu itself, and Apple-Events over to the Daemon.
Sometimes, the daemon needs to prompt the user for further information. It can toss a window on-screen for this, but that's disruptive (randomly positioned), and it seems to me the work flow here is legitimately modal, for example "select a file, pick 'commit' from the menu, provide commit comments, do the operation."
Interprocess cooperation (such as passing a reference of some kind) is acceptable: both processes are mine, but I want to avoid binding the sheet's code into the primary process.
Really, it sounds like you're trying to have your inter-process communication happen at the view level, which isn't really how Cocoa generally works. Things will be much easier if you separate your layers a bit more than that.
Why don't you want to put the sheet code into the other process? It's view code, and view code is inherently process-specific. The right thing to do here is probably to add somewhat generic modal-sheet support to your plugin code, and an IPC call that your daemon can make to summon that code. Trying to ship view objects over to the remote process is going to be nightmarish if you can make it work at all.
You're fighting the frameworks with this approach.
You can't add a sheet to a window in another process, because you have at most only the most restricted access to the windows in the other process.
Please don't do this. Make the interaction nonmodal if at all possible. Especially in something like a commit, it's much nicer to be able to browse around your files while you're writing commit comments.
OS X does have window groups, but I don't think they can (easily) span applications.
Another thing to consider is that in OS X it's possible to have many Finder windows open on the same folder (unlike in OS 9). Even if you did have sufficient privileges/APIs to add a sheet to a Finder window, it's not like the modality of that window would prevent the user from being able to continue working with the files.
(My personal opinion as a long-time Mac user is that this kind of interaction would drive me right up the wall.)