(Macro Group) palettes have the great advantage that they overwrite shortcuts of other apps when they are open. So ⌘+a can do something else than "select all" when the palette is visible/active.
Unfortunately this does not apply to KM shortcuts. So if ⌘+a is already used by KM (without palette) and additionally as trigger of an action of a palette, then KM shows a conflict palette.
Is there any way to avoid this? Actually KM should be able to distinguish if ⌘+a is triggered with or without an active palette. Anyway, this would be very useful
PS: If ⌘+x is used in different apps, there is no conflict because the app is the differentiator. Why can't the active palette be the differentiator?
I’ll be honest, my knowledge on palettes is pretty basic because I don’t use them that much. But there’s really no such thing as an active palette. Macro groups (and by extension the macros they contain) can be active; but a palette works according to the macro groups settings. It is only visible when it’s called for, be it by a hotkey, via an action in a macro etc.
Also, KM overrides apps native hotkeys, but it’s not going to override it’s own hotkeys. So if you have the same hotkey assigned to do two different things, it’s going to present you with the conflict palette so you can decide what you actually want to do. This is by design.
I’m assuming you’ve already read this documentation, but just in case you haven’t it explains the palettes’ purpose and function.
Hi Chris, it's obvious that KM works the way you say it does. But I don't really understand why this restriction should be necessary.
KM can distinguish almost anything and then do something different as a result of those differences.
The most trivial difference is another app. That's why the same shortcut can be used differently in two different apps, without any conflict.
Why is it not possible for KM to recognize if a palette is visible? Its own palette! If KM would recognize this, it could do something different because of this difference.
I have no idea about coding, but if this is possible in a later version, I would appreciate it. And probably not only me, because this opens up many additional possibilities
PS: I imagine a visible palette could be like an additional pressed modifier (p). That would mean ⌘+a with visible palette would be equal to p+⌘+a. (No conflict) Is this a stupid idea?
I have done this test. Two apps (Safari and Scrivener) are triggered with the same shortcut (⌘+1). Additionally, with KM I have globally replaced the letter "a" with "b". "a" no longer exists, in any app.
Now, if I press ⌘+1 a conflict palette appears as expected.
The palette tells me that „a“ opens Safari and „b“ opens Scrivener. And that's exactly how it is. But "a" doesn't exist anymore, it has become "b" and therefore should open Scrivener.
Conclusion: KM overwrites its own shortcuts when a conflict palette is visible/active. This is good! Why is this not possible with other palettes? Or is it possible?
Sorry, be patient with me, it's certainly not my intention to be exhausting. I just would like to understand this.
ObDisclaimer: As always, what follows is my opinion, reinforced by some quick tests. Errors and Omissions Excepted!
Group palettes don't "overwrite shortcuts" -- they're visual (and clickable) displays of (a subset of) the currently active macros and their triggers. It's the KM Engine that "gathers" your keystrokes, not the Group palettes.
I don't think your test shows what you think it does. KM can't send simulated keystrokes to be used as hotkey triggers, plus the Conflict Palette is higher in the events hierarchy so it "swallows" the keystroke anyway.
Part of the problem is that you're looking at this "upside down". If KM is a collection of macros with triggers, you're approaching it as a collection of triggers with macros Not a bad thing, but it might require some re-thinking...
There is no "active Group palette" -- but they are either visible or not visible. So if you have macroA and macroB and
You want them to have the same hotkey trigger
To be active in the same context
You don't want the Conflict Palette to be invoked
You want to run one when a palette is visible and the other when the palette isn't
...then you'll need to remove the hotkey triggers from both macros. You'd then set up a "control" macro with the required trigger which would test for the presence of a, or a specific, palette and then run the appropriate macro.
Demo time! I've specified the "Menu Glyphs" palette, since that's available to everyone via the Macro Library, but you can change the palette name in the AppleScript action to match the palette of your choice:
@Nige_S That's brilliant, Nige. It's exactly what I wanted. Thank you so much!
Am I the only one who thinks this is great? My most used shortcuts with my left hand cmd + q/w/e/r/a/s … and so on, now can all be used double, depending on whether the palette is visible (for 1 action) or not. "Visible" means it can be shrinked in a corner of the screen. I don't need the palette to read the macros, but as a "modifier". I know this is "technically" completely wrong, it's just a way to explain it to myself.
Isn't that exactly what my test shows? Conflict palettes have the "if relation" of your macro already integrated, so to speak
There is one detail I don't quite understand. If I call the palette with cmd+q. And in the palette is also the quit command. Then cmd+q+q should close the front app. But it shows a conflict palette. This seems to me only partially logical. The first cmd+q opens the palette. Now only the triggers of the palette should be active. So there should be no conflict. But yes, cmd+q also opens the palette. That's kind of a circular thing
Anyway, this is insignificant. Thanks again for this macro. I still need to figure out exactly how I will use it, but it will make my shortcut life easier.
Not quite. The Conflict Palette intercepts every key stroke when it is up, and usually either filters the conflict list (key stroke matches possible macros) and swallows that key stroke, or (non-match) cancels the potential macro activation and passes the key stroke to the active app. By your test's logic, if you changed a = b to c = b and changed the hot key to C, then typing ⌘1 then c would open Scrivener -- and that's not what happens.
So not an "if" relationship of any kind, but a result of the event processing hierarchy -- a subtle, but important, difference. And even more important when dealing with Group Palettes, which are outside that hierarchy.
If the palette is triggered by ⌘Q, and opening the palette activates a macro that is triggered by ⌘Q, you now have two things triggered by ⌘Q and so get the Conflict Palette. You'd have to somehow disable the palette's trigger when the palette is visible to avoid that.
If I'm misunderstanding, post an example Group complete with settings and macro.
Not a bad thing, but it might require some re-thinking...
