Can an app be opened in the background?

Is it possible to open an app in the background using keyboard maestro without switching to the app?

1 Like

Found a way to do this using Applescript.

do shell script "open -ga" & quoted form of "/Applications/DEVONthink Pro.app"

Hey Mirizzi,

That’s not really AppleScript per se. That’s AppleScript running a shell script, and since Keyboard Maestro will run shell scripts directly it is the slower way to do this.

The pure AppleScript would be:

tell application "DEVONthink Pro" to run

The plain shell script would be:

open -ga "DEVONthink Pro"

-Chris

Comparing shell script vs Applescript vs javascript, which is the fastest for performing actions and which uses the least resources?

Hey Mirizzi,

Keyboard Maestro runs all scripts from the shell (AppleScript using the shell command osascript).

So you get a little overhead from AppleScript, JavaScript, or JXA.

As always running an AppleScript of any form is faster if run from a script-file rather than as a text-script – but for short scripts this is usually not noticeable.

For this task I would run the pure shell script myself.

-Chris

@ccstone answered the question accurately, but in practice it is rarely an issue of which form of scripting you use, and more an issue of

  • how often you execute it
  • how much any lag will really affect you
  • how the script is written

In almost every case, the answer are: not often enough to matter; not much; and doesn't matter. The important thing in most of these cases is actually to optimise the time it takes you to create the macro in the first place to ensure you're not just wasting time up from to save not much time in the future (that said, that future wasted time tends to be more painful than the tim,e spent creating the macro, so it is often a net-win regardless of the actual time saving).

Unless and until you have a macro that you are executing regularly and taking enough time to say "I wish this ran faster", there is not much point asking the question which scripting system will be faster - they are all fast enough normally, and when they aren't it is more likely the complexity of the problem (or the solution) that is thee issue rather than the scripting system per se.

I wouldn't say it doesn't matter, because experience is very subjective. Nevertheless Peter's points are generally typical of all programming and worthy of consideration when making a macro.

I start noticing timing issues at about 0.02 seconds, so if I use a macro regularly I want it executing as fast as possible. However that doesn't mean I'll spend 5 hours optimizing something just to save a 10th of a second.

When I run complex AppleScripts on my system regularly they get run from a compiled script – especially any scripts that do GUI-Scripting with System Events. It takes very little time to set up and has the added benefit of making AppleScripts easier to edit and test.

(I put them in a subfolder of KM's Application Support folder and have a macro to open it in the KM menu.)

This does not mean I'll never use text-scripts. I have plenty of them where the time issue isn't enough to bother me, and it's more trouble than it's worth to save them as a script-files.

-Chris