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.