> On 27 Sep 2017, at 16:52, J-P Nurmi <jpnu...@qt.io> wrote:
>
>> On 9 Aug 2017, at 14:10, Shawn Rutledge <shawn.rutle...@qt.io> 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
