discussion about touch events
pavel.safrata at oracle.com
Mon Nov 11 04:22:42 PST 2013
this was discussed during during the multi-touch API design phase. I
completely understand what you are saying, yet it has no
straightforward/automatic solution you may have imagined. First, we
can't pick "whatever falls into the circle" - imagine there are two
buttons next to each other, do we want to activate both of them? No,
each event has to have a single target. Moreover, everybody can easily
comprehend the idea of the imprecise touch on a button, but from FX
point of view there is a bunch of nodes (not every application uses just
controls) and each of the application's nodes needs to be pickable.
At that time, if I remember correctly, there was a preliminary agreement
that the way around this might be giving the control to the user's hands
in a form of an API that would for instance make a node pickable on a
certain distance from it. So user could tell to a button "enlarge your
bounds about 10 pixels in each direction and pick on those bounds",
which would then behave as if the button had a transparent border around
it (perhaps applying only to touch events / synthesized mouse events).
Of course controls could use this API to implement a reasonable default
behavior, but user still needs to have the option to create an
unobtrusive ImageView-background with an event-greedy ImageView-button
On 11.11.2013 11:51, 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
> / \
> / \
> ___/ __+_ \___ in this scenario the 'button' will not get
> | \ / |
> |___\ ___ / __ |
> 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
More information about the openjfx-dev