KM - Application Specific Triggers?

I’ve quickly run into the issue of not enough keyboard real estate as it pertains to triggering automation for Keyboard Maestro.

This morning, while realizing how much I despise the archiving keyboard shortcut for Spark, I decided to make my own version. Then, I discovered the “if” function within KM, which you can set to only trigger the “automation” if a given application is “at the front”.

This is a potential game-changer for me as I can now have contextual automation!

Of course, there are some downfalls to this approach (ie, you the human forgetting the change).

Either way, I wanted to share this little nugget of awesomeness with my fellow automation nerds :nerd_face:

Bonus idea - Use KM to correct your typing if you’re a fast typer! I routinely type “teh” instead of “the”. Rather than pausing to handle that pesky issue, KM handles it for me as if nothing happened. It’s like boosting your typing speed 10% automatically :rocket:

1 Like

You can put your macros into groups and specify at the group level what applications they apply to.

Here’s the settings for my Pixelmator Pro group for example.

2020-04-01-15.23.19_screenshot

This approach means you should be able to significantly simplify the multi-IF statement macros you would otherwise have to build, and assuming you name your macro groups logically, make it easy to track down key combinations for a particular app.

One thing I would recommend is that if you have a macro you use in multiple apps, still keep your groups to one app. Create macros in each macro group you want to use it that then call a macro elsewhere. Then you keep one copy to maintain, but you can easily tailor to a particular app later on without impacting any of the other apps.

2 Likes

This is fantastic! So Macros are only enabled while the application itself is open/active?

Could you elaborate on the nesting; how you break down your Macros into groups?

Edit: Started playing with this in Spark and it’s amazing :exploding_head:

Yes, take a look at the documentation - Keyboard Maestro wiki page on Macro Groups. There’s a wealth of criteria around the combination of apps, windows and general activation.

I don’t think anyone would benefit from seeing my dozens of macro groups - even I think they need a good tidy-up. Instead let’s take an example scenario.


Scenario 1 - Macro Level

First, we’ll start with the idea that I have three apps - app1, app2 and app3. Each app is capable of utilising hyperlinks. Now let’s also take it that I have a Keyboard Maestro macro (macroA) to take a tab of the front most Safari window and grab the page title and link and then it returns an HTML formatted hyperlink.

Let’s assume I have a macro called macroA which when I press CMD+ALT+A ,inserts an HTML link for the frontmost Safari tab. Now let’s assume I build into the macro some logic to activate whenever I use one of three apps - app1, app2, or app3.

Version 2020 of app3 drops and they switch from HTML to Markdown. Now I need to go in and amend my probably quite complex macro to also build Markdown links as well as HTML links, without breaking any of the other options that I’ve assigned to CTRL+OPT+A.

Scenario 2 - Grouped Group Level

Let’s assume for this scenario that I have one macro group called groupHTML. This is set to be active when any of app1, app2 or app3 are frontmost. I set CMD+OPT+A to run macroA which is in groupHTML.

Version 2020 of app3 drops and they switch from HTML to Markdown. Now I need to switch things around. I have to create a new macro to generate Markdown links (macroB), take app3 out of the criteria of groupHTML maybe create a new groupMarkdown and put macroB in there and set the activation criteria to include app3.

I do however have the advantage that when app4 and app5 come along that support HTML and Markdown respectively, it is really easy compared to Scenario 1 for me to add support for macroA and macroB. I just add the activation criteria to the relevant groups.

Scenario 3 - Separate Group Level

This is my preferred scenario.

This time we’ll assume that I have my usual three apps, but this time, I have four macro groups called groupHTML, group1, group2 and group3.

group1 is set to be active when app1 is frontmost. group2 is set to be active when app2 is frontmost. group3 is set to be active when app3 is frontmost.

I put the HTML link generating macroA in groupHTML.

In each of group1, group2 and group3 I create a macro that runs macroHTML when I select CMD+OPT+A.

Version 2020 of app3 drops and they switch from HTML to Markdown. Now I need to switch things around. I have to create a new macro to generate Markdown links (macroB),and I place this in a new groupMarkdown group. I then change the name of the macro being executed on CMD+OPT+A for app3 from macroA to macroB.

It was a little more effort in the initial set-up (macro duplication eases the pain dramatically), but maintenance is very easy.

When app4 and app5 come along that support HTML and Markdown respectively, I can re-use the macros and existing groups, but would create new app specific groups for these apps. Now whereas Scenario 2 allowed me quicker and easier grouping, this arrangement allows me to pick and choose at a more granular level. Maybe app4 has a keyboard shortcut clash and so I want to switch my link generator to CTRL+CMD+OPT+A in that app. Maybe app5 supports Markdown to a limited extent, and I want to actually use an HTML styling macro to do bolding. This scenario lets me pick and choose and exactly tailor each app.


All scenarios hopefully avoid the cardinal sin of duplicating the same code blocks over and over, but realistically, the only time this has any real likelihood of occurring is within the macro complexity in Scenario 1.

I hope that helps, all makes sense and you can follow my reasoning for why I opt to tackle things this way. But honestly, just go with whatever makes sense and works for you.

I cannot thank you enough for taking the time to write this up! :raised_hands:

This just 10x’d the amount of automations that I’m able to trigger.