[Qt-components] Key navigation

Alan Alpert 416365416c at gmail.com
Mon Jan 28 20:27:57 CET 2013


On Mon, Jan 28, 2013 at 4:48 AM, Qi Liang <Liang.Qi at digia.com> wrote:
> On Tue, Jan 8, 2013 at 4:52 PM, Alan Alpert wrote:
>> Correct. And with components it seems better to make it a FocusScope.
>
> But I heard that some of quick items just set the flag and not inherit from FocusScope, then it's not good only make it in a FocusScope.

Not necessarily. The point was that most components need to have a
focus scope as their root element. So you can still make it work for
components just fine. Even for components centered around an Item
which is a non-FocusScope focus scope, you can still wrap it in a
FocusScope for this (like TableView does anyways). We only need to be
able to make it work for any group of items, not to have it
automatically work for all Items.

If it's in any focus scope, not just a FocusScope, there's a higher
burden for documentation and examples because this is going to be more
confusing (we usually try not to talk about implicit focus scopes
because it's usually a confusing distinction and things 'just work'
anyways).

>
> I am trying to copy the focus concepts from widget world, with some help from Jan-Arve,
> https://codereview.qt-project.org/44968 - Patch Set 4
>
> Reference about Qt::FocusPolicy: http://qt-project.org/doc/qt-5.0/qtcore/qt.html#FocusPolicy-enum
>
> At least the Tab and BackTab could work now, and has more priority than old KeyNavigation and Keys attached property. We could fix that later.

This needs to integrate with KeyNavigation. It basically is automatic
KeyNavigation, and should be overridden by any explicit Tab/BackTab
key navigation. If it isn't overriden by the existing key handling, it
has a much more serious chance of breaking existing applications
(should it be on by default).

>
> Talked with Jens today, maybe we should be better to be compatible with old focus behaviors. I think all children items under FocusScope, and all has "focus:true" and "focus:false" should be considered want to have focus(at least TabFocus). Alan, could you correct this?

We could have it work like this. We can't have the exact same focus
policy as widgets because mouse handling is separated out, but we can
have TabFocus behaviour on, possibly even by default if explicit focus
has been set. Note that you'd need a reset function if explicit focus
toggles this behavior (focus = undefined would trigger it).

If we're trying to match widgets, we'd probably want a tab order
property as well. I'm thinking of, on KeyNavigation, a tabOrder
property or navigationOrder property if we want to extend it to giving
easier keypad navigation. Automatic tab focus switching is only half
done without that.

>
> And how about Qt::ClickFocus, I haven't touch anything about it, do you have something in your mind? I guess the items with MouseArea should be considered in.

Does not apply. Mouse handling is separated out of Item so it has to
work on a separate level. But because key handling is in attached
objects on every Item (the base class) we can have keyboard focus kind
of like widgets (and already do). Although it is more versatile,
because you can manually control focus instead of setting a focus
policy and gaining focus only in widget supported ways.

Desktop components could ClickFocus if they wanted, controlling
default mouse areas on all the components. But we don't want to mix
key and touch handling in QtQuick, because it needs to be a lean and
versatile set of primitives for platforms which do not necessarily
have both input methods.

>
> BTW, and looks like this change only happens in qtdeclarative, should we also mention it in development mailing list?

Only if you think it would benefit from the wider audience. We have
enough QML and Widgets people on this ML for an informed decision
already.

--
Alan Alpert



More information about the Qt-components mailing list