Re: discussion about touch events

l node chain list for event processing. Care must be taken so we not break the current model for event processing. For example, if a node is picked by its capture zone, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would

Re: discussion about touch events

. 4. Once a node has been picked, we follow the usual node chain list for event processing. Care must be taken so we not break the current model for event processing. For example, if a node is picked by its capture zone, it means that the position does not fall in the boundaries of the node,

Re: discussion about touch events

e, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic controls. Regards, Seeon -Origin

Re: discussion about touch events

processing. For example, if a node is picked by its capture zone, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes

Re: discussion about touch events

vent processing. For example, if a node is picked by its capture zone, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of node

Re: discussion about touch events

Hello all, I'm sorry for the long delay on my side. Daniel, the only remaining point of our discussion that I feel deserves a comment: We could reasonably limit the algorithm to dealing with convex shapes. Can we? What about paths, polygons etc? I realize that it is possible to describe t

Re: discussion about touch events

I'm only occasionally skimming this thread so I hope I don't disrupt discussions by throwing in a few observations now and then... On 11/20/2013 7:30 AM, Assaf Yavnai wrote: Pavel, I think that this is a very good example why touch events should be processed separately from mouse events. For

Re: discussion about touch events

e must be taken so we not break the current model for event processing. For example, if a node is picked by its capture zone, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone fe

Re: discussion about touch events

ries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic controls. Regards, Seeon -Original Message- From: Pavel Safrata Sent: Tuesday, Nov

Re: discussion about touch events

the usual >>>>> parent-child relationship order will give preference to the child. >>>>> >>>>> One way out it is to honor the usual z-order for the extended area of >>>>> child2, so when a touch center hits the fuzzy area of child2, then chi

Re: discussion about touch events

is picked by its capture zone, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic

Re: discussion about touch events

not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic controls. Regards, Seeon -Original Message- From:

Re: discussion about touch events

icked by its capture zone, it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic controls.

Re: discussion about touch events

rictly overlapped by another node and is >>> below that node by z-order. >>> 3. Out of those left choose the "closest" node. (the concept of "closet" >>> should employ some calculation which might not be trivial in the general >>> case). &

Re: discussion about touch events

it means that the position does not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic controls. Regards, Seeon

Re: discussion about touch events

not fall in the boundaries of the node, so existing event handling code that relies on that would break. So I think the capture zone feature should be selectively enabled for certain type of nodes such buttons or other classic controls. Regards, Seeon -----Original Message- From:

Re: discussion about touch events

e the "closest" node. (the concept of "closet" >>> should employ some calculation which might not be trivial in the general >>> case). >>> 4. Once a node has been picked, we follow the usual node chain list for >>> event processing. >>> >

Re: discussion about touch events

des such buttons or other classic controls. Regards, Seeon -Original Message----- From: Pavel Safrata Sent: Tuesday, November 12, 2013 1:11 PM To: Daniel Blaukopf Cc: OpenJFX Subject: Re: discussion about touch events (Now my answer using external link) Hello Daniel, this is quite s

Re: discussion about touch events

ne > feature should be selectively enabled for certain type of nodes such buttons > or other classic controls. > > Regards, > Seeon > > > > > > -Original Message- > From: Pavel Safrata > Sent: Tuesday, November 12, 2013 1:11 PM > To: Daniel Blauk

RE: discussion about touch events

of nodes such buttons or other classic controls. Regards, Seeon -Original Message----- From: Pavel Safrata Sent: Tuesday, November 12, 2013 1:11 PM To: Daniel Blaukopf Cc: OpenJFX Subject: Re: discussion about touch events (Now my answer using external link) Hello Daniel, this is qu

Re: discussion about touch events

Daniel, Pavel , I tend to agree with both of you and also to add some ideas and comments: 1) I think that touch picker and mouse picker should be different implementations used according to origin of event. This means that if application is written to listen only to mouse events and its running

Re: discussion about touch events

(Now my answer using external link) 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

Re: discussion about touch events

(My original message didn't get through to openjfx-dev because I used inline images. I've replaced those images with external links) On Nov 11, 2013, at 11:30 PM, Pavel Safrata > wrote: On 11.11.2013 17:49, Tomas Mikula wrote: On Mon, Nov 11, 2013 at 1:28 PM,

Re: discussion about touch events

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,

Re: discussion about touch events

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

Re: discussion about touch events

On 11.11.2013 17:49, Tomas Mikula wrote: On Mon, Nov 11, 2013 at 1:28 PM, Philipp Dörfler 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

Re: discussion about touch events

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

Re: discussion about touch events

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 listen

Re: discussion about touch events

Hi Assaf, 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 o

Re: discussion about touch events

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 tran