Conflict Palette—Triggering a Macro Exclusively With the Keyboard Has a Limitation

[_jims]

@peternlewis, I have a suggested modification—if it's possible. It's best described with an example.

Suppose I have a simple Conflict Palette (CP)—that appears with Hot Key ⌃⌘1—and includes two macros: ABC and XYZ. Macro ABC has default and alternative logic based on the state of ⌘.

My preferred method to launch CP macros is with the keyboard, not by mouse movement and clicking. Of course I can efficiently trigger ABC (to run default logic) with the following keystrokes: ⌃⌘1 followed by a.

To execute the alternative logic, however, I am currently required to use the keyboard ( for ⌘ ) and the mouse ( to click ABC on the CP ). It would nice if I could trigger ABC (alternative logic) with the following keystrokes: ⌃⌘1 followed by ⌘a. Would it be possible to make that change?

A non-elegant work-around is to add actions at the beginning of the macro that waits up to 1 second for ⌘ to be pressed. With the workaround, the keystrokes are: ⌃⌘1 followed by a, followed by a tap of ⌘ (within a second of triggering).

Peter, thanks in advance for considering this change.

Work-around

[peternlewis]

@_jims

Would it be possible to make that change?

No. They are done with hot keys, and that would exponentially expand the number of required registered hot keys.

You will need to come up with an alternative. Perhaps add another macro with Control-Command-1 hot key that executes the ABC macro with a flag to specify the Command behaviour.

[_jims]

@peternlewis - thanks for the quick reply.

@peternlewis

No. They are done with hot keys, and that would exponentially expand the number of required registered hot keys.

Hum, based on your explanation I think I didn’t do a good job describing my scenario. ABC is not checking %TiggerValue%, it includes an If action that is checking if ⌘ is pressed.

So, effectively what I’m asking: when a Conflict Palette is displayed, could KM ignore the state of ⌘ while it is processing regular keys and matching items on the Conflict Palette (and in my scenario triggering ABC when a is typed?

[peternlewis]

@_jims

So, effectively what I’m asking: when a Conflict Palette is displayed, could KM ignore the state of ⌘ while it is processing regular keys and matching items on the Conflict Palette (and in my scenario triggering ABC when a is typed?

I understood. But the Conflict Palette has to register hot keys for the conflict key selections, and that would require registering all of the modifier variants for each key (which is 16 variants for each letter key registered).

[_jims]

@peternlewis

I understood. But the Conflict Palette has to register hot keys for the conflict key selections, and that would require registering all of the modifier variants for each key (which is 16 variants for each letter key registered).

Thanks for the additional information, Peter!

On a general note, I'd like to thank you for the great support you provide on this forum. I'm amazed how responsive you are and frankly can't imagine how you can do it and simultaneously continue the consistent enhancement of Keyboard Maestro.

[peternlewis]

@_jims

I'm amazed how responsive you are and frankly can't image how you can do it and simultaneously continue the consistent enhancement of Keyboard Maestro.

Because my support load is very low, in fact I'd hazard a guess that my support load-per customer for applications with equivalent complexity is exceptionally low, primarily for two reasons:

1. This forum is an amazing resource which takes a lot of (largely impossible) load off me.
2. As a lone developer, when I get repetitive support questions, I figure out how to rework Keyboard Maestro so that the question never has to be asked (the whole Interactive Help system is because of this for example).

[August]

@peternlewis

I'd hazard a guess that my support load-per customer for applications with equivalent complexity is exceptionally low, primarily for two reasons:

Given the organization and clarity of both the product and the doc, I would imagine that your code is similarly well organized and clear, which results in easier to maintain, less buggy code and thus reduced support load.

I also suspect that, because it's not a burden, you enjoy giving the support that you do, so it's more prompt, more complete, more gentle, more actually addressing the users real problem, etc., creating a "virtuous cycle". I wish Google and Apple could maintain your standards. Unfortunately, they seem to have feedback loops that run the other direction.

Keep it up. You have a lot of fans.

[_jims]

@August

Given the organization and clarity of both the product and the doc, I would imagine that your code is similarly well organized and clear

Yes, I'm sure!

I've noticed that some of the best macOS apps are from indie developers that clearly eat their own dog food.

[johns]

I wonder also, if the nature of your customer is more technical, and therefore less likely to need help with very basic things that most developers spend time supporting.