Close App A when App B closes: Mac OS X 10.7.3 - macos

Say I have two applications running; App A and App B. What would be the easiest way (or indeed is there anyway) to get App B to close automatically when App A is closed? Note that neither of the apps in question have been developed by me and so I have no control over their internal behaviour.
I am open to any suggestions including those that entail the use of Applescript, Automator, Terminal commands and BASH scripting. I would even consider developing a lightweight Mac OS X application to achieve this.

If you don't need B to exit immediately - if it's OK to wait a few seconds - then you could schedule a periodic background task (using cron or even just iCal) that does something like this:
if not exists (processes where name is A)
tell application B to quit
end if
Another option, if you want an immediate response, would be to wrap App A in a script that launches it, waits for it to terminate, and then terminates B (osascript -e "tell application B to quit"). Then you could just always use that script to launch A.
You could even insert the script into the application bundle so that double-clicking runs your script. You would do this by doing "show package contents" on the application, replacing the <CFBundleExecutable> in <app>\Contents\info.plist with your script name, and dropping that script into <app>\Contents\MacOS. Then have the script just run the executable that is already there.

Fantastic question. I spent about 10 minutes looking for an old project where I had registered for notifications for when applications quit but couldn't easily find my code. But I did find a potential alternative for you.
If you download Apple's AppList sample code project, you'll see that it is observing the list of NSRunningApplications and when an app quits, it removes that app from the list of running apps in the window. You can take the technique they're using there and when you detect your "application A" quits, you can send a "quit" Apple Event to "application B".

Since you are running Lion, you can use a Cocoa-AppleScript to access Cocoa methods to add your application as an observer, getting notifications when applications quit.
For example, create a new application from the AppleScript Editor > File > New from Template > Cocoa-AppleScript applet. In the run handler, add the application as an observer to get notifications when an application quits:
set theNotice to current application's NSWorkspaceDidTerminateApplicationNotification
tell current application's NSWorkspace's sharedWorkspace's notificationCenter
addObserver_selector_name_object_(me, "appQuitNotification:", theNotice, missing value)
end tell
Next, add an appQuitNotification handler (this is the handler selector specified in addObserver_selector_name_object_ above), something like:
on appQuitNotification_(aNotification) -- an application quit
-- aNotification's userInfo record contains an NSRunningApplication instance that we can get properties from
set theApplication to (aNotification's userInfo's NSWorkspaceApplicationKey's localizedName()) as text
say "application " & theApplication & " quit" -- for testing
if theApplication is "this" then tell application "that" to quit -- or whatever
end appQuitNotification_
...and you are done. As long as your application is running, it will get notifications from the system when an application quits. Note that these Cocoa-AppleScript applications can't be run directly from the script editor, so they can be a bit of a pain to debug since there is no event log to look at - you will need to add your own dialogs or whatever.

Related

Running Applescript: WorkFlowServiceRunner will not terminate

I am trying to make a keyboard shortcut to launch terminal in OS X Mountain Lion.
After some research I found out that I can use Automator to achieve this:
http://mac.tutsplus.com/tutorials/tips-shortcuts/how-to-launch-any-app-with-a-keyboard-shortcut/
It works, but I noticed that whenever I launch a terminal using this method, a process called WorkFlowServiceRunner starts and never terminates. To make matters worse when I launch more terminals (or launch different applications using shortcuts, again, through Automator) multiple WorkFlowServiceRunner processes start and quickly eat up the memory.
I've also tried writing my own applescripts but the problem does not go away. This clearly looks like a memory leak. Is this a bug in OS X Automator? Is there a way to write an applescript so that the WorkFlowServiceRunner terminates after doing its job (e.g. launch a terminal)? Automator seems to be the most "native" way of getting this done and I do not want to use any 3rd party apps.
I have noticed this from time to time.
One way around it would be to make your own service apps with a Cocoa-AppleScript Applet.
It is not very hard to do. And I will try and guide you through it. It should only take you a couple of minutes.
Step 1.
Open your Application Applescript Editor. And go to the "File" Menu -> "New from Template" -> Cocoa-AppleScript Applet.app
Step 2,
Paste this code into the new documents.
property NSWorkspace : class "NSWorkspace"
tell current application's NSApp to setServicesProvider_(me)
NSUpdateDynamicServices()
my runAService()
on runAService()
NSWorkspace's sharedWorkspace()'s launchAppWithBundleIdentifier_options_additionalEventParamDescriptor_launchIdentifier_("com.apple.Terminal", current application's NSWorkspaceLaunchDefault, missing value, missing value)
tell me to quit
end runAService
Step 3,
Compile
(click this to compile)
and Save the app.
*Make sure the show startup screen is unchecked in the Save dialogue.
Giving the app a name like LaunchTerminal.app
Step 4,
Click the "Bundle Contents" button on the top right hand side of the document.
This will open the applications contents view.
Click the Action button and then "Reveal in finder" sub menu.
step 5,
In the contents folder that opens in the finder you will see a file name "info.plist"
Open Terminal.app and type and run this code using the path to this file:
BUT make sure you do not include the ".plist" part of the name when entering it in Terminal.app
/usr/bin/defaults write /Users/YourUserNameHere/myServiceApps/LaunchTerminal.app/Contents/Info NSServices -array-add '{NSMenuItem={default="Launch Terminal";}; NSMessage="runAService"; NSSendTypes=();}'
( You can drag n drop the file into terminal to get the posix path string )
The path part looks like this: /Users/YourUserNameHere/myServiceApps/LaunchTerminal.app/Contents/Info
This code should add an array to the plist file which is part of the apps way of broadcasting it has a service.
step 6,
Compile and Save the App again.
Just to make sure it picks up the changes. ( I found I had to do this even though I should not have to)
step 7,
Double click the app to run it for the first time.
The App will quit straight away. But the first run should have broadcast that it has a service that should be registered with the system
step 8,
Open system Preferences and go to Services -> General (section)
And you will see the "Launch Terminal" service.
Set up your short cut as normal.
Hope this helps..
UPDATE :
I noticed that the tell application "Terminal" to activate. Would not open my default Window groups if I had closed them all and quit Terminal before. The normal behaviour if I have done this is for my default window group to open. ( I have two Tabs open at startup each cd'd to a different path).
So I have change the open application to a cocoa way of doing it.
A do shell script with open the/application/path/. will work also.
Try using Butler or QuicKeys. They both have endless "Trial periods."

Is it possible to write an applescript so that when I close one program it also closes another?

The example I can think of that is most relevant to me is to be able to close the last.fm app when I close iTunes. I quite often forget to close last.fm and I find it rather annoying. I'm sure there are other uses...
Yes you can.
Over on my Blog thecocoaquest I have two posts that cover this.
The first Post shows you a methods of doing this with a applescript and using a Launch Agent.
Applescript – Quit or Launch Application if another is or is not running
Here is one of the examples:
If I have one App running the second app will launch and will always be running while the first app is running.
Or when I quit the first App the second app will also quit
#!/usr/bin/osascript
#Copyright Mark Hunte 2012
#http://www.markosx.com/thecocoaquest/kill-one-application-if-another-is-not-running-applescript
set appMustBeRunning to "xcode"
set appToKill to "Snippets"
tell application "System Events"
set appMustBeRunningID to (unix id of processes whose name is appMustBeRunning)
set appToKillID to (unix id of processes whose name is appToKill)
end tell
if appMustBeRunningID is {} then
try
tell application "Snippets" to quit
end try
else if appToKillID is {} then
tell application "Snippets" to launch
end if
The Second post is a revision showing how to add more than one master & slave application
Applescript – Quit or Launch Application script.. ( Revised )
Also has an a script for if you just want to run the Applescript as an Application.

infinite loop in applescript stops logout

So I am writing a basic applescript to end a very annoying program that randomly opens and interrupts me while Im working. The program needs to stay but i don't want to see it. I want my script to open automatically when the computer restarts (I did this in settings). I want to test to make sure it works but upon saving it as an application I cannot logout or shutdown or restart without manually force quitting. I assume this is because of the repeat loop but i don't know how to fix this. Ive tried everything i could think of. Any help would be greatly appreciated. thank you
on appIsRunning(appName)
tell application "System Events" to (name of processes) contains appName
end appIsRunning
repeat
if appIsRunning("LiveUpdate") then
tell application "LiveUpdate"
quit
end tell
end repeat
I'm not sure you have the proper approach either. However, if you want to do what you are trying to do then you want to create a stay-open application. You do that by saving the applescript as an application and checking the "stay open after run handler" checkbox. Here's how you write the code for that...
on idle
if appIsRunning("LiveUpdate") then tell application "LiveUpdate" to quit
return 10
end idle
on appIsRunning(appName)
tell application "System Events" to (name of processes) contains appName
end appIsRunning
Notice the "on idle" handler. That is the handler that is repeatedly run while the application stays open. Notice that I have placed "return 10" at the end of that handler. That determines how often the idle handler runs, in this case every 10 seconds. You can change that to what you want.
The advantage of this method is that you can quit this stay-open application. You won't get stuck in a repeat loop that you can't quit.
You mention that you do not want to see this application while it is running. To make that happen you will have to modify the info.plist file inside the application bundle (right-click on the application and show package contents). You have to add the "LSUIElement" key to the plist and give it a value of true. Then you won't see the application in the Dock while it's running.
Because you can't see it running you will need some way to quit the application. You can do that either using another applescript...
tell application "My Stay Open Application" to quit.
Or you can open activity monitor and quit it from there. Good luck.
Here is another approach:
on idle
if application "LiveUpdate" is running then tell application "LiveUpdate" to quit
return 10
end idle

Can a Cocoa app's executable steal focus from caller?

Say I have a standard Cocoa Application call Foo.app (like the one you get just by choosing New Project > Cocoa Application in Xcode), if I open the app via a terminal using:
open Foo.app/
Then I see Foo's name on the status bar up top and its window is in focus, in front of all other apps.
If instead I directly call from the terminal the executable buried in the .app folder, like:
Foo.app/Contents/MacOS/Foo
Nothing appears to happen. On inspection the app has indeed opened but it is not in focus (the terminal still is), I have to find it on the dock or find its window.
Is there any way for the Foo application to make sure its in focus when its run? Even if its run via its executable as described above?
Your app can "steal focus" by calling
[[NSApplication sharedApplication] activateIgnoringOtherApps:YES];
See the NSApplication docs for more info.
did you mean to type:
open -a /Applications/Foo.app/
note the -a option
If you're asking how to give your app (that you're writing) this behavior -- within applicationWillFinishLaunching: you could call [NSApp activateIgnoringOtherApps:YES].
perhaps AppleScript?
tell application "TextEdit"
activate
end tell
There are (at least) three different ways you open (and interact with) Applications from the Terminal.
you can launch any Application (that is registered in LaunchServices) from the Terminal by typing open -a ApplicationName (note that you do not need the trailing ".app" or give any path)
you can open an application giving its specific path by typing open /path/to/ApplicationName.app (you will rarely need that, given that the applications is likely already registered in LaunchServices)
you can open and interact with the executable if you type open /path/to/ApplicationName.app/Contents/MacOS/ApplicationName. The difference here is that for some Applications, you can pass arguments or interact with them afterwards on your command line. Go ahead and try open /Applications/Mail.app/Contents/MacOS/Mail for example - it will give you a debugging log in return.
you can interact with some applications even without using "open" by directly calling their executable; try /Applications/Firefox.app/Contents/MacOS/firefox-bin —help for example.
So if you do want to make sure the command-line-launched application is in focus, use either method 1 or 2.

Google SketchUp close file

The Ruby API to Google SketchUp has a function, open_file, but I can't find a close_file function. Since I have to batch process many files, I want to close each file before moving on to the next, otherwise the program will crash from memory exhaustion.
What is the best way to close SketchUp files programmatically?
I am using Mac OS X and am willing to use AppleScript functions to signal the window to close.
EDIT
I am considering a few approaches that have proven fruitless so far.
Using the appscript Ruby gem, as described in this question. The problem here is that I cannot get SketchUp to recognize my installed gems.
In a similar vein, I am trying to use osascript (a bash program that executes AppleScripts from the shell) to close the window. That is, I call out to the shell from SketchUp's Ruby console window using one of the following:
%x[osascript -e 'tell application "SketchUp" to close window 1']
%x[osascript -e 'tell application "SketchUp" to close window 1' &]
%x[osascript -e 'tell application "SketchUp" to close every window']
%x[osascript -e 'tell application "SketchUp" to close every window' &]
Whenever I try this second approach, SketchUp just freezes. However, when I execute any of these commands from an IRB or directly from the Bash prompt outside of SketchUp, I get the desired behavior: the model window closes (incidentally, the Ruby console window remains open, which is fine).
Have a master script that launches a slave script to process each model. The slave will run within the Google SketchUp program while the master waits. When the slave is finished, it signals the master, and the master closes the SketchUp file. To do this interprocess communication, I tried using drb. However, when I try to require drb within SketchUp, I get the following message:
Error: LoadError: (eval):5:in 'require': no such file to load -- drb
EDIT 2
Having a separate process continuously running that closes Google Sketchup windows using AppleScript when signaled is clumsy for a number of reasons. First, it's ugly to have to have a separate process devoted to closing Sketchup windows. Second, the only effective way of communicating with the external script is through the creation of files, which is wasteful and the disk access may be slowing things down.
However, the most severe issue is that Sketchup is slow at responding to AppleScript commands. I have a pretty computation intensive script running in Sketchup, and it seems to starve the AppleScript response, which means that the osascript times out before the windows close. Sketchup only gets around to responding to AppleScript when there is a dialogue box prompt in Sketchup that pauses the execution of my computationally intensive script.
EDIT 3
I have modified my close_file function to pause execution of the script by displaying a dialog box. This essentially yields the current thread and allows the thread that responds to AppleScript commands to execute:
def close_file()
f = '/temp/mutex.txt' # for finer control, use different mutex for each window you want closed
File.new(f, 'w').close
result = UI.messagebox "Click OK when window has closed."
end
Then the separate ruby script that closes windows via AppleScript will additionally have to click "OK" in the dialog box. AppleScript to do that is:
tell application "System Events"
tell process "SketchUp"
set frontmost to true
keystroke return
end tell
end tell
This modification is an improvement. It corrects the "most severe issue" mentioned in EDIT 2, but the other issues remain.
There is an important limitation with using an external AppleScript to force SketchUp to do something. SketchUp will not accept any user input while a menu script is running.
I found this out trying to setup an automated rendering solution. I added a menu item which opens a WebDialog to get a list of models to download from a server. It then steps through the list and uses cURL to download each model. Once downloaded it loads the model, renders it out, uploads the images using cURL again, and goes to the next model.
What I wanted was to activate the AppleScript after each model is rendered (using the "mutex" file solution shown above) and have it close the model window. Unfortunately, since the menu script is still running, SketchUp will not respond to anything the AppleScript tells it to do. Only once all of the models have been processed and the menu script exits, will the AppleScript finally run.
This would not be so bad if all of the calls to the AppleScript were queued up, but they aren't. It seems that only the last two get honored (that number may be just an accident dependent on the timing of when my calls to the AppleScript were made relative to when the menu script finished).
Because of this limitation, I was not able to use the mutex wait() function in my menu Ruby code. Since the AppleScript was not able to execute, it never created its "I'm done" mutex file, and therefore the wait() function in Ruby never got the signal that it could continue. The result was a deadlock between AppleScript and SketchUp, such that SketchUp just freezes up (well, actually it is just stuck in a really tight loop in the wait() function).
So, when approaching this problem, think of AppleScript as a cleanup tool you can call when all of your processing is done.
One solution is to have a separate process continuously running that will close Google Sketchup windows using AppleScript when signaled. The approach described here uses files to do the interprocess communication (drb did not seem to work).
First, you have to make sure Sketchup supports AppleScripting. To do this, execute the following at the command prompt (with appropriate substitutions for different Sketchup versions, etc.):
$ defaults write /Applications/Google\ SketchUp\ 8/SketchUp.app/Contents/Info NSAppleScriptEnabled -bool YES
Now, create a separate file that will close Sketchup windows. Here is my closer.rb file:
#!/usr/bin/ruby
## closer.rb ##
def wait(f)
while !File::exists?(f)
end
File.delete(f)
end
def signal(f)
File.new(f, 'w').close
end
while true
wait('~/temp/mutex.txt')
msg = %x[osascript -e 'tell application "SketchUp" to close every window']
signal('~/temp/conf.txt')
end
Run this script from the shell. It waits until the file ~/temp/mutex.txt is created. Once the file is created, it runs osascript (essentially AppleScript) to close all the windows in Sketchup, and then signals that the windows were closed by creating a ~/temp/conf.txt file.
Here is the client code (which can be placed in your Sketchup plugins) that signals the closer script:
def wait(f)
while !File::exists?(f)
end
File.delete(f)
end
def signal(f)
File.new(f, 'w').close
end
def close_file
signal('~/temp/mutex.txt')
wait('~/temp/conf.txt')
end
The close_file signals the closer script and then waits for a confirmation that the file was closed before returning. Now you can close files in Sketchup.
You can do a lot with SketchUp using applescript and/or Automator.
tell application "SketchUp"
activate
tell application "System Events"
delay 1.0 --close window, adjust delay to suit
--key code 13 using command down -- Press ⌘W or you can use
keystroke "w" using command down
end tell
end tell
I have a number of status bar items for open new, paste to console, closing, killing SU etc.
They're tiny files that trigger the SU shortcut keys, and can be used externally, from 'Ruby Console' or as part of a plugin.
I'm not sure what kind of 'batch convert' your trying to achieve, but
I used Automator to convert most of my old v5, V6, v7 files to v8 today...
100's of them,
and your probably aware, on opening you get 'alert' warning that saving will convert the file to the latest version (which is what I wanted).
It's tricky to click this "OK" programatically.
Automator on it's own is quite restricted, but you can add an applescript to the workflow and I've found that if you use it's 'record function' to demonstrate what you need to do.
You can then copy/paste that code into 'Script Editor', get rid of the 'dowithTimeout' bits, copy it back into the workflow with delays either side and let it run.
I had to play around with delays, to accommodate some larger files, but achieved >95% success. [Success being able to select all, right click, Create Icon and Preview.]
Unfortunately I then binned the workflow, but could recreate it, if you want to have a look.
success, in Ruby Console
system("osascript -e 'tell application \"suoff\"' -e 'activate' -e 'end tell'")
and this script inside an Automator.app in applications folder....
on run
-- Make sure SU is foremost, don't click on anything else either
tell application "System Events"
tell process "SketchUp"
set frontmost to true
-- gives a message if you try to select when SU's not running
delay 0.2
tell application "SketchUp" to quit saving no
-- no dialog box etc...
delay 0.1
end tell
end tell
end run
the problem is SU has an anti self destruct ruby, that mines any linked files and aborts all efforts to shut it down... from inside itself.
so you need to bury it...
this combination works on 10.5.8 with SU8.1.
if you have a look at SketchUcation [Developer] Forum, I left a call for mac/applescript testers... I've rewritten the app since then but if you PM me I'll send you an open copy of all the bits I've got working..
john
I had to convert hundreds of .skp files with a batch processing script. I faced similar issue, since every time I opened a new file it remained opened. For me it was enough to close the active_model and the file goes with it.
This was true for SketchUp 2019 Pro Mac OS X version.
model = Sketchup.active_model
model.save(filename, Sketchup::Model::VERSION_2015)
model.close
Hope it will help

Resources