discussion about touch events

Tue Nov 12 02:52:22 PST 2013

The image seems to have been stripped somewhere, trying to attach once more.
Pavel

On 12.11.2013 11:46, Pavel Safrata wrote:
> Hello Daniel,
> this is quite similar to my idea described earlier. The major 
> difference is the "fair division of capture zones" among siblings. 
> It's an interesting idea, let's explore it. What pops first is that 
> children can also overlap. So I think it would behave like this (green 
> capture zones omitted):
>
> see attachment
>
> ..wouldn't it? From user's point of view this seems confusing, both 
> cases look the same but behave differently. Note that in the case on 
> the right, the parent may be still the same, developer only adds a 
> fancy background as a new child and suddenly the red child can't be 
> hit that easily. What do you think? Is it an issue? Or would it not 
> behave this way?
>
> Regards,
> Pavel
>
> On 11.11.2013 23:44, Daniel Blaukopf wrote:
>>
>> On Nov 11, 2013, at 11:30 PM, Pavel Safrata <pavel.safrata at oracle.com 
>> <mailto:pavel.safrata at oracle.com>> wrote:
>>
>>> On 11.11.2013 17:49, Tomas Mikula wrote:
>>>> On Mon, Nov 11, 2013 at 1:28 PM, Philipp Dörfler 
>>>> <phdoerfler at gmail.com <mailto: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?
>>>>
>>>
>>> There is always something directly on the center of the touch 
>>> (possibly the scene background, but it can have event handlers too). 
>>> That's what we pick right now.
>>> Pavel
>>
>> What Seeon, Assaf and I discussed earlier was building some fuzziness 
>> into the node picker so that instead of each node capturing only 
>> events directly on top of it:
>>
>> ..nodes at each level of the hierarchy would capture events beyond 
>> their borders as well:
>>
>> In the above, “Parent” would capture touch events within a certain 
>> radius around it, as would its children “Child 1” and “Child 2”. 
>> Since “Child 1” and “Child 2” are peers, they would have a sharp 
>> division between them, a watershed on either side of which events 
>> would go to one child node or the other. This would also apply if the 
>> peer nodes were further apart; they would divide the no-man’s land 
>> between them. Of course this no-man’s land would be part of “Parent” 
>> and could could be touch-sensitive - but we won’t consider “Parent” 
>> as an event target until we have ruled out using one of its 
>> children’s extended capture zones.
>>
>> The capture radius could either be a styleable property on the nodes, 
>> or could be determined by the X and Y size of a touch point as 
>> reported by the touch screen. We’d still be reporting a touch point, 
>> not a touch area. The touch target would be, as now, a single node.
>>
>> This would get us more reliable touch capture at leaf nodes of the 
>> node hierarchy at the expense of it being harder to tap the 
>> background. This is likely to be a good trade-off.
>>
>> Daniel
>>
>>
>>
>>>
>>>> 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 <mailto: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
>>
>