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."
Related
I've seen a few questions dealing with this issue but nothing recently. I'm not sure if El Capitan (10.11) is breaking something, and I'm an AppleScript (and Automator) newbie.
I just want to have the basic functionality where a keyboard shortcut opens a new terminal window in the space I'm in. After doing the following things, absolutely nothing happens when I trigger the keyboard shortcut
1. Create an Automator Service
Open Automator and choose Service for my document type.
Set Service recieves selected to no input
Drag a Run AppleScriptaction into my workflow.
on run {input, parameters}
tell application "Terminal"
do script ""
activate
end tell
return input
end run
(At this point, running the workflow from automator by pressing Play opens a new terminal window correctly).
Save the service as Launch New Terminal Window
2. Assign a Keyboard Shortcut
Open System Preferences -> Keyboard -> Shortcuts -> Services
Assign Shift Command T to Launch New Terminal Window
When I try my new command, nothing happens.
Note, I tried to delete the service and retrace my steps. When I recreated a new service with the same name, the keyboard shortcut was remembered by the system. Does anyone know which .plist/where these keyboard shortcuts are saved?
If anyone can help me out, that would be great. A 30 second project has turned into 30 minutes of hair pulling.
I also encountered a similar problem. The issue is that, most probably some other application is using the key combination that you tried. You can check by using a bizarre key combination and check whether it works and then modify it. Try using something like Shift + alt + command + G. Or something like this ( use at least 4 keys ). It worked for me. Hope it helps you.
For future reference, since it seems a very common question, I think the only reason why a shortcut won't work is that it's being used by other application, as 2XSamurai said.
You can have quick feedback if the shortcut is going to work or not by navigating to Finder and then Services.
If your brand new shortcut is showing next to the service you created, that means is going to work, otherwise, it won't.
No need to perform other actions, you just need to pick a good shortcut. Somewhere on the web, you may also read that you must include the command key to make your shortcut work. That's also not necessary (see the screenshot with just ctrl + T combination working just fine).
PS I can't post pictures on answers yet so StackOverflow generated links to the images instead, but this caused the answer to broke (I was getting a message error stating there was code in my answer (??), so no screenshots, sorry, I hope the answer is clear enough even without them :)
I did exactly what you've described (Automator Service, no entry, only one Applescript Action, and assign the Automator Service to short cut key (in my case command shift Y).
All is working OK on my ElCapitain with bellow script in Automator action : (I mean the short cut opens a new Terminal window as expected)
tell application "Terminal" to activate
tell application "System Events"
tell process "Terminal"
keystroke "n" using {command down}
end tell
end tell
But I still ask myself the basic question : what do you really want to achieve ? usually the bash instruction could be done in do shell script command...no need for Terminal window... may be you have an other constraint.
I had the same problem before, solved it somehow, forgot about it and ran into it again when setting up a new MacBook today.
This solution works for me on several Macs:
Instead of using System Preferences -> Keyboard -> Shortcuts -> Services (screenshot 1 - for some reason I'm not allowed to insert pictures directly into posts) you can use
System Preferences -> Keyboard -> Shortcuts -> App Shortcuts (screenshot 2).
There you have to spell out the name of your service.
There are some issues with the App Shortcuts menu as well. For example a shortcut for the "Tags..." menu in Finder simply won't work but for services it works for me.
I'm on MacOS X, and I'm pretty new to app-bundle-type things. I am writing a program that opens a window and registers mouse input -- not a command line tool. When I compile my code (written in C, if that is important) into an executable file (a "unix executable file") and then run that file directly (by double clicking it, for example), a terminal window pops up, and then the program's window pops up. Likewise, if I navigate to the directory of the executable and open it from the command line, it pops open /another/ terminal window and then the program's window.
However, if I wrap the executable in a bundle (thus, I suppose, turning it into a proper "app"), then when I run the app, either by double clicking or from the command line, the program's window opens and no new terminal window is created. Is this merely a property of the "app bundle"'s architecture? Or is there a way that I can run the raw executable without incurring another terminal window? I suspect that I'm misunderstanding something fundamental. Thanks in advance!
I believe what you're seeing is correct. In order for a separate window to not pop-up, you'd need to encapsulate it into a bundle.
Launching by double-clicking a bundle, or using the 'open' command from Terminal uses Apple's Launch Services, which maintains a list of known (registered) applications. When an application (bundle) is introduced to the system, it is registered with Launch Services and associated with its URI (e.g. com.apple.calculator), which is present in the bundle's Info.plist
Other items in the Info.plist tell launch services how to handle the application, such as checking if the minimum or maximum version of the OS has been exceeded, or whether or not to display a dock item.
A lone binary doesn't have an associated Info.plist manifest, so its behaviour can't be varied and a Terminal window is opened.
Bare executable files are essentially treated as documents by Launch Services (the framework that the Finder, Dock, and open command use when you open stuff). The application which handles such documents is Terminal. So, when you open an executable in that fashion, it launches Terminal if it's not already running and tells it to open the document. Terminal does this by opening a new shell window and auto-typing the path to the "document" as a command line.
Launch Services handles bundled apps as, well, apps. If the app is already running, it activates it and possibly has it open a new untitled window. Otherwise, it launches it.
As Rob Napier notes in the comments, if you run an executable directly from the command line (or if some already-running app launches it using NSTask or fork+exec), it will simply run. Launch Services won't be involved, so Terminal will not be asked to open the executable as a document.
No-one has been able to answer this question.
It would seem to be impossible to have XCode open this way.
However Youssef provided the most useful answer - so Youssef gets the points, thank you Youssef.
Note for future readers .. the mac utility Moom is excellent for some, but not all, problems of this nature. Again it is not a total solution.
Using the current up-to-date XCode,
Whenever I OPEN a project in XCode (or start a new project),
it looks like this:
However, I want it to look like this:
Again that's when I OPEN a project.
Is there any way to achieve this? Thanks.
Go to Xcode (in the top menu bar) --> Preferences...
Switch to the Behaviors tab and modify what you want in the Running section
You'll get something like this:
You can choose to show/hide what you need, and specify the default behavior
Cheers
EDIT:
After understanding what you need, I will modify my answer.
There is no way to force XCode to automatically enter a behavior at startup.
The best you can do is to create a custom behavior and give it a keyboard shortcut. And when you start XCode just use the keyboard shortcut to enter the desired behavior.
This is how it is done:
In the behaviors tab (above) click on the + sign at the bottom
Then enter the desired name of this behavior (Maybe StartupBehavior)
Click on the left button to modify the shortcut key. My preferred shortcut key is Command + ` (the button to the left of the '1' key). This is because it will not override any other command and it is easy to click.
Note: you can specify any shortcut you like and dont be afraid to override one that already exists if you don't use it.
Now you need to configure your behavior the way you like it
Close the preference windows.
Now everytime you start XCode just use the shortcut key you specified (Command + ` in my case) to quickly load your behavior
Note:
If you dont like keyboard shortcuts you can also load your behavior by going to Xcode (menu bar) --> Behaviors --> Select your behavior
That is the quickest way you can achieve what you want. I dont think you will be able to force Xcode to run your behavior automatically on startup.
Hope it helped.
Cheers
(not really default layout, you have to hit at least 2 keys simultaneously once XCode is open) You could set up a behavior for "Build->Starts" and hit "CMD + B"
after opening XCode / any Project. This way it will 1. change to your
Layout even if there are any errors and Build fails and 2. you don't
have to Stop it again.
As already said, it's not a default layout, but I like to let the compiler run through projects of other people at the beginning anyway.
You could search for some Keys in XCodes preference file in
~/Library/Preferences/com.apple.Xcode.plist as already suggested in
my comment, I'm not experienced enough to know which are the right
ones, sorry.
Wrap the .xcodeproj File opening in an application. E.g. in no way "clean", but anyway:
Set up an XCode behavior like in option 1
Open Automator, choose Application, drag "open Finder Items" and "run AppleScript" inside.
on run {input, parameters}
set frontmostAppName to name of (info for (path to frontmost application))
repeat while frontmostAppName is not "XCode.app"
set frontmostAppName to name of (info for (path to frontmost application))
delay 0.5
end repeat
try
tell application "System Events" to keystroke "b" using {command down} --simulates CMD + B
end try
return input
end run
Insert some applescript like the above and save the Automator application.
RightClick -> getInfo on any .xcodeproj File in Finder/on Desktop, in "open with" select your new Automator app, click add and back in the info panel -> check "Change All"
You can obviously create a new Behavior instead of using Build->starts, assign a different Hotkey in XCode and script e.g. tell application "System Events" to keystroke "i" using {command down, control down, shift down, alt down} , optimize the applescript somehow or do everything via a real cocoa app if you want
Well, you may be able to approach it using preconfigured xcuserstate files nested in your project templates' default workspace directory, but that is going to be a pain to tweak and maintain. I'm not even sure it would work.
I would personally just approach it by using Behaviors.
So:
1) create a Behavior
2) Give it a convenient key binding
3) Then define the Behavior. For example:
ASCII Behavior Editor:
...
√ Show *Debugger* with *Console View*
√ *Hide* utilities
...
That should do it. Just hit the assigned key command when you want to restore that display state, regardless of its initial state.
Of course, you can do a few other things or all sorts of arbitrary stuff by running an external AppleScript (triggered with a Behavior's run script facility).
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.
Using AppleScript you can create a script that runs another application, and then save that script itself as an application and place it in the dock. The problem (not really a problem) is that when you click it, it will still show the other application on the dock. Is it possible to prevent the other application from showing in the dock, yet show its GUI as it would normally do when executed?
Thanks
The only solution I can think of is to actually modify the 'other app' to have no Dock icon. It works, but it's nasty:
•Yep, you're directly modifying the other app—not doing something from your script.
•Accordingly, it will change every launch of said other app, not just invocation from your script.
•It prevents OtherApp from having a menubar (though key combos and any in-window controls will still work).
It's easily reversed though, and can almost always be done just by adding a GUI mode flag to the app's Info.plist file:
Right- or Ctrl-click the other app and Choose 'Show Package Contents'
Open the 'Contents' folder
Open the Info.plist in your text/xml editor of choice*
Add these two lines right after the first line that says <dict>
<key>NSUIElement</key>
<true/>
Save, then fire up the app. Remember… no menubar, so make sure one of its windows has focus and -Q to quit when you verify it runs with no Dock icon.
*If you're squeamish with editing xml, or if the plist file is the binary variety, you'll need a dedicated plist editor. Apple's own Property List Editor is included with their free Dev Tools.
Add a Child to the root ("Information Property List").
Set the name to NSUIElement.
From the Edit (or context) menu, set the Value Type to Boolean.
Click the checkbox ON (sets the bool to true).
Building off the previous answer -- you can modify the Info.plist of your Applescript application with the same XML code. This will prevent the Applescript app from displaying an icon (and having a menubar, which in my experience is unusable anyway for this type of 'app'), but your main application -- the one you're launching from the applescript -- will display in the Dock as usual.
I tried this on OSX 10.7 Lion and it worked successfully.