Floating Menu - Keyboard Navigation

Is it possible to make a floating menu 'keyboard navigateable'?

Eg. I have a vertically stacked floating menu, and when I hover over the menu items with the mouse they will highlight, and trigger when I click on them:

But I'm wondering if it is also possible to use the arrow keys to navigate up/down through the menu items, and then something like the enter key to trigger the currently selected item. This would allow floating menus to work similar to normal menus as far as keyboard navigation goes.

I did find this similar post, which suggests using a conditional activation group; though that feels a bit 'heavy weight' and 'disconnected' from the main floating menu config to enable something like this:

Which seems to also be the method described in this similar post:

"Arrow navigation" is planned for the next release. (also some other standard navigation methods like tabbing through items)

Via conditional activation groups you can set shortcuts for specific items, but cycling through them with the arrow keys or similar is not yet possible.

The main problem is that usually floating menus are not actively receiving keyboard input, thus this will only work if the menu has explicitly received keyboard focus (e.g. when showing the menu via predefined action and checking the keyboard focus option).

1 Like

Ah true, awesome!

So given this setup, theoretically it should have the keyboard focus already:

Which I can see sets the following when hovered:

image

And these when not hovered:

image

So presumably that would 'just work' in the conditional activation group setup if I wanted to do that. As a basic test, I created a Keyboard shortcut in the conditional activation group for the enter key, which has the Trigger Hovered Menu Item And Hide Floating Menu action set on it; which seems to work fine:

As you suggested though, I didn't see any way that I could hack a workaround for arrow keys in the current version. I thought I might be able to use Activate Simulated Hover For Floating Menu + some variable scripting or similar, but that doesn't have any options for setting/getting the currently hovered menu item seemingly.

In any case, happy to wait till the next version for the official support :slight_smile:

Starting with v4.636, BTT adds basic keyboard navigation to floating menus when shown via the "show / hide floating menu" action and the "keyboard focus" option enabled.
It should be possible to tab through items or use arrow keys, however the arrow keys will just be able to follow the direction of the flow (up/down)

Triggering the selected item is done by pressing enter.

Selected items use the same effect as when hovered.

Would be great if you could check whether this works for you

1 Like

I'm on BTT 4.637 and ventura 13.6.7

I can move left and right with arrow keys but nothing happens when I press Enter.

unfortunately apple added this to swiftui only starting with macos 14 ;-(

it’s sad that apple never backports these swiftui impovements to older macos versions

Just upgraded to 4.638 on macOS Sonoma 14.5 (23F79); I'm using Toggle Floating Menu Hidden/Shown with Activate Keyboard Focus When Showing enabled, triggered from a Key Sequence; and it seems as though the basic arrow key + forward tab navigation works as expected :tada:

Some things that don't work as expected:

  • shift+tab doesn't navigate backwards
  • pressing enter does trigger the menu option, but I have Close After Button Press enabled on the Floating Menu, and so I was surprised when pressing enter didn't also close the menu
    • Not sure if this should be a new setting for enter, or just reuse the one for click (probably reuse is fine, since both are buttons whether it's a mouse button or keyboard button?); but ideally it would allow me to configure it to close when I press enter as well.
  • Pressing esc doesn't close out of the floating menu
    • Not sure if this should be a default, or an option, or just something I have to go and configure a new separate keybinding for myself. I think maybe an option, as some people might not want that behaviour? But then I guess the same could theoretically be said about the keyboard navigation, so maybe it's fine since it's a fairly standard thing.

Edit: Afterthought.. not sure if this happened before I updated as well and I just never noticed it; but it looks as though my menu 'slides in from the top of the screen' now, rather than just appearing (and the animation of it feels kind of 'laggy'/'jumpy'. I can raise a separate bug report for this if needed, but just wanted to confirm it wasn't always doing that before I did.

good points, starting with 4.639:

  • shift + tab should work
  • enter should hide the menu if the option is selected
  • esc should close the menu

BTT doesn't have any sliding animations by default, do you have the "resize on hover" option enabled for that menu? I just checked with all of mine but they behave as before, just showing up without animation.

I think having esc and keyboard navigation by default is fine, because this only works if the "keyboard focus" option is checked in the show/hide action

1 Like

Can confirm that these all work as expected now, thanks! :black_heart:

nods, yeah, that makes sense. Sounds good :slight_smile:

I don't have resize on hover enabled.

Though I did have another thought: this menu is on iTerm2, and specifically I am using the 'hot key' version of iTerm2 that slides in from the top of the screen. So it looks like the menu may also be inheriting this animation somehow? When I trigger the Floating Menu, iTerm2 is already visible on screen, so I wouldn't have expected that it should also need to scroll in.