JavaFX embedded (jre 8u6): touch problem (malformed multi touch event)

[Prasant J]

Hi,

I'm woking on Freescale iMX6Q based linux system and I have a single
touch display connected. I'm running Oracle ARM JVM (8u6 release).

The touch is multi touch with 2 touch points (touch controller is from
eGalax). My javafx application does not get any touch events and
javafx dumps the following message:

"com.sun.glass.ui.lens.LensApplication nativeEventLoop
SEVERE: 2352 udevInput.c:1634 lens_input_pointerEvents_handleSync:
[preprocessing MT_A] malformed multi touch event - ignoring"


Any clue what might be wrong? Any inputs will be of help to me.

-Pj

hg: openjfx/8u-dev/rt: RT-37964: [Accessibility] implement a set focus action

[felipe . heidrich]

Changeset: d114805cda20
Author:Felipe Heidrich 
Date:  2014-07-22 16:52 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d114805cda20

RT-37964: [Accessibility] implement a set focus action
Follow-up: implementing REQUEST_FOCUS on ListCell, TableCell, TreeCell, 
TreeTableCell. Common on Windows

! modules/controls/src/main/java/javafx/scene/control/ListCell.java
! modules/controls/src/main/java/javafx/scene/control/TableCell.java
! modules/controls/src/main/java/javafx/scene/control/TreeCell.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java

hg: openjfx/8u-dev/rt: RT-37959: [Accessibility] Review a11y enums

[felipe . heidrich]

Changeset: 1eaf140df101
Author:Felipe Heidrich 
Date:  2014-07-22 16:25 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1eaf140df101

RT-37959: [Accessibility] Review a11y enums
Part 4: Remove SCROLL_INDEX. Add SHOW_ITEM (for ListView, TableView, TreeView, 
TableTreeView) and  SHOW_TEXT_RANGE (for text input controls)

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextInputControlSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java
! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java
! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
! modules/graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java
! modules/graphics/src/main/java/javafx/scene/AccessibleAction.java

hg: openjfx/8u-dev/rt: RT-37959: [Accessibility] Review a11y enums

[felipe . heidrich]

Changeset: 3e3de644625d
Author:Felipe Heidrich 
Date:  2014-07-22 15:41 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3e3de644625d

RT-37959: [Accessibility] Review a11y enums
Part 3: Removed ADD_TO_SELECTION, REMOVE_FROM_SELECTION, SELECT. Added 
SET_SELECTED_ITEMS and SET_TEXT_SELECTION

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java
! modules/controls/src/main/java/javafx/scene/control/ListCell.java
! modules/controls/src/main/java/javafx/scene/control/TableCell.java
! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java
! modules/controls/src/main/java/javafx/scene/control/TreeCell.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java
! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java
! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
! modules/graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java
! modules/graphics/src/main/java/javafx/scene/AccessibleAction.java
! modules/graphics/src/main/java/javafx/scene/AccessibleRole.java

Re: Mirrored observable collections

[Tomas Mikula]

Nice!

On Tue, Jul 22, 2014 at 6:09 PM, Mike Hearn  wrote:
> I have what I imagine is a fairly typical JavaFX application (once it's
> released I'll post more about it). It has a GUI, some mostly asynchronous
> state management, and interactions with various servers that can change the
> apps state.
>
> At first I tried the simple and obvious approach in which the backend would
> schedule closures onto the UI thread using Platform.runLater() when things
> changed, sometimes via ad-hoc event handlers or callbacks. But it ended up
> getting more and more complicated and unclear. So I ended up rewriting
> things to be more actor-ish in which the backend code ran mostly in its own
> thread and vended "mirrored observables".
>
> I figured mirrored observables are a generally useful concept that probably
> JavaFX should have itself.
>
> The idea is simple enough. Given an ObservableList or ObservableSet (I
> didn't need map yet), calling a static utility function with that list and
> an Executor returns a new list in which all updates run in the context of
> that executor. This means a piece of code that's responding to changes in
> state held elsewhere e.g. via a network connection which receives updates
> from a server can have its own thread, and update its own
> ObservableLists/Sets/Maps without thinking about threading as long as the
> only public accessors for these collections vend mirrored versions. Note
> that mirrors are read-only, I don't attempt to do two-way sync (with
> conflict resolution?!). If you want to update the "real" list you have to
> schedule a closure onto the backend thread to do it and wait for the change
> to re-propagate to the frontend thread.
>
> Once this is in place, you can then bind the collections to UI controls
> using some extra transformers in the standard manner, and everything hangs
> together nicely.
>
> The code I'm using is here (Apache licensed, go wild)
>
>https://gist.github.com/mikehearn/4781ce7f00228762adfb
>
> There are three files. AffinityExecutor is an extended version of the
> Executor interface which has a notion of thread ownership (supports short
> circuiting and assertions), along with static methods to create:
>
>1. AffinityExecutors that are bound to a dedicated new thread with a
>task queue.
>2. An AffinityExecutor that queues up tasks but doesn't execute them
>until explicitly requested, this is useful for unit testing.
>3. An AffinityExecutor that wraps Platform.runLater and
>Platform.isFxApplicationThread
>4. An executor that just runs closures immediately on the same thread.
>
> Then ObservableMirrors creates sets/lists in the same way a content binding
> would, but which re-applies changes in the given thread or short-circuits
> and does so immediately if the listener on the mirror is running on the
> same thread as the caller.
>
> There's also a set of static addListener methods in MarshallingObservers
> that just relays into the right thread as well, if you only care about
> changes and not full content.

You can also use ReactFX streams to transfer events (here list
changes) to another thread:

ObservableList list = ...;
EventStream> changesOnFxThread =
EventStreams.changesOf(list)
.threadBridgeToFx(backendExecutor);

See 
http://www.reactfx.org/javadoc/org/reactfx/EventStream.html#threadBridgeToFx-java.util.concurrent.Executor-

>
> Of course you could have an ObservableMirrors equivalent that uses a
> regular Java executor, you'd just lose some safety and short circuiting.

[8u26] Review Request RT-37583 [Monocle] Change X.java and EGL.java to use instance methods

[Lisa Selle]

Hi Daniel,

Please review the proposed fix for 
https://javafx-jira.kenai.com/browse/RT-37583.


Details in the jira.

Thanks,

Lisa

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Kevin Rushforth]

Here is the JIRA that is tracking this:

RT-36215 :  Allow FX to 
interoperate with 3rd party (native) OpenGL visualizations


There aren't any concrete plans to deliver it, though. When/if we do, 
Richard's earlier comments reflect current thinking as to how we would 
likely proceed.


-- Kevin


Richard Bair wrote:

This sounds like there are concrete plans for this, which wood be
great news.



I’d say there were a lot of thoughts around it but it hasn’t been turned into 
an actionable plan. Heck, I don’t even know if we have a JIRA for it (Kevin 
would know…)

Richard

  

The approach where an integration API would only work on
Windows with GL support would at least in our area not be uncommon.
There are a number of digital media pro applications that require GL
to be installed on Windows to work.

Keep up the good work.



  

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Richard Bair]

> This sounds like there are concrete plans for this, which wood be
> great news.

I’d say there were a lot of thoughts around it but it hasn’t been turned into 
an actionable plan. Heck, I don’t even know if we have a JIRA for it (Kevin 
would know…)

Richard

> The approach where an integration API would only work on
> Windows with GL support would at least in our area not be uncommon.
> There are a number of digital media pro applications that require GL
> to be installed on Windows to work.
> 
> Keep up the good work.

hg: openjfx/8u-dev/rt: [Accessibility] Removing warnings (unused import, raw casts)

[felipe . heidrich]

Changeset: 47b2d611494a
Author:Felipe Heidrich 
Date:  2014-07-22 11:54 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/47b2d611494a

[Accessibility] Removing warnings (unused import, raw casts)

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java
! modules/controls/src/main/java/javafx/scene/control/TableView.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java

hg: openjfx/8u-dev/rt: RT-36925: [Linux, Mac] Prism build script unnecessary mixing of 2 different compilers

[kevin . rushforth]

Changeset: bea785e79ae4
Author:kcr
Date:  2014-07-22 11:36 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bea785e79ae4

RT-36925: [Linux, Mac] Prism build script unnecessary mixing of 2 different 
compilers

! buildSrc/linux.gradle
! buildSrc/mac.gradle

hg: openjfx/8u-dev/rt: RT-37959: [Accessibility] Review a11y enums

[felipe . heidrich]

Changeset: 62382252b90a
Author:Felipe Heidrich 
Date:  2014-07-22 09:44 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/62382252b90a

RT-37959: [Accessibility] Review a11y enums
Part 2: remove SELECTED_CELLS and SELECTED_ROWS, use SELECTED_ITEMS instead

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java
! modules/controls/src/main/java/javafx/scene/control/ListView.java
! modules/controls/src/main/java/javafx/scene/control/TableView.java
! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java
! modules/controls/src/main/java/javafx/scene/control/TreeView.java
! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java
! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
! modules/graphics/src/main/java/javafx/scene/AccessibleAttribute.java

Mirrored observable collections

[Mike Hearn]

I have what I imagine is a fairly typical JavaFX application (once it's
released I'll post more about it). It has a GUI, some mostly asynchronous
state management, and interactions with various servers that can change the
apps state.

At first I tried the simple and obvious approach in which the backend would
schedule closures onto the UI thread using Platform.runLater() when things
changed, sometimes via ad-hoc event handlers or callbacks. But it ended up
getting more and more complicated and unclear. So I ended up rewriting
things to be more actor-ish in which the backend code ran mostly in its own
thread and vended "mirrored observables".

I figured mirrored observables are a generally useful concept that probably
JavaFX should have itself.

The idea is simple enough. Given an ObservableList or ObservableSet (I
didn't need map yet), calling a static utility function with that list and
an Executor returns a new list in which all updates run in the context of
that executor. This means a piece of code that's responding to changes in
state held elsewhere e.g. via a network connection which receives updates
from a server can have its own thread, and update its own
ObservableLists/Sets/Maps without thinking about threading as long as the
only public accessors for these collections vend mirrored versions. Note
that mirrors are read-only, I don't attempt to do two-way sync (with
conflict resolution?!). If you want to update the "real" list you have to
schedule a closure onto the backend thread to do it and wait for the change
to re-propagate to the frontend thread.

Once this is in place, you can then bind the collections to UI controls
using some extra transformers in the standard manner, and everything hangs
together nicely.

The code I'm using is here (Apache licensed, go wild)

   https://gist.github.com/mikehearn/4781ce7f00228762adfb

There are three files. AffinityExecutor is an extended version of the
Executor interface which has a notion of thread ownership (supports short
circuiting and assertions), along with static methods to create:

   1. AffinityExecutors that are bound to a dedicated new thread with a
   task queue.
   2. An AffinityExecutor that queues up tasks but doesn't execute them
   until explicitly requested, this is useful for unit testing.
   3. An AffinityExecutor that wraps Platform.runLater and
   Platform.isFxApplicationThread
   4. An executor that just runs closures immediately on the same thread.

Then ObservableMirrors creates sets/lists in the same way a content binding
would, but which re-applies changes in the given thread or short-circuits
and does so immediately if the listener on the mirror is running on the
same thread as the caller.

There's also a set of static addListener methods in MarshallingObservers
that just relays into the right thread as well, if you only care about
changes and not full content.

Of course you could have an ObservableMirrors equivalent that uses a
regular Java executor, you'd just lose some safety and short circuiting.

[8u40] review request: RT-36925: [Linux, Mac] Prism build script unnecessary mixing of 2 different compilers

[Kevin Rushforth]

Chien,

Please review the following:

https://javafx-jira.kenai.com/browse/RT-36925

Thanks.

-- Kevin

hg: openjfx/8u-dev/rt: Fix for RT-37604 [Monocle] Make sure all methods in the X11 port have javadoc

[lisa . selle]

Changeset: 9d9b35b0e3f6
Author:lisa.se...@oracle.com
Date:  2014-07-22 09:16 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9d9b35b0e3f6

Fix for RT-37604 [Monocle] Make sure all methods in the X11 port have javadoc
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf
Reviewed by dblaukopf

! modules/graphics/src/main/java/com/sun/glass/ui/monocle/AcceleratedScreen.java
! 
modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11AcceleratedScreen.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11Cursor.java
! 
modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11InputDeviceRegistry.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11Platform.java
! 
modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11PlatformFactory.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11Screen.java
! modules/graphics/src/main/java/com/sun/glass/ui/monocle/X11WarpingCursor.java

hg: openjfx/8u-dev/rt: RT-37982 : Create a unit test for RT-36241

[rafi . tayar]

Changeset: f07260b4dcda
Author:Rafi Tayar 
Date:  2014-07-22 15:39 +0300
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f07260b4dcda

RT-37982 : Create a unit test for RT-36241
Reviewed-by : dblaukopf

! tests/system/src/test/java/com/sun/glass/ui/monocle/SimpleMouseTest.java

JavaFX Canvas misses API to set dashed line stroke

[David Gilbert]

Hello,

I have created a small open source library that provides a bridge from Java2D 
to the JavaFX Canvas:

https://github.com/jfree/fxgraphics2d

Unfortunately I have so far not been able to support dashed lines, since the 
GraphicsContext from the JavaFX Canvas doesn't provide any API to set the line 
dash attributes.  Did I miss something, or is there really no way to specify 
dashed lines?  I know this is possible in the Shape API 
(http://docs.oracle.com/javafx/2/api/javafx/scene/shape/Shape.html#getStrokeDashArray())
 but I am specifically interested in drawing dashed lines on the JavaFX Canvas. 
 Any pointers will be appreciated.

Best regards,

David

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Robert Krüger]

Thanks for all the in-depth insights. As most of the time it appears
easier at first glance than it actually is.

On Mon, Jul 21, 2014 at 10:22 PM, Richard Bair  wrote:
> I was interested in Angle for exactly this same reason — it would allow us to 
> expose OpenGL at the public API level. However there are licensing issues 
> we’d have to look at, performance tests to be run, security audits performed, 
> and whether or not it is actually able to perform well.
>
> Although the browsers use it for WebGL, WebGL is not the main thing browsers 
> do. What I mean by that, is that if WebGL isn’t working, an HTML author can 
> detect that and redirect or provide some kind of error to the user. If GL 
> doesn’t work for us, we’d be dead in the water (probably just crash) without 
> having some kind of fallback. We could maybe just fallback to software 
> rendering (and realize that in such cases the performance will not be good 
> and people will be mad). It didn’t look like a slam dunk to me. Rather, it 
> seemed to me that we should allow the OpenGL stack to run on Windows with an 
> option, let developers opt into it, but note that it isn’t a supported 
> configuration so we don’t have support costs associated with it if it doesn’t 
> work. And we’d have to forbid it on WebStart / Applets (within reason) so as 
> not to allow bugs in the native drivers to be exploitable through us (if the 
> board causes the VM to crash, there is potentially some security issues 
> there). And then expose an API that works with GL, supported on Mac / Linux, 
> but “known to work” on Windows in cases where Windows GL support works. That 
> seemed to me a shorter path to victory.

This sounds like there are concrete plans for this, which wood be
great news. The approach where an integration API would only work on
Windows with GL support would at least in our area not be uncommon.
There are a number of digital media pro applications that require GL
to be installed on Windows to work.

Keep up the good work.