discussion about touch events

[Philipp Dörfler]

I see the need to be aware of the area that is covered by fingers rather
than just considering that area's center point.
I'd guess that this adds a new layer of complexity, though. For instance:
Say we have a button on some background and both the background and the
button do have an onClick listener attached. If you tap the button in a way
that the touched area's center point is outside of the buttons boundaries -
what event will be fired? Will both the background and the button receive a
click event? Or just either the background or the button exclusively? Will
there be a new event type which gets fired in case of such area-based taps?

My suggestion would therefore be to have an additional area tap event which
gives precise information about diameter and center of the tap. Besides
that there should be some kind of "priority" for choosing which node's
onClick will be called. Maybe the draw order / order in the scene graph / z
buffer value might be sufficient to model what would happen in the real,
physical world.
Am 11.11.2013 13:05 schrieb "Assaf Yavnai" <assaf.yavnai at oracle.com>:

> The ascii sketch looked fine on my screen before I sent the mail :( I hope
> the idea is clear from the text
> (now in the reply dialog its also look good)
>
> Assaf
> On 11/11/2013 12:51 PM, Assaf Yavnai wrote:
>
>> Hi Guys,
>>
>> I hope that I'm right about this, but it seems that touch events in glass
>> are translated (and reported) as a single point events (x & y) without an
>> area, like pointer events.
>> AFAIK, the controls response for touch events same as mouse events (using
>> the same pickers) and as a result a button press, for example, will only
>> triggered if the x & y of the touch event is within the control area.
>>
>> This means that small controls, or even quite large controls (like
>> buttons with text) will often get missed because the 'strict' node picking,
>> although from a UX point of view it is strange as the user clearly pressed
>> on a node (the finger was clearly above it) but nothing happens...
>>
>> With current implementation its hard to use small features in controls,
>> like scrollbars in lists, and it almost impossible to implement something
>> like 'screen navigator' (the series of small dots in the bottom of a smart
>> phones screen which allow you to jump directly to a 'far away' screen)
>>
>> To illustrate it consider the bellow low resolution sketch, where the "+"
>> is the actual x,y reported, the ellipse is the finger touch area and the
>> rectangle is the node.
>> With current implementation this type of tap will not trigger the node
>> handlers
>>
>>                 __
>>               /     \
>>              /       \
>>        ___/ __+_ \___    in this scenario the 'button' will not get
>> pressed
>>        |    \         /    |
>>        |___\ ___ / __ |
>>               \___/
>>
>> If your smart phone support it, turn on the touch debugging options in
>> settings and see that each point translate to a quite large circle and what
>> ever fall in it, or reasonably close to it, get picked.
>>
>> I want to start a discussion to understand if my perspective is accurate
>> and to understand what can be done, if any, for the coming release or the
>> next one.
>>
>> We might use recently opened RT-34136 <https://javafx-jira.kenai.
>> com/browse/RT-34136> for logging this, or open a new JIRA for it
>>
>> Thanks,
>> Assaf
>>
>
>