[Development] Pointer Handlers will be Tech Preview in 5.10

[André Somers]

Op 28/09/2017 om 13:42 schreef Tor Arne Vestbø:
> On 28/09/2017 13:36, J-P Nurmi wrote:
>> I would prefer attached properties and signals. Similarly to
>> Keys.onPressed. Attaching onTapped from the outside of a component
>> would be similar to overriding an event handler in C++. There would
>> be a single attached object instance with multiple signal handlers.
>> They objects would not be piling up like FooAreas and BarHandlers
>> do.
>
> Agreed! Gesture.onTapped, Gesture.onDrag, etc?
While on first thought I'd agree, it ends up being less flexible. It
would make it impossible to do things described in the top post, like
having a different action for a two finger pinch versus a three finger
one. So, in the end, I don't think attached properties would work here
unfortunately, as for the common case they'd be really elegant.

Unless it would be possible to do both, so you could use the attached
property for the common case but use separate, explicit handlers or
recognizers if you want to go funcky like the above?

With respect to naming, I also don't like the Hander, but I do like the
Recognizer names that Tor Arne  suggested a bit above. If the Gesture
part were to be dropped, I think they are still clear and yet not overly
long, especially if they would only be needed for more control than
you'd get via a common attached property. So, TapRecognizer,
DragRecognizer, PinchRecognizer, etc.

@Shawn:
I do have a doubt left on the choice to make these objects rather than
items though. What we sometimes end up doing is make mouse areas for
button-like objects larger than the actual button, to create a bigger
hittarget for it. That works quite well. I don't see how that would be
done here. Reversely, there are uses for multiple 'areas' within a
single item, and again I don't see how to do that other than instantiate
a separate parent item again, but then you end up with both a QObject
_and_ a QQmlItem instance instead of just the latter. I'm not sure the
hassle is worth the savings you make here by instantiating a QObject
instead of a QQmlItem, more so because you also loose the attached
property onCompleted.

André