Feature Request: Palettes with "different layers"

KM palettes in all variations have become indispensable for me. I would like to see them developed further to make them even more useful.

One feature I miss is to have "different layers" for the same palette.

Example: A palette is always open at the edge of the screen and shows certain macros. I would like to be able to press and hold a modifier (or a combination) to display other macros. When the modifier is released, the "basic" macros appear again.

Of course I could open another palette for this or always have all macros in the same palette, but this is not the same. :slightly_smiling_face:

Am I the only one who finds this useful?

I suspect a palette that changed appearance every time you pressed or released a modifier would be quite distracting.

But if you really want to do it you could have a macro with a USB Device Key trigger that changed the activate of macros/macro groups when a modifier was pressed or released and in doing that would change the palette.

Thanks Peter, I would still like to try. :slightly_smiling_face: If I knew how.

I assume you mean something like this, but unfortunately this doesn't work.

Can someone help please? Thanks!

1 Like

Yes, something like that.

Whenever a macro “does nothing”, use the Interactive Help to find out what is happening.

In this case, I'd suspect the problem is with the modifier settings on the trigger - change them to "ignoring modifiers". Otherwise, if you press the Command key, then the Command key modifier might well be set, and if you release the Command key, the Command key modifier might still be set. Either way, it's right on the edge of the modifier changing, so it's not clear which one would fire.

Also, I would change to using the Trigger token to determine which one is firing.

1 Like

Yes, that works, thanks Peter. :slightly_smiling_face:

By the way, both work. this

and this

The trick was to select "ignoring modifiers".


Sorry, but I don't understand that. If no modifier is selected, why does it work differently?

"with these modifiers" that should actually mean "none". Apparently not. :wink:


My idea was, if I want to temporarily ignore selected modifiers without deleting them, I change the option.




...means "as long as no modifiers are pressed". So if you hold down the left ⌘ key and tap the right ⌘, your macro won't trigger.

"Ignoring modifiers" is exactly that -- your right ⌘ tap will trigger the macro regardless of whether any modifiers are down, allowing you to test for the modifiers later.

I think your problem was with your "If" -- while the USB Device Key trigger will treat left and right ⌘ keys differently, the condition won't. So ⌘ will always be pressed at that point:

Always True.kmmacros (5.3 KB)


You'll see the difference if you duplicate and rename that macro, keeping the trigger the same, so you get a Conflict Palette -- that'll give you time to get your finger off the ⌘ key before the condition is tested, so you can get the "False" dialog.

Thanks Nige, now I understand. But ... it's not really intuitive, is it?. :slightly_smiling_face:

You are triggering on the press or release of the Command Key. So if the trigger is configured as:


You are saying: Trigger when the Command Key is pressed when no modifiers are pressed. But that cannot happen - when the Command Key is pressed, the modifier Command is on.

It doesn't make sense.

If there was some sort of modifier setting that could say "when the Control, Shift, and Option key are not pressed and the Command key is ignored", that would be ideal, but there is no such setting.

As for whether it would work with :


or whether it works with “released” in either state, well, any of them might work or might not work, because the USB Device Key trigger detects the keystroke at a low level.

So maybe the Command modifier is not set when the Command key is detected being pressed. Or maybe it is. Same for released. It the modifier might be set as the key was before the event or after, it's literally an “edge condition”.

I'm not really sure why. If the trigger is set to “ignore modifiers”, then the trigger happens when the key is pressed. If the trigger is set to "with no modifiers", then the trigger happens when the key is pressed, if there are no modifiers currently pressed.

Normally this would be entirely unambiguous, except you're pressing a modifier exactly at that point, so whether a modifier is pressed or not depends on whether the system has noticed the modifier is pressed or not.

Thanks @peternlewis I understood that. I admit your argument is perfectly logical. And I have never claimed otherwise. But the solution is not intuitive. These are completely different categories. If I throw you a hand grenade, you will try to catch it. Is that logical? Of course not, but your reaction is intuitive. Sorry for the weird example, but that's how one should understand the difference.

This is not a criticism, and if I knew exactly how to solve it intuitively, I'd tell you. I'm just not sure you understood me as I understood you. :slightly_smiling_face:

Ask 1000 people who don't know KM, but know a bit about Macs and software. What do you understand when you see this?


Of course I can't prove it, but I'm pretty sure I know 90% of the answers.

"ignoring modifiers" is understood as "no modifiers".

"with these modifiers" is understood as, with the modifiers that are highlighted and without the modifiers that are not highlighted.

This understanding is reinforced by the fact that by changing the option (from "with" to "ignoring") the modifiers remain clicked, so to say in waiting position to be reactivated.

Now, what would I try in your place with your knowledge? Perhaps one approach lies in this consideration.

So that means I can choose a constellation that is a contradiction in itself and cannot be executed. I would look for a solution that does not allow this. I know, probably sounds easier than it is. You are the brain. :wink: :slightly_smiling_face:

It can be difficult to express a complex concept concisely in a UI label. But in this case Peter is correct and your 90% of people have misunderstood -- "ignoring" means "paying no attention to". The trigger quite literally ignores the state of all modifier keys.

A slight UI tweak which might help would be to increase vertical separation between the options -- as it is, the modifier key buttons do bleed into the line above a little, suggesting that "ignoring modifiers" can also have selections, eg "ignoring the ⌘ key".

That was my first thought when @Frankb said there was a problem -- but it seems that treating the right-⌘ as a Device Key Trigger prevents it from being considered a modifier to the trigger.

This works with right-⌘ only:

And this fails with right-⌘ only:

...but it does work when holding down left-⌘ and tapping right-⌘, showing that still respects modifiers.

Which is either really neat... Or really worrying, given the expansion in key combos that allows :wink:

Nige, of course Peter is correct. And so are you. But that's not the point. It can't be in Peter's interest to be correct, but 90% don't understand. That's a meaningless victory.

Anyway, I understand it now and I can apply it. :slightly_smiling_face: But after me there will be many who don't understand it either, the other 90 %. Then Peter will say, pleased with himself, how good that I was right. :wink:

I'm not sure I understand how that could be.

If that was the case, why would there be any radio button to allow you to choose? Why not just:

That would exactly the same as what you say people would take as “ignoring modifiers”.

I can't see how 90% of people are going to think selecting the first radio button is the same as selecting the other option, that's not how radio buttons work.

But regardless of that, clearly you were confused as to what the meaning was so what UI do you suggest as an alternative?

Sure, but this is only due to the fact that the keys selecting are modifier keys which Keyboard Maestro does not know. The whole point of the USB Device Key trigger is it detects low level USB Device key events. It can detect things like buttons on scanners, and monitors and mice and weird macro keyboards and such. But the key events have no meaning at that point, they are just messages. So there is no way for Keyboard Maestro to know that these specific keys are those responsible fr adjusting the modifiers.

Because, dear Peter, you are a friendly man who provides user-friendly software. And user-friendly software remembers settings of a user. So should a user have checked all modifiers earlier, like this


Then (without the second radio button) this user would have to click all modifiers one by one to delete them. But because the user is convinced, that you don't force him to do so much unnecessary work he believes that this constellation ...


... means "ignoring" the modifiers that are checked below.

I'll show you a example of another app. It is German, but you will understand it. This constellation ...


... means that something happens only if all modifiers are down. Now, if I want to switch off all modifiers for test purposes, should I click away them one by one? That would not be user-friendly. So what do I do? I change the menu above the modifiers.

This deactivates the modifiers, but they remain checked in case I want to reactivate them later.

Peter, it's all good. I'm just answering your questions from the perspective of an underperforming user.

I realize that especially in this case it is complicated to find a better solution because the trigger is also a modifier. And I don't know how to do it better either. :slightly_smiling_face:

The normal Mac solution to such a problem is to allow Option clicking a checkbox to toggle all the associated checkboxes.

Fair enough, if you do have an idea, I'm happy to hear it.