Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[J-P Nurmi]

> On 28 Sep 2017, at 16:54, Shawn Rutledge  wrote:
> 
> 
>> On 28 Sep 2017, at 13:36, J-P Nurmi  wrote:
>> 
>>> On 28 Sep 2017, at 13:07, Tor Arne Vestbø  wrote:
>>> 
>>> On 28/09/2017 13:05, Tor Arne Vestbø wrote:
 If we can't have a generic GestureRecognizer type with dynamic recognizer 
 behavior based on which handler callback is bound, then it should be 
 TapGestureRecognizer, DragGestureRecognizer, etc.
>>> 
>>> Or if we want to follow the existing naming of MouseArea and TouchArea, 
>>> perhaps GestureArea, with TapGestureArea, DragGestureArea, etc
>> 
>> 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.
> 
> We’ve had that discussion a couple of times already, so I’ll start by 
> repeating what I said then (more or less).  (I did like the idea to begin 
> with, until I saw the problem with it.)
> 
> If the only way is to use attached objects, it would mean one Item can’t have 
> two instances of the same attached object (as André also pointed out).  If 
> you declare discrete handlers though, then you can declare event-filtering 
> conditions too: this handler reacts only to right mouse button, this one 
> reacts only to left button while Control is held down (and does something 
> completely different), this one reacts only if the device is a touchscreen, 
> etc.  Being able to have multiple instances per Item gives you more degrees 
> of freedom.  If you limit yourself to a single Javascript callback per Item, 
> then you are forced to write more logic (testing various conditions and 
> deciding what to do about them) in Javascript.
> 
> And in fact, Keys.onPressed has exactly that problem, too: if your use case 
> is any more complex than just passing text input to some other 
> slot/invokable, your JS is probably messy.  Shortcuts are much nicer to 
> detect single key combinations, in that you can declare a separate instance 
> for each command which needs a shortcut, instead of needing a big switch (and 
> also worrying about which item has focus, but that’s a different problem).  
> Now you can say, well there are also a lot more signals like 
> Keys.onEnterPressed, and so on; but not all of the keys of the keyboard are 
> there.  (Why not?)  And again, onAPressed (let’s say you want to detect 
> control-A) wouldn’t be a one-liner anyway, even if the signal existed.
> 
> Syntactically I think the handler use cases so far are looking OK.  Sometimes 
> the declaration is a one-liner; and when it’s not, at least it’s more 
> declarative than the equivalent attached-object-javascript would be.  (Look 
> in tests/manual/pointer)
> 
> But I think attached objects could be a supplemental way of using handlers or 
> modifying existing handlers’ behavior, somehow.  I’ve got a little prototype 
> of one variety of that, but it doesn’t do much yet.  I was thinking it would 
> be an aggregator, able to find and expose all the handler instances within 
> one Item and its children, so that you can manipulate them outside the 
> context of their declaration; and that it would also aggregate common state 
> like pressed and hovered, and tell you which of those handlers is active.
> 
> Can we do that and also go to the next step of using the attached property on 
> its own?  That seems harder, without duplicating code.  Maybe it would have 
> to create the appropriate handler for you.  But Controls 2 has a related 
> problem: how to reuse logic from Handlers without needing to make instances.  
> Controls 2 has the policy of creating as few objects as possible, to save 
> memory and improve the startup time.  I just have a vague idea of putting the 
> logic into static methods or some such, but haven’t really tried to think 
> about specific API for that.  It’s hard to do without instances, because each 
> handler needs to remember some state.  And if this was a C framework, that 
> would be _your_ problem: hold onto a struct which holds the state, and pass 
> that into each function which you need to use.  Maybe we could do something 
> similar.  Before we can offer public C++ API, we need to make PIMPLs anyway; 
> so we can try to make the private classes usable on their own, so that 
> Controls can use them.  But that’s just a vague idea.
> 
> Another thing we could try is to have some sort of global object per device, 
> so you can query or bind to the mouse position and button state, and track 
> all the touchpoints, without depending on event propagation to Items within 
> the scene.  This is an easy starting point for young frameworks, but we don’t 
> have it in QtQuick for some reason.  For example, at some point Qt 3D didn’t 
> have 

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[Shawn Rutledge]

> On 28 Sep 2017, at 13:36, J-P Nurmi  wrote:
> 
>> On 28 Sep 2017, at 13:07, Tor Arne Vestbø  wrote:
>> 
>> On 28/09/2017 13:05, Tor Arne Vestbø wrote:
>>> If we can't have a generic GestureRecognizer type with dynamic recognizer 
>>> behavior based on which handler callback is bound, then it should be 
>>> TapGestureRecognizer, DragGestureRecognizer, etc.
>> 
>> Or if we want to follow the existing naming of MouseArea and TouchArea, 
>> perhaps GestureArea, with TapGestureArea, DragGestureArea, etc
> 
> 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.

We’ve had that discussion a couple of times already, so I’ll start by repeating 
what I said then (more or less).  (I did like the idea to begin with, until I 
saw the problem with it.)

If the only way is to use attached objects, it would mean one Item can’t have 
two instances of the same attached object (as André also pointed out).  If you 
declare discrete handlers though, then you can declare event-filtering 
conditions too: this handler reacts only to right mouse button, this one reacts 
only to left button while Control is held down (and does something completely 
different), this one reacts only if the device is a touchscreen, etc.  Being 
able to have multiple instances per Item gives you more degrees of freedom.  If 
you limit yourself to a single Javascript callback per Item, then you are 
forced to write more logic (testing various conditions and deciding what to do 
about them) in Javascript.

And in fact, Keys.onPressed has exactly that problem, too: if your use case is 
any more complex than just passing text input to some other slot/invokable, 
your JS is probably messy.  Shortcuts are much nicer to detect single key 
combinations, in that you can declare a separate instance for each command 
which needs a shortcut, instead of needing a big switch (and also worrying 
about which item has focus, but that’s a different problem).  Now you can say, 
well there are also a lot more signals like Keys.onEnterPressed, and so on; but 
not all of the keys of the keyboard are there.  (Why not?)  And again, 
onAPressed (let’s say you want to detect control-A) wouldn’t be a one-liner 
anyway, even if the signal existed.

Syntactically I think the handler use cases so far are looking OK.  Sometimes 
the declaration is a one-liner; and when it’s not, at least it’s more 
declarative than the equivalent attached-object-javascript would be.  (Look in 
tests/manual/pointer)

But I think attached objects could be a supplemental way of using handlers or 
modifying existing handlers’ behavior, somehow.  I’ve got a little prototype of 
one variety of that, but it doesn’t do much yet.  I was thinking it would be an 
aggregator, able to find and expose all the handler instances within one Item 
and its children, so that you can manipulate them outside the context of their 
declaration; and that it would also aggregate common state like pressed and 
hovered, and tell you which of those handlers is active.

Can we do that and also go to the next step of using the attached property on 
its own?  That seems harder, without duplicating code.  Maybe it would have to 
create the appropriate handler for you.  But Controls 2 has a related problem: 
how to reuse logic from Handlers without needing to make instances.  Controls 2 
has the policy of creating as few objects as possible, to save memory and 
improve the startup time.  I just have a vague idea of putting the logic into 
static methods or some such, but haven’t really tried to think about specific 
API for that.  It’s hard to do without instances, because each handler needs to 
remember some state.  And if this was a C framework, that would be _your_ 
problem: hold onto a struct which holds the state, and pass that into each 
function which you need to use.  Maybe we could do something similar.  Before 
we can offer public C++ API, we need to make PIMPLs anyway; so we can try to 
make the private classes usable on their own, so that Controls can use them.  
But that’s just a vague idea.

Another thing we could try is to have some sort of global object per device, so 
you can query or bind to the mouse position and button state, and track all the 
touchpoints, without depending on event propagation to Items within the scene.  
This is an easy starting point for young frameworks, but we don’t have it in 
QtQuick for some reason.  For example, at some point Qt 3D didn’t have any 
concept of delivering mouse events to objects (and I didn’t check whether it 
does now), because that’s harder in 3D.  So I get the impression that in most 
3D scene graphs you have to be more explicit: when the 

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[Jason H]

> Sent: Thursday, September 28, 2017 at 8:20 AM
> From: "André Somers" <an...@familiesomers.nl>
> To: development@qt-project.org
> Subject: Re: [Development] Pointer Handlers will be Tech Preview in 5.10
>
> 
> 
> 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.

Admittedly I don't fully grasp this as I've not worked with the API yet, but...

It seems that you have a InputEvent with several on handlers.
I would not like to see many Handler classes, when these things are really 
mainly only functions.
If we work backwards they are handling events from various input devices. 
Seemingly 2 dimensional,  though force touch and resistive touch devices could 
conceivably provide a 3rd dimension.
I'd probably use a single CartesianDevice which would support events that use 1 
to 3 dimensional coordinate system. 
For 1-D devices, X is used, y is 0, Z (depth) is 0.
For 2-D devices, X and Y are used, Z/depth is 0.
For 3-D devices, X, Y, and Z/depth are used.
If anyone ever invents a spherical coordinate system input device 
PolarDevice... Keystrokes are from KeyDevices..

I never really liked separating gestures from lower order input like mouse 
clicks, since in my limited experience it's all the same device/driver.

I figure the function signatures for Cartesian devices are all the same 
(EventType, Point, EventData) except for multi-point (EventType, Points[], 
EventData[]) And this is really what you are coding against? The callback 
interface/function signature? If so then I would think that single point events 
are the default, Multi point events are prefixed with multi, etc.

The event determines the member (onXXX) and the EventData type onXXX(Point, 
XXXData)

I think someone made a comparison to Keys... I think that would be the example 
to follow. Also i think this would mimic QMouseEvent, QTouchEvent, QTouchDevice?




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [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é


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[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?

tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[J-P Nurmi]

> On 28 Sep 2017, at 13:07, Tor Arne Vestbø  wrote:
> 
> On 28/09/2017 13:05, Tor Arne Vestbø wrote:
>> If we can't have a generic GestureRecognizer type with dynamic recognizer 
>> behavior based on which handler callback is bound, then it should be 
>> TapGestureRecognizer, DragGestureRecognizer, etc.
> 
> Or if we want to follow the existing naming of MouseArea and TouchArea, 
> perhaps GestureArea, with TapGestureArea, DragGestureArea, etc
> 
> tor arne


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.

--
J-P Nurmi

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[Tor Arne Vestbø]

On 28/09/2017 13:05, Tor Arne Vestbø wrote:
If we can't have a generic GestureRecognizer type with dynamic 
recognizer behavior based on which handler callback is bound, then it 
should be TapGestureRecognizer, DragGestureRecognizer, etc.


Or if we want to follow the existing naming of MouseArea and TouchArea, 
perhaps GestureArea, with TapGestureArea, DragGestureArea, etc


tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[Tor Arne Vestbø]

On 27/09/2017 21:18, J-P Nurmi wrote:

On 27 Sep 2017, at 21:08, Jean-Michaël Celerier
 wrote:

Why not just Drag, Tap, Pinch ? (for Drag it'd have to be in a
different namespace than the actual QtQuick.Drag though)

Best,



+1 for such Qt Quick style short and concise naming. :) This proposal
was previously shot down because of the conflict with Drag, though.



-1. Declaring a Drag or Tap in your QML doesn't make sense, as the drag 
and tap are ephemeral, while the QML structure is not.


What we're talking about here is a GestureRecognizer with an onTapped 
handler.


If we can't have a generic GestureRecognizer type with dynamic 
recognizer behavior based on which handler callback is bound, then it 
should be TapGestureRecognizer, DragGestureRecognizer, etc.


tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[J-P Nurmi]

> On 27 Sep 2017, at 21:08, Jean-Michaël Celerier 
>  wrote:
> 
> Why not just Drag, Tap, Pinch ? (for Drag it'd have to be in a different 
> namespace than the actual QtQuick.Drag though)
> 
> Best,


+1 for such Qt Quick style short and concise naming. :) This proposal was 
previously shot down because of the conflict with Drag, though.

--
J-P Nurmi

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[Jean-Michaël Celerier]

Why not just Drag, Tap, Pinch ? (for Drag it'd have to be in a different
namespace than the actual QtQuick.Drag though)

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Sep 27, 2017 at 7:56 PM, J-P Nurmi  wrote:

> On 27 Sep 2017, at 17:35, Shawn Rutledge  wrote:
>
>
> On 27 Sep 2017, at 16:52, J-P Nurmi  wrote:
>
> On 9 Aug 2017, at 14:10, Shawn Rutledge  wrote:
>
> […] So far we only have
>
> TapHandler - […]
> DragHandler - […]
> PinchHandler - […]
>
>
>
> Hi Shawn,
>
> Why are these types called “handlers”? Because we use term “event handler”
> for those methods that you override in C++? IMHO “handler” type names
> belong to the same category with “utils” and “helpers”, type names that you
> give to internal helper classes when you don’t bother coming up with better
> names. You have implemented a gesture framework with support for taps,
> pinches, drags, and swipes, so why not call these types “gestures”?
>
>
> The gesture is what it handles.  The reason the object exists is to handle
> events.
>
>  A TapHandler _handles_ the tap _gesture_.
>
> (subject verb object)
>
> If we just replace that one word with yours:
>
>  A TapGesture handles the tap gesture.
>
> doesn’t sound right to me.
>
>
> Why?
>
> The problem IMO is mainly that we have the habit of calling a Javascript
> block bound to a signal a handler.  E.g. a TapHandler could have an
> onTapped: { … } Javascript block, and what do you call that: the
> TapHandler's onTapped handler?  We could be more old-fashioned and start
> calling bound Javascript functions callbacks (they are just functions after
> all), but it's too hard to break the habit.  Or we could try to think of
> another unique noun with similar meaning for the handler classes.
>
>
> To the point. :) We may use the handler term in many contexts, but what is
> a handler, really? Most Qt classes handle something, but I’m glad we don’t
> have too many handlers. I’m not saying the name doesn’t make sense. You
> could stick that suffix to almost any class and it would make sense, and
> that’s exactly why I put it in the same category with utils and helpers. I
> was just hoping we could have nicer names. That’s all. These things are
> commonly recognized as gestures.
>
> Responder maybe, to use macOS terminology?
>
> Maybe Recognizer, I think I like that.
>
>
> Sounds familiar. Oh, QGestureRecognizer, QPinchGesture, QTapGesture,
> QSwipeGesture… :)
>
> --
> J-P Nurmi
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[J-P Nurmi]

On 27 Sep 2017, at 17:35, Shawn Rutledge 
> wrote:


On 27 Sep 2017, at 16:52, J-P Nurmi > wrote:

On 9 Aug 2017, at 14:10, Shawn Rutledge 
> wrote:

[…] So far we only have

TapHandler - […]
DragHandler - […]
PinchHandler - […]



Hi Shawn,

Why are these types called “handlers”? Because we use term “event handler” for 
those methods that you override in C++? IMHO “handler” type names belong to the 
same category with “utils” and “helpers”, type names that you give to internal 
helper classes when you don’t bother coming up with better names. You have 
implemented a gesture framework with support for taps, pinches, drags, and 
swipes, so why not call these types “gestures”?

The gesture is what it handles.  The reason the object exists is to handle 
events.

 A TapHandler _handles_ the tap _gesture_.

(subject verb object)

If we just replace that one word with yours:

 A TapGesture handles the tap gesture.

doesn’t sound right to me.

Why?

The problem IMO is mainly that we have the habit of calling a Javascript block 
bound to a signal a handler.  E.g. a TapHandler could have an onTapped: { … } 
Javascript block, and what do you call that: the TapHandler's onTapped handler? 
 We could be more old-fashioned and start calling bound Javascript functions 
callbacks (they are just functions after all), but it's too hard to break the 
habit.  Or we could try to think of another unique noun with similar meaning 
for the handler classes.

To the point. :) We may use the handler term in many contexts, but what is a 
handler, really? Most Qt classes handle something, but I’m glad we don’t have 
too many handlers. I’m not saying the name doesn’t make sense. You could stick 
that suffix to almost any class and it would make sense, and that’s exactly why 
I put it in the same category with utils and helpers. I was just hoping we 
could have nicer names. That’s all. These things are commonly recognized as 
gestures.

Responder maybe, to use macOS terminology?

Maybe Recognizer, I think I like that.

Sounds familiar. Oh, QGestureRecognizer, QPinchGesture, QTapGesture, 
QSwipeGesture… :)

--
J-P Nurmi

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[Shawn Rutledge]

> On 27 Sep 2017, at 16:52, J-P Nurmi  wrote:
> 
>> On 9 Aug 2017, at 14:10, Shawn Rutledge  wrote:
>> 
>> […] So far we only have
>> 
>> TapHandler - […]
>> DragHandler - […]
>> PinchHandler - […]
>> 
> 
> 
> Hi Shawn,
> 
> Why are these types called “handlers”? Because we use term “event handler” 
> for those methods that you override in C++? IMHO “handler” type names belong 
> to the same category with “utils” and “helpers”, type names that you give to 
> internal helper classes when you don’t bother coming up with better names. 
> You have implemented a gesture framework with support for taps, pinches, 
> drags, and swipes, so why not call these types “gestures”?

The gesture is what it handles.  The reason the object exists is to handle 
events.

  A TapHandler _handles_ the tap _gesture_.

(subject verb object)

If we just replace that one word with yours:

  A TapGesture handles the tap gesture.

doesn’t sound right to me.

The problem IMO is mainly that we have the habit of calling a Javascript block 
bound to a signal a handler.  E.g. a TapHandler could have an onTapped: { … } 
Javascript block, and what do you call that: the TapHandler's onTapped handler? 
 We could be more old-fashioned and start calling bound Javascript functions 
callbacks (they are just functions after all), but it's too hard to break the 
habit.  Or we could try to think of another unique noun with similar meaning 
for the handler classes.  

Responder maybe, to use macOS terminology?  

Maybe Recognizer, I think I like that.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[J-P Nurmi]

> On 9 Aug 2017, at 14:10, Shawn Rutledge  wrote:
> 
> […] So far we only have
> 
> TapHandler - […]
> DragHandler - […]
> PinchHandler - […]
> 


Hi Shawn,

Why are these types called “handlers”? Because we use term “event handler” for 
those methods that you override in C++? IMHO “handler” type names belong to the 
same category with “utils” and “helpers”, type names that you give to internal 
helper classes when you don’t bother coming up with better names. You have 
implemented a gesture framework with support for taps, pinches, drags, and 
swipes, so why not call these types “gestures”?

--
J-P Nurmi

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development