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
