Is it possible to activate an app with a variable specifying the name of the app? i.e. in the image below to active KM if the AppName var was "Keyboard Maestro."
I can't promise that this is the best way, but here is a chunk of my Stream Deck app switcher:
(I've got a dictionary of apps "AppDeck", keyed by the button pressed. But you get the idea) Second step is probably what you're after.
In a pinch you could use Cmd-Space to open Spotlight and paste the name in there
I guess the only problem with this is that the app has to already be open.
Depending on the use-case, the pool of potential apps might be small enough for you to set up a switch/case filled with open with actions.
How about this?
EDIT: Didn't notice @kraftyDevil beat me to it. Mine is the same solution using %TriggerValue%
and a local variable.
This also works
Edit: see two comments below for a theoretically safer approach, assuming you're not on the latest OS.
Hi @noisneil - that does indeed work. However, when I suggested this in a different thread, @peternlewis cautioned me against using it. (Also there is a yellow warning triangle in the top right of your Action and if you click on it, it also warns you).
Normally, using open with "Finder" rather than "Default Application" works fine with no warning triangle in that same action. But as of macOS 12.3 there is an AppleScript bug that breaks that (hopefully Apple will fix).
It would be very bad luck if your app was opened with another app by default with catastrophic results, and anecdotally, it's never done that for me. Better safe than sorry I suppose, so...
I actually agree. And in my testing this has never happened to me either so, I have been using with "Default Application" to open Applications using a Variable for the path to the Application, at my own risk in my own Macros, while the macOS 12.3 bug remains not fixed. But the yellow warning triangle is there to show it is not officially recommended.
Hi @Bobby_Joe. In short, I've found that the following action works well:
With that said, here's a subroutine that includes more information:
DOWNLOAD Macro File:
sub—Activate an App and Wait Until It Is Ready.kmmacros (37 KB)
Note: This macro was uploaded in a DISABLED state. It must be ENABLED before it can be run. If it does not trigger, the macro group might also need to be ENABLED.
And here's an example use of that subroutine:
DOWNLOAD Macro File:
Example call of—sub—Activate an App and Wait Until It Is Ready.kmmacros (2.6 KB)
Note: This macro was uploaded in a DISABLED state. It must be ENABLED before it can be run. If it does not trigger, the macro group might also need to be ENABLED.
It has never happened to me, either. But it has happened to other Keyboard Maestro users, hence the warning.
Basically, it is possible to end up with apps that operate on applications as the default opened for application. The Finder will still launch them normally (well, pre-12.3 anyway, sigh), but the system can open them as documents to that other application instead.
The Use Variable action or Execute a Shell Script action with open -a
are good solutions for this.
Hi @_jims - With the AppleScript approach, I have found I need to add in one more command to deal with restoring the App Window if it has been minimized. Otherwise what seems to happen is the App is activated but stays minimized. The extra command in the AppleScript is reopen
And to confirm - this AppleScript still works in MacOS 12.3
AppleScript
set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
set varAppPath to getvariable "LOCAL__AppPath" instance kmInst
end tell
tell application varAppPath
activate -- makes the app frontmost
reopen -- unminimizes the first minimized window or makes a new default window
end tell
And interestingly this AppleScript works if the Keyboard Maestro Variable LOCAL__AppName is either just the Application name, for example Final Cut Pro or the full path to the App /Applications/Final Cut Pro.app I can't take credit for adding the reopen
command, I found it here after a Google search.
@Zabobon, thanks for sharing that. I will add the reopen
to the subroutine I shared above and run it for awhile to make sure I don't encounter any unintended side-effects.
Doing some quick-and-dirty testing today, it appears that these two actions behave the same:
The open -a
also opens and and restores minimized windows.
As you might have read in the subroutine comments, I encountered a situation where it seemed that I needed both actions. I'm frustrated with myself because I normally document observations like this, but this time I failed to do so and I can't remember the exact circumstances. However, it was likely when I was activating an application assigned to another Desktop Space. Anyway, so far I've seen no harm in having both actions in the subroutine.
As has been noted by @Lantro the macOS 12.3 bug that stopped the Keyboard Maestro Action Open with Finder
working has been fixed in macOS 12.3.1
So, the below works again to open an Application and restore if it was minimized (using native Keyboard Maestro Actions only).