hg: openjfx/8u-dev/rt: RT-37950: Wrong touch coordinates for a window not at the origin (0, 0)
Changeset: 859783c709ed Author:Seeon Birger seeon.bir...@oracle.com Date: 2014-08-03 13:13 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/859783c709ed RT-37950: Wrong touch coordinates for a window not at the origin (0,0) ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/TouchInput.java
hg: openjfx/8u-dev/rt: RT-38144: Add Single Touch Non-Fullscreen Test
Changeset: edd25a1b83bb Author:Seeon Birger seeon.bir...@oracle.com Date: 2014-08-03 13:24 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/edd25a1b83bb RT-38144: Add Single Touch Non-Fullscreen Test ! tests/system/src/test/java/com/sun/glass/ui/monocle/ParameterizedTestBase.java + tests/system/src/test/java/com/sun/glass/ui/monocle/SingleTouchNonFullScreenTest.java ! tests/system/src/test/java/com/sun/glass/ui/monocle/TestApplication.java
[8u26] Review request : RT-38167: Fix SingleTouchTest: touch count check
Daniel, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-38167 Webrev: http://cr.openjdk.java.net/~sbirger/RT-38167/webrev/ Thanks, Seeon
hg: openjfx/8u-dev/rt: RT-38167: Fix SingleTouchTest: touch count check
Changeset: 2821644c36f4 Author:Seeon Birger seeon.bir...@oracle.com Date: 2014-08-03 16:35 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2821644c36f4 RT-38167: Fix SingleTouchTest: touch count check ! tests/system/src/test/java/com/sun/glass/ui/monocle/SingleTouchTest.java
[8u26] Review request : RT-38168: Redundant creation of LinuxInputProcessor
Daniel, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-38168 Webrev: http://cr.openjdk.java.net/~sbirger/RT-38168/webrev Thanks, Seeon
[8u26] Review request : RT-38144: Add Single Touch Non-Fullscreen Test
Daniel, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-38144 Webrev: http://cr.openjdk.java.net/~sbirger/RT-38144/webrev/ Thanks, Seeon
hg: openjfx/8u-dev/rt: RT-37714: Single swipe event is not handled
Changeset: b405a56cb9c4 Author:Seeon Birger seeon.bir...@oracle.com Date: 2014-07-16 14:02 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b405a56cb9c4 RT-37714: Single swipe event is not handled ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/SwipeGestureRecognizer.java
[8u26] Review request : RT-37714: Single swipe event is not handled
Hi Martin, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37714 http://cr.openjdk.java.net/~sbirger/RT-37714/webrev In particular would like to verify that it behaves well on Windows platform. Thanks, Seeon
Post commit notification: RT-37829: Zoom gesture inertia too agressive
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-37829RT-37829 - Zoom gesture inertia too aggressive Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8c3561a1bccb Regards, Seeon
Post commit notification: RT-36547 - Implement inertia for Scroll gesture
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-36547RT-36547 - Implement inertia for Scroll gesture Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fad1b7cb08d7 Regards, Seeon
Post commit notification: RT-35306: Add scroll gesture recognizer.
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-35306RT-35306 - 8u26: Support multitouch gestures Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ca938a1131ad Regards, Seeon
Post commit notification: RT-35306: Add zoom and rotate gesture recognizers.
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-35306RT-35306 - 8u26: Support multitouch gestures Fixed in commit: 1cff0246b7b6 Regards, Seeon
RE: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Hi Anthony,
Thanks for sending a request for applying the multi-threaded plug-in.
As for the email plug-in mentioned below, using it does not mean sending all
JIRA's automatically to a single mailing list..
On the contrary it can be used as a selective tool for sharing selective JIRAs
to selective people/groups. This might be handy in case an issue was previously
discussed in JIRA and at a point you want to share with specific recipients.
Anyway if the current watch list mechanism functionality suffices that's it's
fine with me.. :)
Regards,
Seeon
-Original Message-
From: Anthony Petrov
Sent: Friday, January 24, 2014 1:07 PM
To: Seeon Birger; Steve Northover
Cc: John Hendrikx; openjfx-dev@openjdk.java.net
Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue
should have a hasListener(listener) method]
Hi Seeon,
I don't think that posting updates from all our JIRAs to a single mailing list
is a good idea because the messages traffic would be huge.
Each JIRA provides a watch list, so people can follow specific bugs that
they're interested in. I believe that this functionality is sufficient for all
reasonable purposes.
However, your suggestion about using threaded comments sounds interesting.
We've sent a request to our Infrastructure team to evaluate the plugin and
consider adding it to our JIRA instance. Note that this is not going to happen
overnight and could take some time, but the request is filed at least. Thanks
for the suggestion!
--
best regards,
Anthony
On 1/23/2014 9:09 PM, Seeon Birger wrote:
Steve,
I wonder if we could take advantage of available plug-ins for JIRA.
I particular I found this one which enables threaded comments for JIRA:
https://marketplace.atlassian.com/plugins/com.atlassian.jira.threadedc
omments.threaded-comments
Also interesting is the following which make it easy to put JIRA updates on
mailing lists in a flexible and customizable way:
https://marketplace.atlassian.com/plugins/com.metainf.jira.plugin.emai
lissue
What do you think?
Seeon
-Original Message-
From: Stephen F Northover
Sent: Thursday, January 23, 2014 12:45 AM
To: John Hendrikx; openjfx-dev@openjdk.java.net
Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613,
ObservableValue should have a hasListener(listener) method]
Hi John,
The goal is not to end the discussion!
It's a trade off. Mailing lists are good because they provide a threaded
discussion. JIRA is bad because it is not threaded. JIRA has the advantage
that it captures data in a single place and provides a good history of why a
decision was made.
There's no right answer here but the policy that the FX committers is using
is to try to capture as much as possible in JIRA.
Steve
On 2014-01-22 5:29 PM, John Hendrikx wrote:
Unfortunately, discussing things in JIRA works very poorly and is a
good way to end a productive discussion IMHO. Mailinglists are much
better suited to the task, as thousands of interesting mailinglists
accross many developer communities will atest to.
Keeping a record is good, aren't these mailinglists archived?
--John
On 22/01/2014 18:47, Daniel Blaukopf wrote:
Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
This is a productive discussion, but once we get to this level of
detail JIRA is the place to have it, so that we don't lose our
record of it. Would you continue the discussion on
https://javafx-jira.kenai.com/browse/RT-25613 ?
See
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeRevie
w s-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F
Northoversteve.x.northo...@oracle.com wrote:
If we add this API, I like addListener(InvalidationListener,
boolean) better than ensureListener().
Steve
On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking
boolean parameter duplicateAllowed or duplicateNotAllowed.
On Wed, Jan 22, 2014 at 3:00 PM, Richard
Bairrichard.b...@oracle.comwrote:
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would
apply to ObservableValue and ChangeListener and
Observable[List|Set|Map] and [List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be
called in the correct order not?
That's a good point :-(
Why doing a remove and not simply check if the
listener has already been added?
Because there is no way to check, except in the implementation.
From the
Observable interface level, there is no way to a) force all
implementations
of the interface to implement the method correctly (without
breaking source
compatibility anyway), or b) to provide a reasonable default
implementation.
Maybe
RE: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Steve,
I wonder if we could take advantage of available plug-ins for JIRA.
I particular I found this one which enables threaded comments for JIRA:
https://marketplace.atlassian.com/plugins/com.atlassian.jira.threadedcomments.threaded-comments
Also interesting is the following which make it easy to put JIRA updates on
mailing lists in a flexible and customizable way:
https://marketplace.atlassian.com/plugins/com.metainf.jira.plugin.emailissue
What do you think?
Seeon
-Original Message-
From: Stephen F Northover
Sent: Thursday, January 23, 2014 12:45 AM
To: John Hendrikx; openjfx-dev@openjdk.java.net
Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue
should have a hasListener(listener) method]
Hi John,
The goal is not to end the discussion!
It's a trade off. Mailing lists are good because they provide a threaded
discussion. JIRA is bad because it is not threaded. JIRA has the advantage
that it captures data in a single place and provides a good history of why a
decision was made.
There's no right answer here but the policy that the FX committers is using is
to try to capture as much as possible in JIRA.
Steve
On 2014-01-22 5:29 PM, John Hendrikx wrote:
Unfortunately, discussing things in JIRA works very poorly and is a
good way to end a productive discussion IMHO. Mailinglists are much
better suited to the task, as thousands of interesting mailinglists
accross many developer communities will atest to.
Keeping a record is good, aren't these mailinglists archived?
--John
On 22/01/2014 18:47, Daniel Blaukopf wrote:
Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
This is a productive discussion, but once we get to this level of
detail JIRA is the place to have it, so that we don't lose our record
of it. Would you continue the discussion on
https://javafx-jira.kenai.com/browse/RT-25613 ?
See
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReview
s-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F
Northoversteve.x.northo...@oracle.com wrote:
If we add this API, I like addListener(InvalidationListener,
boolean) better than ensureListener().
Steve
On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking
boolean parameter duplicateAllowed or duplicateNotAllowed.
On Wed, Jan 22, 2014 at 3:00 PM, Richard
Bairrichard.b...@oracle.comwrote:
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would
apply to
ObservableValue and ChangeListener and Observable[List|Set|Map] and
[List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be
called in
the correct order not?
That's a good point :-(
Why doing a remove and not simply check if the
listener has already been added?
Because there is no way to check, except in the implementation.
From the
Observable interface level, there is no way to a) force all
implementations
of the interface to implement the method correctly (without
breaking source
compatibility anyway), or b) to provide a reasonable default
implementation.
Maybe this is one of those things we can't fix on the Observable
interface
and just have to provide implementations of on our concrete
properties.
Richard
Post commit notification: RT-34632: Lens: VK preload
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-34632RT-34632 - Lens: VK preload Fixed in commit: b9e39db1ecbe Regards, Seeon
[8] Review request for RT-34632: Lens: VK preload
Jonathan, Daniel, Please review in time for ZBB, a fix for https://javafx-jira.kenai.com/browse/RT-34632 - Lens: VK preload (sub-task of https://javafx-jira.kenai.com/browse/RT-24685 - Lens: Virtual keyboard initialization is slow) The patch moves VK initialization including pre-rendering to initialization of first TextInputControl. Preloading is disabled by default. To Enable use: -Dcom.sun.javafx.virtualKeyboard.preload=PRERENDERER Regards, Seeon
Post commit notification: RT-33336: Virtual keyboard buttons has incorrect ids
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-6RT-6 - FB: Virtual keyboard buttons has incorrect ids Fixed in commit: 4d018e4ca9e4 Seeon
Post commit notification: RT-33336: Strip '.' from ids to support keys like '.com'
JIRA: HYPERLINK https://javafx-jira.kenai.com/browse/RT-6RT-6 - FB: Virtual keyboard buttons has incorrect ids Fixed in commit: b681690f12bd Seeon
RE: discussion about touch events
Hi Pavel, Your example of 'child over child' is an interesting case which raises some design aspects of the desired picking algorithm: 1. Which node to pick when one node has a 'strict containership' over the touch center and the other node only has a fuzzy containership (the position falls in the fuzzy area). 2. Accounting for z-order for extended capture zone area. 3. Accounting for parent-child relationship. Referring to your 'child over child' example: http://i.imgur.com/e92qEJA.jpg The conflict would arise were touch point center position falls in the capture zone area of child2 but also clearly falls in the strict bounds of child1. Generally, when two control nodes compete on same touch event (e.g. child1 child2 in Daniel's diagram), it seems that we would like to give priority to strict containership over fuzzy containership. But in your case it's probably not the desired behavior. Also note that in the general case there's almost always exists come container/background node that strictly contains the touch point, but it would probably be an ancestor of the child node, so 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 child2 would be picked. But is not ideal for Daniel's example: http://i.imgur.com/ELWamYp.png where the 2 nodes don't strictly overlap, but their capture zones do. Preferring one child by z-order (which matches the order of children in the parent) is not natural here. And we might better choose the node which is closer To the touch point. So to summarize I suggest this rough picking algorithm: 1. Choose all uppermost nodes which are not transparent to mouse events and contain the touch point center either strictly or by their capture zone. 2. Remove all nodes that is strictly 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). 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, 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, 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 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): Child in parent vs. Child over child: http://i.imgur.com/e92qEJA.jpg ..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 12.11.2013 12:06, Daniel Blaukopf wrote: (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 pavel.safr...@oracle.com mailto:pavel.safr...@oracle.com wrote: On 11.11.2013 17:49, Tomas Mikula wrote: On Mon, Nov 11, 2013 at 1:28 PM, Philipp Dörfler phdoerf...@gmail.com mailto:phdoerf...@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
