Context: I'm trying to fix the fact that pressing "tab" in the KDE Connect app walks the buttons backwards. I originally reported this in https://bugs.kde.org/show_bug.cgi?id=482752 but was told that this should be fixed per-app and not in Kirigami. I found that Qt supports KeyNavigation.tab [1] to indicate, for each element, which is the next element to be selected when tab is pressed, together with KeyNavigation.right and KeyNavigation.left for the arrow keys. Although I still think that tab navigation should work out of the box, KeyNavigation seemed like a way to (with a bit of hardcoding) fix it for KDE Connect at least. However, when I tried it, I found that KeyNavigation.tab makes no difference when I use it in a Kirigami.Action. Does Kirigami.Action not support KeyNavigation.tab? [1] https://doc.qt.io/qt-6.5/qml-qtquick-keynavigation.html#tab-attached-prop
Kirigami.Action (based on QtQuick.Control/Action) is an abstract non-graphical type, it can't have key navigation, it doesn't support it, nor would it make any sense. A single Action object can be bound to multiple UI controls, for example.
Created attachment 168294 [details] Kirigami.Actions as buttons Fair enough. I still need a way to fix tab navigation, though. In KDE Connect we have 3 Kirigami.Action [1] that end up as buttons on the top bar (see screenshot). Tab navigation circles through them backwards. How do I fix that? [1] https://invent.kde.org/network/kdeconnect-kde/-/blob/master/app/qml/DevicePage.qml?ref_type=heads#L20-49
Reopening because in practice Kirigami.Actions do result in buttons and those need a way to be navigated with the keyboard. See my previous comment.
Aren't these buttons on a toolbar? If so, the toolbar itself should process the tab sequence. Can you provide a higher level explanation of what the problem is from a KDE Connect perspective? The screenshot of the full app instead of the components themselves will be useful.
I linked the code. They are in another Kirigami component, a `Kirigami.ScrollablePage`: https://invent.kde.org/network/kdeconnect-kde/-/blob/master/app/qml/DevicePage.qml?ref_type=heads#L20-49
High-level issue is that if you try to navigate the app using your keyboard instead of the mouse, it's impossible: tab doesn't circle through all the buttons (it only does within the area you have selected, and in a somewhat unpredictable order) and right/left arrows don't do anything.
> High-level issue is that if you try to navigate the app using your keyboard instead of the mouse, it's impossible: tab doesn't circle through all the buttons (it only does within the area you have selected, and in a somewhat unpredictable order) and right/left arrows don't do anything. That's fair. The keyboard navigation story is far from being perfect in QtQuick. All we have at the moment is tab/backtab/up/down/left/right targets, which as you could imagine isn't very composable between independent containers of controls. We don't have a concept of dig in / pop out, like Enter/Escape works in video games (A/B buttons on Nintendo platforms), but we should. It is a broad upstream topic that the keyboard navigation API should be expanded to address all those use-cases.
I'm not sure what you mean. I find these are working. The work a bit weird, in that they navigate right-to-left, this could maybe be a bug but tab navigation works. Also I see that the focus is not very well displayed. Is that what you mean? How did you test it?
It does happen to me. If I open kdeconnect-app, I can only navigate through the main pane ("Device") on the right. There's no key that moves the focus to the left pane. Furthermore, if I press 'space' to select one device from the list, the focus is lost and there's no way to continue navigating with the keyboard whatsoever.