Group Enable by Window Title, Use Multiple Titles?

[August]

One of the options to controlling when a macro is active is the Group settings. I can, for instance, make a set of macros only available when a Finder WIndow with a specific title is frontmost.

There are multiple threads in the forum about using this feature for Chrome tabs.

I want to push the boundaries of this feature (who, me?!). I want to set the Window Title field using a variable. But the field does not have the little icon in the corner indicating that a variable or a token can be used. That suggest to me that it only accepts literal text. I want to use it for Finder, to have multiple different Finder folders and to be able to swap which one has the macros enabled. Or specify all three, but that isn't an option either.

Am I wrong? Can I use a variable here? Can I have multiple text strings?

I haven't figured out a simple test yet, all my test ideas seem complicated and I'm not sure that I would be using them correctly.

If not, is there a way of working around this? Can I programmatically change the value in the group settings (e.g. at the same time as I would be changing the variable that I want to use)?

[August]

I think I'm answering my own question. I still haven't tested if I can use a variable there, but since there is no [T] or [V] icon in the corner, I am assuming that I can't.

I can make it work for a list of window names by having a group for each of the desired window names and separate the triggering from the macro definitions. That there is only one copy of the macros doing all the work, despite the fact that the triggers have to be in separate groups.

To have a set of macros and triggers that are enabled for an app window with one of (for instance) four possible titles, and not enabled elsewhere, I'll create four groups to specify the four cases of app and window title (=! Triggers for Finder Window AAA, etc.).

For now I'll call these Enablement Groups. The macros that I want to be enabled in the four cases will be in another group, the Target Group (=! Tools for FInder Windows AAA,BBB,CCC,DDD). These Target Group macros will not have any hotkeys or other triggers. They are triggered solely by the triggers of the Enablement Groups.

The triggers that I want to be enabled in only those four windows will be defined and copied to each of the Enablement Groups. They are simple, single action macros that when triggered, execute one of the macros in the Target Group.

This set of trigger macros is copied to each of the Enablement Groups and won't need much maintenance.

When any of the four defined windows is frontmost, the triggers will all work, defined in the Enablement Group to be active in that window. When the macros are triggered, they execute the appropriate target macros. The triggers only work in the defined set of window, the right macros are executed. That's the goal.

[tiffle]

Hi @August - you don't seem to have considered using a regular expression for your window titles like this for example:

I don't fully understand what you're doing but I'm wondering if this might help you.

[August]

@tiffle

you don't seem to have considered using a regular expression

No, I had not. I would not have thought that a text field would handle REs.

In the Wiki, on the "Regular Expressions (RegEx)" page, it says:

In any Action where the term “matches” is used, you may (optionally) use a regular expression.

So to use REs I just chose a "Matches" option instead of "Is" or "Contains", etc.

That's awesome.

KBM continues to amaze me with its elegant simplicity in handling complexity.

[tiffle]

@August

So to use REs I just chose a "Matches" option

Correct.

[griffman]

Regex matching was going to be my suggestion as well.

Another option that I often use is to go ahead and let the macro trigger generically based on a very broad condition, then only continue executing it if some condition I check within the macro passes. For example, I have a macro that decrufts URLs on the clipboard. It's got a generic trigger:

Then the first step within the macro checks if the clipboard contains something I want to deal with or not:

The time cost to start and cancel the macro is minimal, and this gives me full flexibility over the conditions under which the macro will continue—there are obviously many more things you can check and act on once within a macro as opposed to at the trigger stage.

-rob.

[vincent_ardern]

… have you tried a variable? I think I'm using some variable window titles (but I’m not at my Mac to confirm or deny sorry).

[August]

@vincent_ardern

have you tried a variable?

Thanks Vincent.

@August

I still haven't tested if I can use a variable there, but since there is no [T] or [V] icon in the corner, I am assuming that I can't.

If you find that working example, I'd like to see it.

[vincent_ardern]

Thanks for the reminder. Turns out I don’t use variables, BUT I DO use named clipboards with those clipboards containing RegEx.

Not identical, but possibly useful in that they can be dynamically updated.

[August]

@vincent_ardern

don’t use variables, BUT I DO use named clipboards

Thanks Vincent,

That's defnitely another direction to explore.

Your sample macro brings up what may be a BUG, which is probably a question for @peternlewis:

In your image above, when you have picked "Available when a focused window title matches:", the text field does not show a [T] icon at the far left, and yet you are successfully using the NamedClipboard Token. If Tokens work, then Variables should also work.

Which brings up another issue about this whole process, whether it's a variable or named clipboard or whatever, that I think I'd also like to ask @peternlewis, is how it works in terms of timing. When you open a window, or when you change focus to an existing window, first KBM sees that Brave, Safari, or Chrome is open, then it sees that the window title matches your Clipboard, so the macro group is activated. But what if you're already in that window and the clipboard changes? There's nothing to trigger KBM to notice and check, so you're on the right page but the macros aren't active until you change pages and return. Or are they? I'm guessing here. @peternlewis ??

As for my actual programming goal, I'm still trying to work out the overall "architecture" of a bunch of interconnected macros, and this was one way I came up with to have one set of macros to maintain while being able to change the triggers. I don't really know yet whether I will need to change triggers "on the fly" or whether I can change the macro code occasionally, when I need to.

Or maybe the RegEx solution will work and I simple have the macros active in multiple, narrowly defined situations, all at the same time. I do know that I don't, for instance, want them active in all Finder windows.

But I don't yet know whether I want them to be active in window AAA but not the others, and then active in window BBB, but not the others, including not active in AAA., or whether it would be desired vs. tolerable to have them active in AAA, BBB, CCC, and DDD all at the same time, since only one of those windows can be foremost. That distincion I don't know about yet and probably won't know until I'm using it. I guess I'll try coding whatever seems easiest (all active via RegEx) and then see if I have to change it.

Again, Thanks Vincent, for thinking about my problem and sharing your macro.

[peternlewis]

@August

In your image above, when you have picked "Available when a focused window title matches:", the text field does not show a [T] icon at the far left, and yet you are successfully using the NamedClipboard Token. If Tokens work, then Variables should also work.

Hmm, this is likely because it is not meant to be supported.

As a general rule, triggers and macro group settings cannot have tokens. And indeed in this case it will likely not work quite as you might expect.

For example, if you change the variable (or Named Clipboard - but it really should be a variable) that will not affect the current window matches.

Image the chaos is you used the RandomUUID token or ShortTime tokens in the trigger/macro group.

@August

Which brings up another issue about this whole process, whether it's a variable or named clipboard or whatever, that I think I'd also like to ask @peternlewis, is how it works in terms of timing. When you open a window, or when you change focus to an existing window, first KBM sees that Brave, Safari, or Chrome is open, then it sees that the window title matches your Clipboard, so the macro group is activated. But what if you're already in that window and the clipboard changes? There's nothing to trigger KBM to notice and check, so you're on the right page but the macros aren't active until you change pages and return. Or are they? I'm guessing here. @peternlewis ??

Exactly why it is not really supported. And the answer is “I don't know, and I would not want to guarantee its behaviour”. I expect the check only happens when the focussed window changes (or the title of the window changes).

So basically, this is not supported and if it works and it's useful, then that is lucky for you but don't expect it will necessarily continue.

You can see the workarounds done in the Display in Menu Bar option, which explicitly allows a variable and allows token text with an explicit update frequency.

[vincent_ardern]

@peternlewis

not want to guarantee its behaviour

Fair call, but eek! Given that, may I please make a feature request to add a workaround similar to that for the Display in Menu Bar option to the Macro Group availability logic?
For what it's worth, my use case is displaying two different palettes (for different types of tasks) on certain websites. I imagine I could get this result some other way but this way seems very performant, and easy to configure on my end - although I'm not enthusiastic about using an unsupported idiosyncrasy to make it happen!

[peternlewis]

@vincent_ardern

Fair call, but eek! Given that, may I please make a feature request to add a workaround similar to that for the Display in Menu Bar option to the Macro Group availability logic?

Maybe, but unlikely.

Triggers/Activations with varying conditions are liking to cause more than a few problems trying to implement them consistently.