[Qt-components] Key navigation

Alan Alpert 416365416c at gmail.com
Mon Jan 7 20:41:19 CET 2013


On Mon, Jan 7, 2013 at 10:42 AM, Alberto Mardegan
<mardy at users.sourceforge.net> wrote:
> On 01/07/2013 06:23 PM, Bache-Wiig Jens wrote:
>> It is not realistic to assume that the majority of controls will be placed inside these optional layouts. At least not to rely on them for all things regarding keyboard navigation. You are likely also using a mix of Row, Column, Grid or just plain old anchoring. What if we just assign a default key navigation chain based on the declared order of items (which is what widgets do by default I believe)  and special case the tabbing through layouts to allow RTL/LTR behaviour specifically for them.
>>
>> At the moment I think tabbing into and out of FocusScopes are a bit broken. See this for instance: https://bugreports.qt-project.org/browse/QTCOMPONENTS-1266
>>
>> I think Liang is interested in researching improved key navigation for 5.1 after we have a basic test framework in place for components.
>
> Another issue is that QQuickItem::setFocus() only accepts a boolean
> parameter and not a Qt::FocusReason; if we want to do without a
> FocusChain object and we want to integrate the focus chain functionality
> directly into FocusScope, then having the information on how the focus
> was obtained is important: so, when a FocusScope receives focus, the
> child item to be focused should be:
>
> - the child item currently holding the focus (within the scope), if no
> reason is given
> - the "first" item inside the FocusScope, if the reason was "TAB"
> - the "last" item inside the FocusScope, if the reason was "BACKTAB"

If these are the only reasons then we don't have to modify the QML
API. We can just add another setFocus to FocusScope with the extra
argument. Although then it would only work with KeyNavigation, because
only the KeyNavigation implementation would be able to access it.

But I just had a look at Qt::FocusReason and there are 8 different
reasons there. Unless most of them were added in error, we may end up
adding an optional Qt::FocusReason argument to QQuickItem::setFocus().

> I think we should also discuss whether it makes sense to add a CanFocus
> flag to QQuickItem itself.

The current approach basically has that with FocusScopes. If you have
a component which can do something with Keyboard focus, it has a
FocusScope around it.

Now FocusScopes aren't that great, so maybe there's a better way, but
given the current keyboard handling in QML where would you add
CanFocus where there isn't already a FocusScope (or a root level Item
that could easily be turned into a FocusScope)?

--
Alan Alpert



More information about the Qt-components mailing list