[Qt-components] Key navigation

Alan Alpert 416365416c at gmail.com
Tue Jan 29 19:51:11 CET 2013


On Mon, Jan 28, 2013 at 9:27 PM, Alberto Mardegan
<mardy at users.sourceforge.net> wrote:
> On 01/28/2013 04:48 PM, Qi Liang wrote:
>>
>> 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?
>
>
> This seems reasonable, though (as someone pointed out in some earlier
> conversation) assigning more than a meaning to a property is generally bad.
> I would rather add an explicit "canFocus" property, which simply toggles the
> isFocusScope flag on the item (or a new flag, but I think that isFocusScope
> is exactly what we need here, despite the strange name).

We're entering confusing territory here, as any Item can be focused
with focus: true, so "canFocus" is a bad name. focusScope is even
worse, even if we implement it as setting isFocusScope, because that's
even more confusing to users (there's a reason we make FocusScope a
separate item!).

If we want to avoid mixing up meanings, we shouldn't be placing this
on the Item at all. There should be a separate attached property like
KeyNavigation.inFocusChain for this specific feature of focus chains
to split it out. If we're looking at making all "focusable" items
automatically enter a focus chain, I think that explicit focus is the
current best definition of focusable and thus what we need to use.

> Since the main use case of keyboard navigation is when using (desktop)
> components, I think that having to specify an additional "canFocus" property
> in order for your widget to be part of the focus chain is not a big issue;
> and all the default components could have this flag set by default, so in
> most cases the user wouldn't need to care about it at all.

If we're just focusing on the desktop components, I'm starting to like
your initial FocusChain{} item more. You can even get the convenient
syntax just by having your own Item subclass for key-handling - have
you considered that? The component set, for a keyboard enabled
platform, could have a "FocusScope subclass" like KeyContainer which
handles key navigation with a FocusChain attached property. It's a
similar approach to adding more functionality to KeyNavigation, except
that since it's on the component set level you can do whatever you
want without worrying about backwards compatibility.

--
Alan Alpert



More information about the Qt-components mailing list