| Summary: | Kirigami.Action doesn't honor KeyNavigation.tab | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | Albert Vaca Cintora <albertvaka> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | aleixpol, notmart |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | Not decided | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Kirigami.Actions as buttons | ||
|
Description
Albert Vaca Cintora
2024-04-05 10:56:28 UTC
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.
|