As an example, let's say I have this action selected in the KM Editor:
Is there any way to insert text into the "With Parameter" field without using the mouse? In a lot of apps, ⇥ and ⇧⇥ will move the focus between different elements, but that's not the case here.
Interesting. I'm able to tab to the field and enter the text.
My process:
Click the add Execute Macro button (Stream Deck)
Press the tab 3 times...
Edited:
Ahhh --
The above is only if I added it without any other action present.
If there is another action, above it, and then I add the Execute a Macro action, it's a little more unpredictable...
-- Edited again...
But what you can do....
... is can create a keyboard shortcut, within System Preferences (Keyboard), for Keyboard Maestro.
That should get you there upon addition of the action.
See if this works for you.
KC
Thanks for taking the time. I'm not sure I understand what you're doing here. In the system Keyboard prefs, I don't see an entry for Keyboard Maestro.
I'd rather do this all within Keyboard Maestro, and I'm hoping @Zabobon might be able to throw me a cheeky script which would create the action and set the parameter value from a variable, as I know he's a dab hand with scripting KM action creation. (No pressure though, obviously! 
)
You will have to add it. Go to System Preferences, Keyboard and Shortcuts. There you can add shortcuts to any application. You use the menu item and yes, it works within Keyboard Maestro. Just take a look and try it, you will see. You won’t need a script to do this, just pick a hotkey within the Process above. I leave for Hawaii in a few hours so I can’t show you a video right now. You will figure it out.
Thanks for this workaround!
I was confused for a second as the menu item doesn't exist until the action is selected. There's actually no need to use the system keyboard prefs for this, as it can be done within KM like so:
There are two instances of the Select Menu Item action in order to toggle With Parameter off and on, thereby placing the text cursor in the field.
@peternlewis Does the Editor have a more general keyboard navigation method (similar to using ⇥), or is this the best way of doing things? I'm always trying to do less with the mouse because of my RSI.
Tab works, but not in an entirely intuitive way.
Normally when you create an action, Keyboard Maestro will put the text focus in to the first text field in the action. For example, if you create a Select Menu Item action, it will automatically put you in to the Menu Title field.
But the Execute Macro action is a bit odd in that the Parameter field, when not enabled does not show up at all - except when you first create the macro:
So for the Execute Macro action, when you create it, I forgot to set the desired first field to the parameter when it exists. I'll fix that, and so when you create the action it will be selected.
As far as going from the selected action afterwards, that is what the View ➤ Enter Action menu command does. If you try it on the Select Menu Item action for example, it selects the Menu Title field. Once the fix above is done, it would work on this action as well.
Sorry for the hijack - but Peter can you also do something similar for the Execute Subroutine action so that the cursor is left in the first field (if it exists)?
Yes, there was a mistake in that code too. Fixed for the next version.
Overview
[Apologies for the length of this post. I hope that the hours I spent drafting it make the minutes it will take to read worthwhile. 
-CL]
Having arrived on this thread with the same general question as the O.P., I find myself still wondering exactly what the intended behaviors are for navigating Keyboard Maestro's macro editor with the keyboard. It seems like it might be worth considering a design sprint specifically dedicated to this issue, rather than playing whack-a-mole.
For what it's worth, here are all the issues I can think of that make keyboard navigation super challenging in Keyboard Maestro:
Issues with current design
No unified documentation to describe how to navigate without the mouse. Or, if it exists, I haven't been able to find it.
Actions seem to have two types of selection state: blue border, and thick gray border. Again, I haven't managed to find any documentation on this. Seems like a sub-topic of Editor Window…?
Individual navigation commands behave in inconsistent ways. For instance, If I have a Group action selected, then ⌃⌘▶️ (the keyboard shortcut that triggers Actions ➤ Enter Action) selects the top action within the Group. If I then press ⌃⌘▶️ again (now Actions ➤ Enter Action is disabled in the Actions menu), the selected action pops to the bottom of the group. At worst, the shortcut should be a no op. At best, it should select the next action in the group.
Current focus seems to be a fractured concept in the editor. For instance, with this selection…
Certain navigation attempts land one in a ditch. For instance, pressing Tab to navigate through sub-elements of an action works great until you encounter a text field, at which point pressing Tab just enters tab characters into the field, at which point ⇧Tab can't get you out!
There seem to be too many navigation metaphors at play, which makes it hard to remember how to use them. For example, I'm sure the following is possible, but figuring out how to do it seems to require far too much research!
|:arrow_backward: / 
|:arrow_forward:|:arrow_backward: / |:arrow_forward: / [overloaded] or Tab [nb. this quickly lands one in the ditch if a hot key trigger is visible, and if you hit the end of navigation, it's not a no-op, it just deselects everything!]
! [requires user config]
[overloaded]I'd like to suggest that this can be made much simpler using a few simple design heuristics in combination with just three of what I've been calling metaphors: Containers, Lists, and Navigation Traps.
Specific suggestions
I don't know whether this kind of analysis is welcome, or viewed as an intrusion, @peternlewis, but with the utmost respect, appreciation, and, frankly, awe! for your creation, I humbly offer this spec as a stake in the ground for a simplified navigation UX:
All navigation is well-documented in both the Manual and by virtue of commands being explicitly listed in a menu, a la Actions ➤ Enter Action
The selected focus is clear at all times, with all navigation commands "rooted" at the current selection. I.e., there exists one and only one selection, and all navigation commands generate a consistent response regardless of whether that's currently in the Groups list, the Macros list, on an action, or on some sub-element of an action (chevron, corner menu, form field, etc.)
No ditches to fall into!
Paired directional commands are idempotent. E.g., if I can navigate back and forth using Tab/⇧Tab, each command only has two possible behaviors: select next/previous, or no-op
/ to navigate in- and out of any containers:
/ navigate up and down within lists
Return to enter navigation traps
Esc to exit navigation traps
⌘🔽 / ⌘🔼 to jump to the bottom/top of the current container [as is]
⇧⌘🔽 / ⇧⌘🔼 to select to the bottom/top of the current container [as is]
⌃⌘🔽 / ⌃⌘🔼 to move selected action to bottom/top of the current container [as is]
Doubling down on appreciation
Keyboard Maestro does so much in such a tight space that there's a certain level of irreducible complexity. It seems unlikely that I've managed to resolve every keyboard navigation challenge that has come up over the years, and chances are that the above suggestions have drawbacks that I've failed to notice.
Still, I hope that this experience report and rough spec demonstrate that there's room for vastly improving the usability of keyboard navigation in Keyboard Maestro without trading off anything except backwards compatibility in the muscle memory of Keyboard Maestro users who have fully adapted their brains to the current system. My hypothesis is that such users will easily be able to rewire—perhaps even happily!—in the face of a carefully-conceived update.
Regardless, it's worth saying again how much I appreciate the years of work that it's taken to get Keyboard Maestro to where it is, and I present the above with deep humility.
Thanks for your time!
Keyboard Maestro, being a Mac program, is always designed as mouse first.
This is fairly standard Mac “has keyboard focus” and “selected but does not have keyboard focus”
For example, if I am editing this in Safari and select some text, it appears as:
If I switch to another window with it still selected, I see:
This behaviour is because Command-Control-Right Arrow is a synonym for Command-Control-Down Arrow in a list, which moves to the end of the list.
It is also the menu command key for Enter Action.
The latter takes precedence if the menu item is enabled. If it is not enabled, the key flows on to the list and performs its "move selection to the last item in the list" behaviour.
The former behaviour predates the introduction of the Enter Action menu and its command key. I suppose I could disable the synonym behaviour, but that seems a little pointless for this edge case.
Tab moves to the next selectable field, typically the next text field. So from Paste being selected and having keyboard focus, Tab will take you to the next text field, which is no where in your images.
If you have the System Setting for Full Keyboard Access, then Tab will behave very differently to normal.
I'm not sure what you expect it to do, but it wont take you to the next action.
Yes, that's what happens with Tab on the Mac. Similar behaviour to Scroll Wheel which will scroll a window until you get over a scroll field and then start scrolling the the scroll area.
It's perfectly welcome, but in this case unlikely to be actionable in general. The Mac has a zillion already defined behaviours and I am not inclined to fight the system or contradict the behaviours.
This is impractical. There are dozens of arrow key combinations that all mean things, and they are implemented by the selected items in ways that do not interoperate particularly well with menus (as seen above), and that are implemented by the system for some controls and thus cannot be done via menus in the same way.
What is not clear? The selected text focus is blue. Other selections without text focus are grey. You can see this same behaviour everywhere across the Mac, eg the Finder column view.
I'm afraid that doesn't even make sense.
If a text field in an Insert Text action has keyboard focus, the it is blue. And it's parent action is selected, and its macro is selected and it’s macro group is selected.
If the macro was not selected, the action would not be visible. Same for the Macro Group.
Selection matters as much as keyboard focus.
Within reason, I would say they do. If there are specific instances where they don't, feel free to note them. But note that the Tab key behaviour, with Full Keyboard Access, is not going to work in any reasonable way, it taps through controls that are not really designed to be tabbed through, it certainly is not a setting I test. So if you are expected any specific behaviour of the Tab key under Full Keyboard Access you are likely to be disappointed, and I probably am not going to prioritise adjusting the behaviour (if I even could).
Unfortunately, that would go against established Mac behaviour.
Select the action and use arrow keys if that is what you want to do - Tab does not behave like you expect.
If you tab in to a text field, then further Tabs will insert Tab characters, and Shift-Tab does nothing in a text field.
I think at this point I have to stop because it seems clear you are operating with Full Keyboard Access, and that's not really something that is practical to support. Most things you describe (eg Triggers) cannot be selected at all, there is no concept of a selected trigger. And I'm afraid it would be far far too much work to try to make all of that work as you describe for the tiny percentage of users that use Full Keyboard Access. I'm all for accessibility, and I do my best to enable it, but I can't spend the time on this that would be required to get anywhere close to what you describe.
On top of that, many of the things you describe go against existing behaviour, either on the Mac as a whole, or in Keyboard Maestro over the last decade. I wont go against Mac behaviour and I'm loath to change Keyboard Maestro behaviour except in cases where there is a clear and obvious benefit.
I appreciate the time you've taken, and I'm sorry I don't have a more useful response to offer.
Have you tried ⌃⇥ (next) and ⌃⇧⇥ (previous)? Those would be the usual "tab out of a text box that accepts tab characters" keystrokes.
It may be my imagination, but has ⇥ behaviour changed in the latest version?
I have a macro that restores an image path to an image (in the image well), and it was working fine until recently. It uses ⇧⇥ to switch focus from the image path field to the source dropdown, and that no longer seems to work.
Hi @noisneil ⇧⇥ still works that way for me.
I suspect somehow Keyboard Navigation has got turned off in System Preferences/Settings
Nope...
⇥ takes me to the Search field
⇧⇥ takes me to the Y-axis coordinates field
⇧⇥ used to take me to the "File" dropdown, and I know this to be true because the macro used to work and I haven't edited it.
This is the way ⇥ and ⇧⇥ work for me in Keyboard Maestro(10.2)
Well, despite what the setting shows your system is exhibiting the "normal" macOS behavior – i.e. without "Change the way tab moves focus".
Weird. I wonder why it's skipping the drop-down for me..?
That did it! Thanks Chris!
