discussion about touch events

[Tomas Mikula]

On Mon, Nov 11, 2013 at 1:28 PM, Philipp Dörfler <phdoerfler at gmail.com> wrote:
> 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.

What about picking the one that is closest to the center of the touch?

Tomas

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