tabIndexDirection: directional focus navigation - #933
Conversation
|
From discussion with @MichaelBelousov one usecase is a floatingMenu that has a bunch of expanders that each inside have a flexbox with some differently-sized widgets. Need a way to navigate everything by arrow keys directionally. |
This supports a floating menu that works like a popup, where the arrow keys will move focus like in a normal window, but escape still closes it.
Act like the focus is coming into the window from outside in the given direction.
This was only used by SuggestionWidget, and is replaced by checking if any menuItem has .submenu = true. This makes floatingMenu more usable in a popup scenario where there might not be any menuItems at all.
This makes floatingMenu more usable as a popup. When .from == null it will center itself on the screen/subwindow the same way a new floatingWindow does. Also remove dvui.minSize - it was only used by 2 widgets and both were old and not taking into account max_size_content.
No practical difference but guards against the case where max_size_content is smaller than min_size_content. In that case max_size_content wins, so this helps make that more obvious.
When .style == .popup: * floatingMenu will be modal * any click outside the popup will close it * escape closes it * internal menu processes arrow keys like a normal window
|
@MichaelBelousov I think this is ready for merging. It also includes a bunch of stuff to make Can you try in this branch to use the demo > Layout > Directional Navigation > Popup and let me know if that is what you were thinking? |
Will do later today! |
|
Superb work! Works intuitively and meets all criteria I was hoping to have! The only thing I'd wonder is, and it's not even super relevant for me, is it trivial to customize the exact target for a given cardinal (left/right/up/down/next(tab)/prev(shift-tab)) direction? One thing I found possibly unintuitive (although correct for my use case) was the four direction buttons (up/down/left/right) where settling on So of course that is a different strategy which I think is more akin to maybe games, but I think could be solved with precise tab index control. So as long as that's easy, I think it works great. Let me know if you have questions about that but I think this is a great feature, good default, and perfect for my case! Thank you! |
Awesome thank you!
I agree. My plan here is to wait for someone to be using it that kind of context and explore the options then. I suspect it will involve both some tweaking/customization to the algorithm plus some way to directly control edge cases. Anyone reading this - if you are in this situation please file an issue! |
2 participants
fixes #857
The strategy is (edited):
I've added up/down/left/right key handling by default to do this. But I ran into some issues that I'm unsure about:
Scroll areas already use up/down/left/right to scroll. I modified it slightly so ScrollContainer ignores up/down/left/right if no scrolling is possible (all content fits in the viewport).
Focus Groups also use up/down/left/right for focus movement. I modified it to use tabIndexDirection if
nav_key_diris null. But you still can't escape a focus group via this.We'll probably need to get more real usage experience to know how to proceed.