@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.
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.
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?
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).
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.
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:
This forum is an amazing resource which takes a lot of (largely impossible) load off me.
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).
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.
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.
