hg: openjfx/8u-dev/rt: RT-38668 [Monocle] x86egl build fails with warnings
Changeset: e68f17bfa4f1 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-09-16 11:38 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e68f17bfa4f1 RT-38668 [Monocle] x86egl build fails with warnings ! modules/graphics/src/main/native-glass/monocle/x11/X11.c
hg: openjfx/8u-dev/rt: RT-38673 [Monocle] Fall back to headless screen if we cannot access the framebuffer
Changeset: 55914cd82ec8 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-09-16 17:43 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/55914cd82ec8 RT-38673 [Monocle] Fall back to headless screen if we cannot access the framebuffer ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatform.java
hg: openjfx/8u-dev/rt: RT-37414 JavaFX x86egl cross built from a 64 bits Linux gives NumberFormatException
Changeset: 2abfc95e5ffd Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-09-11 15:17 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2abfc95e5ffd RT-37414 JavaFX x86egl cross built from a 64 bits Linux gives NumberFormatException ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/SysFS.java
hg: openjfx/8u-dev/rt: RT-38393 [Monocle] Mouse Events stop coming on embedded
Changeset: 1d08d9490df0 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-09-08 10:51 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1d08d9490df0 RT-38393 [Monocle] Mouse Events stop coming on embedded Fixes in modules/graphics/src/main/java/com/sun/glass/ui/monocle/ contributed by fheidric ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxInputDeviceRegistry.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java ! tests/system/src/test/java/com/sun/glass/ui/monocle/MultiTouch2Test.java ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/devices/EGalaxMultiTouchDevice1.java ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/devices/EGalaxMultiTouchDevice2.java + tests/system/src/test/java/com/sun/glass/ui/monocle/input/devices/EGalaxMultiTouchDevice3.java + tests/system/src/test/java/com/sun/glass/ui/monocle/input/devices/EGalaxMultiTouchDevice4.java + tests/system/src/test/java/com/sun/glass/ui/monocle/input/devices/EGalaxMultiTouchDeviceBase.java ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/devices/TestTouchDevices.java
Re: openjfx-8u20-b23: Stuck in monocle build for armv7hf
Hi Prasant,
I suggest you modify the following line in bin/pkg-config in your SDK directory:
export
PKG_CONFIG_LIBDIR=${SYSROOT}/usr/lib/arm-linux-gnueabihf/pkgconfig:${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig
.. so that it includes the path to your Pango package index.
Thanks,
Daniel
On Jul 31, 2014, at 4:06 PM, Lisa Selle lisa.se...@oracle.com wrote:
Kevin or David,
Ideas on how to get Prasant past this issue? Apparently he has his pango
libs installed in a non-standard location and needs to use PKG_CONFIG_PATH so
they can be found.
Thanks,
Lisa
Original Message
Subject: Re: openjfx-8u20-b23: Stuck in monocle build for armv7hf
Date: Thu, 31 Jul 2014 11:37:08 +0530
From: Prasant J pj0...@gmail.com
To: Lisa Selle lisa.se...@oracle.com
CC: openjfx-dev@openjdk.java.net Mailing openjfx-dev@openjdk.java.net
On Thu, Jul 31, 2014 at 10:10 AM, Prasant J pj0...@gmail.com wrote:
On Wed, Jul 30, 2014 at 11:16 PM, Lisa Selle lisa.se...@oracle.com wrote:
How did you install your arm toolchain?
I'm using yocto (poky distribution) for my iMX6. I can build my own
SDK (toolchain). I'm using that.
I may have made some mistake is setting up the toolchain (I will look
into that one again).
I have now corrected the toolchian setup!
https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+Arm+Hard+Float
If it's installed according to these instructions pkg-config should get
picked up from the correct place and there should be no need to set any
environment variables.
Is there a way to set environment variables?
Still stuck at the same point.
In my linux shell I executed the following commands:
./pkg-config --cflags pangoft2 [cannot find package pangoft2]
PKG_CONFIG_PATH=path ./pkg-config --cflags pangoft2 [finds the
package and lists the cflags]
So, is there any way to pass the environment variable PKG_CONFIG_PATH
before executing 'commandLine' ?
Regards, Pj
Re: JavaFX embedded (jre 8u6): touch problem (malformed multi touch event)
We are in the process of moving this application into the openjfx repository. On Jul 27, 2014, at 1:03 PM, Seeon Birger seeon.bir...@oracle.com wrote: You can use this one which is more suitable for testing multi-touch: rt-closed/toys/HelloWorld/src/helloworld/HelloMultitouch.java Also note that if using Monocle you'll have to apply the patch referenced in this JIRA: RT-37950 - Wrong touch coordinates for a window not at the origin (0,0) Regards, Seeon -Original Message- From: Lisa Selle Sent: Friday, 25 July 2014 18:43 To: Prasant J Cc: openjfx-dev@openjdk.java.net Subject: Re: JavaFX embedded (jre 8u6): touch problem (malformed multi touch event) Daniel, Do you have any other suggestions for apps that we know handle multitouch correctly that Prasant could use to determine if his multitouch problem is in the platform or in his app? Thanks, Lisa On 7/25/2014 11:42 AM, Lisa Selle wrote: rt//apps/toys/Hello/ has HelloGestures which uses multitouch gestures. I'm not aware of any others, but maybe someone else on the list has some input there? I will inquire internally also. Thanks, Lisa On 7/25/2014 11:20 AM, Prasant J wrote: Hi Lisa, Can you please point out to me a javafx application that can help me test my multi touch? I want to rule out my application out of my multi touch test, so a standard multi touch test will be of help to me. Regards, Prasant On Fri, Jul 25, 2014 at 7:47 PM, Lisa Selle lisa.se...@oracle.com wrote: On 7/25/2014 10:06 AM, Prasant J wrote: On Wed, Jul 23, 2014 at 6:36 PM, Lisa Selle lisa.se...@oracle.com wrote: Hi Prasant, This looks suspiciously related to https://javafx-jira.kenai.com/browse/RT-34296. If so, this bug *should* be fixed in Monocle but it is not (and will not be) fixed in lens. Thanks Lisa for pointing that out. First I tried to build the openjfx 8u6 (you pasted a link in another post) with the patch someone posted in the RT-34296 jira post. The patch had to be manually applied because it was created from a different changeset. Anyway, I was able to apply the patch and cross build successfully. However, only one touch was working. Second touch is not working (I could not figure out). The single touch is also sending two events and my application has different behaviour for one event and two events. So, I abandoned this idea and I;m building the latest javafx. I believe you are building openJFX, correct? If you can try a recent build with the latest Monocle code (if you are building from OpenJFX, monocle is now the default) the problem should be resolved. Please let us know if that's not the case. I was able to build from 8u-dev/rt (tag: 8u20-b23). However my application is recognizing the touch only on the main window. I have multi-touch in the pop-up window where even single touch in not working from some reason. Whenever I touch to bring up the pop-up window I get the following error message on console: Exception in thread JavaFX Application Thread java.lang.InstantiationError: com.sun.javafx.scene.traversal.TraversalEngine at com.sun.javafx.scene.control.skin.ScrollPaneSkin.initialize(ScrollP aneSkin.java:242) at com.sun.javafx.scene.control.skin.ScrollPaneSkin.init(ScrollPaneS kin.java:130) at javafx.scene.control.ScrollPane.createDefaultSkin(ScrollPane.java:579) at javafx.scene.control.Control.impl_processCSS(Control.java:878) at javafx.scene.Parent.impl_processCSS(Parent.java:1267) at javafx.scene.Parent.impl_processCSS(Parent.java:1267) at javafx.scene.Parent.impl_processCSS(Parent.java:1267) at javafx.scene.Node.processCSS(Node.java:8858) at javafx.scene.Node.processCSS(Node.java:8851) at javafx.scene.Node.processCSS(Node.java:8851) at javafx.scene.Scene.doCSSPass(Scene.java:525) at javafx.scene.Scene.access$3400(Scene.java:144) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2358) at com.sun.javafx.tk.Toolkit.lambda$runPulse$28(Toolkit.java:314) at com.sun.javafx.tk.Toolkit$$Lambda$354/20040469.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:313) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:340) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java: 451) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java: 431) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$363(Quan tumToolkit.java:298) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$71/28758344.run(Un known Source) at com.sun.glass.ui.monocle.RunnableProcessor.runLoop(RunnableProcesso r.java:77) at
Re: Java SE Embedded 8u6 and JDK 8u6 for ARM released
built from are not currently public. I don't believe there is any plan to make them public, although I will follow up on this question. In the case where the repos remain private, then I'm sorry to say that while all JavaFX changesets for 8u6 are also in 8u-dev, there is no tag or other indicator which would let you see exactly which changesets went into 8u6, or to duplicate them in a build. If you are interested in specific features or bug fixes, there are jiras corresponding to the bulk of the changesets - just look for 8u6 in the fix version field. The jiraas should contain links to the corresponding openjfx changeset. Is this just a general question or is there something specific you are looking for? Maybe there is another way to get you the information you're after. Lisa On 7/11/2014 5:25 AM, Jörg Wille wrote: Hi, what JavaFX Changeset is this release based on? And in which repo can I see the tag for this release? Jörg Date: Thu, 10 Jul 2014 17:06:58 +0300 From: Daniel Blaukopf daniel.blauk...@oracle.com daniel.blauk...@oracle.com To: openjfx-dev@openjdk.java.net Mailing openjfx-...@openjdk.java.netMailing openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net Subject: Java SE Embedded 8u6 and JDK 8u6 for ARM released Message-ID: 5ae2b8ca-d766-4969-94cb-34d8f080d...@oracle.com 5ae2b8ca-d766-4969-94cb-34d8f080d...@oracle.com Content-Type: text/plain; charset=us-ascii Hi, JDK 8u6 for ARM and Java SE Embedded 8u6 were released yesterday. This release includes new JavaFX features in addition to bug fixes: Support for Freescale i.MX6Q Sabre Device Platform Multitouch support The 8u6 release also includes several enhancements to the core Java platform such as reduced static footprint and improved runtime performance. Java SE Embedded:http://www.oracle.com/technetwork/java/embedded/ embedded-se/downloads/javase-embedded-downloads-2209751.html JDK for ARM:http://www.oracle.com/technetwork/java/javase/ downloads/jdk8-arm-downloads-2187472.html Docs: http://docs.oracle.com/javase/8/javase-embedded.htm This is an update to the tested and supported binary release of JavaFX. The OpenJFX sources have the latest features and bug fixes, but have not undergone the same testing as supported JavaFX binary releases. Daniel
Java SE Embedded 8u6 and JDK 8u6 for ARM released
Hi, JDK 8u6 for ARM and Java SE Embedded 8u6 were released yesterday. This release includes new JavaFX features in addition to bug fixes: Support for Freescale i.MX6Q Sabre Device Platform Multitouch support The 8u6 release also includes several enhancements to the core Java platform such as reduced static footprint and improved runtime performance. Java SE Embedded: http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/javase-embedded-downloads-2209751.html JDK for ARM: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-arm-downloads-2187472.html Docs: http://docs.oracle.com/javase/8/javase-embedded.htm This is an update to the tested and supported binary release of JavaFX. The OpenJFX sources have the latest features and bug fixes, but have not undergone the same testing as supported JavaFX binary releases. Daniel
hg: openjfx/8u-dev/rt: RT-37865 [Monocle] Show absolute axis bounds in GetEvent
Changeset: 8cd193121334 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-09 15:59 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8cd193121334 RT-37865 [Monocle] Show absolute axis bounds in GetEvent ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/GetEvent.java
hg: openjfx/8u-dev/rt: RT-37871 [Monocle] monocle.input.traceEvents.verbose should imply monocle.input.traceEvents
Changeset: acc06f0a5691 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-09 20:43 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/acc06f0a5691 RT-37871 [Monocle] monocle.input.traceEvents.verbose should imply monocle.input.traceEvents ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleSettings.java
hg: openjfx/8u-dev/rt: Fix broken build
Changeset: 91225781d515 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-07 13:16 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/91225781d515 Fix broken build ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/TouchState.java
Re: Monocle gone?
Hi Christian, Monocle is gone for the desktop since it is not a tested configuration there. We only test Monocle in his non-headless implementations, on embedded platforms. However, if you build OpenJFX yourself (https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) you will get Monocle included in the build and will be able to use it as before. Thanks, Daniel On Jul 5, 2014, at 11:09 PM, Christian krampenschies...@gmail.com wrote: Hi all, I just updated from 1.8.20-b17 to b21 and there is no monocle platform anymore. Will it come back? Is there any other way to have a headless build? I was trying around with xvfb as an alternative but sadly: ES2 Prism: Error - GLX extension is not supported GLX version 1.3 or higher is required Additionally xvfb segfaults... However I would be awesome if Monocle would be back. I have a lot of tests for the UI and since I cannot mock JavaFX classes because they are final I have to run a real application. Thanks, Christian
hg: openjfx/8u-dev/rt: [DOCS] RT-35308: [Monocle] Make sure all methods in Monocle used by the X11 port have javadocs
Changeset: cfdd4005b555 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-06 15:49 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cfdd4005b555 [DOCS] RT-35308: [Monocle] Make sure all methods in Monocle used by the X11 port have javadocs Partial fix ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/C.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/InputDevice.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/KeyInput.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/KeyState.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyBits.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxSystem.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MouseInput.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MouseState.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativeCursor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NullCursor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/SoftwareCursor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/TouchState.java
hg: openjfx/8u-dev/rt: [DOCS] RT-35308: [Monocle] Make sure all methods in Monocle used by the X11 port have javadocs
Changeset: 8aa4a19308e6 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-06 16:37 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8aa4a19308e6 [DOCS] RT-35308: [Monocle] Make sure all methods in Monocle used by the X11 port have javadocs ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/InputDeviceRegistry.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativeScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/RunnableProcessor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/X.java
hg: openjfx/8u-dev/rt: RT-37802 [Monocle] GetEvent shows events as integer values instead of constant names
Changeset: b072265d6928 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-03 15:01 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b072265d6928 RT-37802 [Monocle] GetEvent shows events as integer values instead of constant names ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxInput.java
hg: openjfx/8u-dev/rt: RT-36424 [Monocle] Implement software solution for double buffering
Changeset: a83aa0a73ee5 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-07-03 15:09 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a83aa0a73ee5 RT-36424 [Monocle] Implement software solution for double buffering ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/FBDevScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxFrameBuffer.java
hg: openjfx/8u-dev/rt: RT-37456 [Monocle] Fold together monocle.input, monocle.util and monocle packages
Changeset: 3fa3f3d53510 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-06-25 09:58 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3fa3f3d53510 RT-37456 [Monocle] Fold together monocle.input, monocle.util and monocle packages Reviewed-by: kselle ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/AcceleratedScreen.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/AssignPointIDTouchFilter.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/C.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/DispmanAcceleratedScreen.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/DispmanCursor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/DispmanPlatform.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/DispmanPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/DispmanScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/EGL.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/FBDevScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/Framebuffer.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/GLException.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/GetEvent.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/HeadlessPlatform.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/HeadlessPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/HeadlessScreen.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/InputDevice.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/InputDeviceRegistry.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/IntSet.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/KeyInput.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/KeyState.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxAbsoluteInputCapabilities.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxEventBuffer.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxEventBuffers.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxFrameBuffer.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxInput.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxInputDevice.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxInputDeviceRegistry.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxInputProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyBits.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxMouseProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatform.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxSimpleTouchProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatelessMultiTouchProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxSystem.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxTouchProcessor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxTouchTransform.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/LookaheadTouchFilter.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6AcceleratedScreen.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6Platform.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6PlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleCursor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleDnDClipboard.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonoclePixels.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonoclePlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleRobot.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleSettings.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleSystemClipboard.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleTimer.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleTrace.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleView.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindow.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java + modules/graphics/src/main/java/com/sun/glass
hg: openjfx/8u-dev/rt: RT-37707 [Monocle] Software cursor is too transparent
Changeset: 83f65386cca4 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-06-25 16:53 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/83f65386cca4 RT-37707 [Monocle] Software cursor is too transparent ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/SoftwareCursor.java
[8u26] Review request RT-37456: [Monocle] Fold together monocle.input, monocle.util and monocle packages
Hi Lisa, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37456 Thanks, Daniel
[8u26] Review request RT-37508: [Monocle] Support 16-bit software-rendered framebuffer
Hi Dave, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37508 Thanks, Daniel
[8u26] Review request RT-37512: [Monocle] Provide a software-rendered cursor
Hi Dave and Lisa, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37512 Thanks, Daniel
[8u26] Review request RT-36960: A switch to change between frame buffers
Hi Lisa, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-36960 Thanks, Daniel
Review request: RT-37474 [Monocle] Shift-backspace generates an undefined key code
Hi Lisa, Please review: https://javafx-jira.kenai.com/browse/RT-37474 http://cr.openjdk.java.net/~dblaukop/webrev-20140609-2233-RT-37474/webrev Thanks, Daniel
Review request: RT-36421 Implement drag and drop for monocle
Hi Dave and Lisa, Please review: http://cr.openjdk.java.net/~dblaukop/webrev-20140520-0006-RT-36421/webrev/ https://javafx-jira.kenai.com/browse/RT-36421 Thanks, Daniel
Review request: RT-35838 [Quantum] NPE if Platform.exit() is called when rendering is happening
Hi Steve and Dave, Please review: http://cr.openjdk.java.net/~dblaukop/webrev-20140212-0939-RT-35838/webrev/ https://javafx-jira.kenai.com/browse/RT-35838 Thanks, Daniel
Re: ScrollPane like on iOS?
Hi Tobias, Running with -Dcom.sun.javafx.touch=true should get you the effect you are looking for. The code for this is in VirtualFlow and ScrollBarSkin. Thanks, Daniel On May 11, 2014, at 3:39 PM, Tobias Bley t...@ultramixer.com wrote: Hi JavaFX freaks, does anybody has an idea how to start to develop a ScrollPane that acts like the one on iOS? When the scroll position on iOS is on top (0) and the user drags the scroll pane to bottom, it slides down until the user releases the finger (touch off). Best regards, Tobi
Review request: RT-37063 [Monocle] X11 port should use full screen mode
Hi Lisa and Dave, Please review: http://cr.openjdk.java.net/~dblaukop/webrev-20140511-1730-RT-37063/webrev https://javafx-jira.kenai.com/browse/RT-37063 Thanks, Daniel
Review request: RT-37064 [Monocle] Make -Dembedded=monocle the default
Hi Lisa, Please review: http://cr.openjdk.java.net/~dblaukop/webrev-20140511-1749-RT-37064/webrev/ https://javafx-jira.kenai.com/browse/RT-37064 Thanks, Daniel
Review request: RT-37065 [Monocle] Use the X11 implementation in preference to framebuffer if DISPLAY is set
Hi Lisa and Dave, Please review: http://cr.openjdk.java.net/~dblaukop/webrev-20140511-1809-RT-37065/webrev/ https://javafx-jira.kenai.com/browse/RT-37065 Thanks, Daniel
Re: News about Java 8
Hi Ricardo, These are great questions. You are correct in your analysis that the Pi implementation uses a different code path for touch than desktop Linux. Although what you are trying to do is not a supported configuration of JavaFX, the good news is that it should work and we can help you get it built. I recommend using the Monocle implementation of Glass instead of Lens. Here are the flags to do that and select the X11 implementation: -Djavafx.platform=monocle -Dmonocle.platform=X11 -Dembedded=monocle If you run into input problems, the following flags should help you debug them: -Dmonocle.input.traceEvents=true -Dmonocle.input.traceEvents.verbose=true Please let me know how you get on with this. Thanks, Daniel On May 6, 2014, at 7:56 PM, Ruíz Martín, Ricardo rrmar...@indra.es wrote: Hi, We are trying adding direct multitouch interaction support for our JavaFX application and we are facing some multi-touch support issues under Linux. Under Windows all touch events are propagated (zoom, rotate, swipe, touch...), but although windows can be a development solution for us, we would need final version running under Linux. We have tried different distributions (mainly RedHat beta7 and Ubuntu 14.04) and only events we get from JavaFX are Mouse events generated by multi-touch screen. There are a Jira Issue about this (with some others duplicate issues): https://javafx-jira.kenai.com/browse/RT-25079 But there are no timeline or Fix version. Searching for some workaround we have found that OpenJfx has Raspberry Pi multitouch support in ARM linux JVM runtime. It seems that this support is because ARM JVM does not use X11 and/or GTK, but only device drivers, and it should be possible build OpenJFX with this configuration for x86 (I suppose this should work on 64 bits too.) With this build we should use EGL/X11 for full-screen output but we would get inputs from dev/input. So we have tried build OpenJFX with -PCOMPILE_TARGETS=x86egl because we can get touch events from /dev/input/eventX in evtest with no problems. Unfortunately although we can build OpenJFX for linux with no target, when we use this compile target build fails: https://javafx-jira.kenai.com/browse/RT-36921 We are stuck now with this. Is there any other way for getting multitouch events with JavaFX under Linux? Regards Ricardo Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary.
Re: News about Java 8
With the latest code you should be getting notification of multitouch gestures as well as raw multitouch events. These events use JavaFX's built-in gesture recognizer for embedded platforms. Out of curiosity, what touch screen are you using? Thanks, Daniel On May 7, 2014, at 12:29 PM, Daniel Blaukopf daniel.blauk...@oracle.com wrote: Hi Ricardo, These are great questions. You are correct in your analysis that the Pi implementation uses a different code path for touch than desktop Linux. Although what you are trying to do is not a supported configuration of JavaFX, the good news is that it should work and we can help you get it built. I recommend using the Monocle implementation of Glass instead of Lens. Here are the flags to do that and select the X11 implementation: -Djavafx.platform=monocle -Dmonocle.platform=X11 -Dembedded=monocle If you run into input problems, the following flags should help you debug them: -Dmonocle.input.traceEvents=true -Dmonocle.input.traceEvents.verbose=true Please let me know how you get on with this. Thanks, Daniel On May 6, 2014, at 7:56 PM, Ruíz Martín, Ricardo rrmar...@indra.es wrote: Hi, We are trying adding direct multitouch interaction support for our JavaFX application and we are facing some multi-touch support issues under Linux. Under Windows all touch events are propagated (zoom, rotate, swipe, touch...), but although windows can be a development solution for us, we would need final version running under Linux. We have tried different distributions (mainly RedHat beta7 and Ubuntu 14.04) and only events we get from JavaFX are Mouse events generated by multi-touch screen. There are a Jira Issue about this (with some others duplicate issues): https://javafx-jira.kenai.com/browse/RT-25079 But there are no timeline or Fix version. Searching for some workaround we have found that OpenJfx has Raspberry Pi multitouch support in ARM linux JVM runtime. It seems that this support is because ARM JVM does not use X11 and/or GTK, but only device drivers, and it should be possible build OpenJFX with this configuration for x86 (I suppose this should work on 64 bits too.) With this build we should use EGL/X11 for full-screen output but we would get inputs from dev/input. So we have tried build OpenJFX with -PCOMPILE_TARGETS=x86egl because we can get touch events from /dev/input/eventX in evtest with no problems. Unfortunately although we can build OpenJFX for linux with no target, when we use this compile target build fails: https://javafx-jira.kenai.com/browse/RT-36921 We are stuck now with this. Is there any other way for getting multitouch events with JavaFX under Linux? Regards Ricardo Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary.
Re: News about Java 8
On May 7, 2014, at 12:47 PM, Ruíz Martín, Ricardo rrmar...@indra.es wrote: Hi Daniel, This properties should work in 8u20? Only with OpenJFX repository version? You’ll need to build OpenJFX with the latest repository version because you need this fix: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9db01136330d Thanks, Daniel With repository version if I get a x86egl buld? Thank you Ricardo De: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] Enviado el: miércoles, 07 de mayo de 2014 11:29 Para: Ruíz Martín, Ricardo CC: openjfx-dev@openjdk.java.net Asunto: Re: News about Java 8 Hi Ricardo, These are great questions. You are correct in your analysis that the Pi implementation uses a different code path for touch than desktop Linux. Although what you are trying to do is not a supported configuration of JavaFX, the good news is that it should work and we can help you get it built. I recommend using the Monocle implementation of Glass instead of Lens. Here are the flags to do that and select the X11 implementation: -Djavafx.platform=monocle -Dmonocle.platform=X11 -Dembedded=monocle If you run into input problems, the following flags should help you debug them: -Dmonocle.input.traceEvents=true -Dmonocle.input.traceEvents.verbose=true Please let me know how you get on with this. Thanks, Daniel On May 6, 2014, at 7:56 PM, Ruíz Martín, Ricardo rrmar...@indra.es wrote: Hi, We are trying adding direct multitouch interaction support for our JavaFX application and we are facing some multi-touch support issues under Linux. Under Windows all touch events are propagated (zoom, rotate, swipe, touch...), but although windows can be a development solution for us, we would need final version running under Linux. We have tried different distributions (mainly RedHat beta7 and Ubuntu 14.04) and only events we get from JavaFX are Mouse events generated by multi-touch screen. There are a Jira Issue about this (with some others duplicate issues): https://javafx-jira.kenai.com/browse/RT-25079 But there are no timeline or Fix version. Searching for some workaround we have found that OpenJfx has Raspberry Pi multitouch support in ARM linux JVM runtime. It seems that this support is because ARM JVM does not use X11 and/or GTK, but only device drivers, and it should be possible build OpenJFX with this configuration for x86 (I suppose this should work on 64 bits too.) With this build we should use EGL/X11 for full-screen output but we would get inputs from dev/input. So we have tried build OpenJFX with -PCOMPILE_TARGETS=x86egl because we can get touch events from /dev/input/eventX in evtest with no problems. Unfortunately although we can build OpenJFX for linux with no target, when we use this compile target build fails: https://javafx-jira.kenai.com/browse/RT-36921 We are stuck now with this. Is there any other way for getting multitouch events with JavaFX under Linux? Regards Ricardo Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s
[8u26] Review request for RT-35406 [Monocle] Implement mouse/touch grab
Hi Lisa, Would you review the fix for https://javafx-jira.kenai.com/browse/RT-35406 ? http://cr.openjdk.java.net/~dblaukop/webrev-20140505-2010-RT-35406/webrev/ Thanks, Daniel
Re: FX and PiTFT on Raspberry
Hi Marco, Is it the parameter to vc_dispmanx_display_open that you want to change? Currently this is fixed at 0 in dispmanCursor.c but we could make that configurable. Is the problem that JavaFX is drawing to the wrong screen, or getting the wrong screen size? Would you open a JIRA describing what you need? Thanks, Daniel On May 4, 2014, at 1:01 PM, Marco Wiorek ma...@code-xy.com wrote: Hello guys, I wonder if it is possible to redirect the eglfb output to /dev/fb1 instead of fb0. An older revision of modules/graphics/src/main/native-prism-es2/eglfb/wrapped_egl.c (19ca9150cb33) seem to had it hard coded but in newer versions it is not. The touch events are perfectly catched but the frame buffer unfortunately is wrong. Regards and thanks in advance, Marco
[8u26] Review request for RT-36822 [Monocle] X11 framebuffer container doesn't work any more
Hi Lisa, Would you review the fix for https://javafx-jira.kenai.com/browse/RT-36822? http://cr.openjdk.java.net/~dblaukop/webrev-20140424-2239-RT-36822/webrev/ Thanks, Daniel
[8u26] Review request for RT-36461: Monocle: Pressing two fingers, releasing, and pressing again - is sending two touch events with same coordinates
Hi Rafi, Would you review the fix for https://javafx-jira.kenai.com/browse/RT-36461 ? http://cr.openjdk.java.net/~dblaukop/webrev-20140417-0022-RT-36461/webrev/ Thanks, Daniel
Re: JavaFX8: Multittouch support under Linux
Tracked at https://javafx-jira.kenai.com/browse/RT-36462 It's targeted at 9, but there will be a patch soon. Thanks, Daniel On 4/4/14, 10:40 AM, Stefan Schwandter wrote: Hi, thanks! I’ve tried to compile on a current Ubuntu 13.10. A default build (gradle 1.8 without parameters) works fine. With gradle -PCOMPILE_TARGETS=x86egl sdk however, I get the following build error: stefan@stefan-OptiPlex-GX620:~/src/openjfx/rt$ gradle -PCOMPILE_TARGETS=x86egl sdk :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava UP-TO-DATE :buildSrc:compileGroovy UP-TO-DATE :buildSrc:processResources UP-TO-DATE :buildSrc:classes UP-TO-DATE :buildSrc:jar UP-TO-DATE :buildSrc:assemble UP-TO-DATE :buildSrc:compileTestJava UP-TO-DATE :buildSrc:compileTestGroovy UP-TO-DATE :buildSrc:processTestResources UP-TO-DATE :buildSrc:testClasses UP-TO-DATE :buildSrc:test UP-TO-DATE :buildSrc:check UP-TO-DATE :buildSrc:build UP-TO-DATE Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html for information on the replacement for dynamic properties. Deprecated dynamic property: compilePrefix on root project 'rt', value: . FAILURE: Build failed with an exception. * Where: Script '/home/stefan/src/openjfx/rt/buildSrc/x86egl.gradle' line: 59 * What went wrong: A problem occurred evaluating script. No signature of method: java.lang.String.exists() is applicable for argument types: () values: [] Possible solutions: wait(), toList(), expand(), execute(), toList(), next() * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 9.536 secs Best, Stefan Am 02.04.2014 um 10:19 schrieb Daniel Blaukopf daniel.blauk...@oracle.com: Hi Stefan, You have it exactly right. The touch support on the Raspberry Pi and similar devices gets events from the Linux device drivers, not from X11 or GTK. We don’t provide a binary of this configuration for x86, but if you are able to build OpenJFX then you could easily create a binary yourself (“gradle -PCOMPILE_TARGETS=x86egl sdk”). This is a hybrid binary that uses EGL/X11 for full-screen output but gets input directly from device nodes in /dev/input. Thanks, Daniel On Apr 2, 2014, at 11:10 AM, Stefan Schwandter s.schwand...@me.com wrote: Hi Anthony, thanks for your quick reply. I wonder though: it seems there’s at least preliminary touch support for OpenJFX on the Raspberry Pi - is this because it does not use X11 and/or GTK there? Is it possible to do the same on an X86-based Linux device? Cheers, Stefan Am 01.04.2014 um 14:02 schrieb Anthony Petrov anthony.pet...@oracle.com: Hi Stefan, No, currently it's not. Here's a JIRA that you may want to watch: https://javafx-jira.kenai.com/browse/RT-25079 -- best regards, Anthony On 4/1/2014 3:52 PM, Stefan Schwandter wrote: Hello all! Is multitouch-input supposed to be supported on Java 8 SE running on Linux? I use a capacitive touch screen, with a DMC controller, connected to a Ubuntu 13.10 PC via USB, and none of the sample code that I've tried seems to recognize any touch events. Under Windows 7, touch events are recognized, I can swipe, zoom, etc. So I wonder, if multitouch input is simply not supported under Linux with JavaFX 8, or I have another problem. Best regards, Stefan
Re: JavaFX8: Multittouch support under Linux
Hi Stefan, You have it exactly right. The touch support on the Raspberry Pi and similar devices gets events from the Linux device drivers, not from X11 or GTK. We don’t provide a binary of this configuration for x86, but if you are able to build OpenJFX then you could easily create a binary yourself (“gradle -PCOMPILE_TARGETS=x86egl sdk”). This is a hybrid binary that uses EGL/X11 for full-screen output but gets input directly from device nodes in /dev/input. Thanks, Daniel On Apr 2, 2014, at 11:10 AM, Stefan Schwandter s.schwand...@me.com wrote: Hi Anthony, thanks for your quick reply. I wonder though: it seems there’s at least preliminary touch support for OpenJFX on the Raspberry Pi - is this because it does not use X11 and/or GTK there? Is it possible to do the same on an X86-based Linux device? Cheers, Stefan Am 01.04.2014 um 14:02 schrieb Anthony Petrov anthony.pet...@oracle.com: Hi Stefan, No, currently it's not. Here's a JIRA that you may want to watch: https://javafx-jira.kenai.com/browse/RT-25079 -- best regards, Anthony On 4/1/2014 3:52 PM, Stefan Schwandter wrote: Hello all! Is multitouch-input supposed to be supported on Java 8 SE running on Linux? I use a capacitive touch screen, with a DMC controller, connected to a Ubuntu 13.10 PC via USB, and none of the sample code that I've tried seems to recognize any touch events. Under Windows 7, touch events are recognized, I can swipe, zoom, etc. So I wonder, if multitouch input is simply not supported under Linux with JavaFX 8, or I have another problem. Best regards, Stefan
Re: Glass Robot and getSCreenCapture
We should be consistent about what we return, although I agree that that the actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable. On Mar 21, 2014, at 7:05 PM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi David, I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing. In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen). So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff00 - both look good. However, I agree that a stricter specification and a check might be the best solution. -- best regards, Anthony On 3/21/2014 8:53 PM, David Hill wrote: I have been working on a problem with Robot.getScreenCapture() on a 565 ARM device, and while doing so, encountered a couple of questions which I will bring up: Pixxls getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) I don't seem any real documentation that says how x,y + width,height should be treated when compared to the reality of the Screen. What values of x,y + width,height are reasonable ? I can picture any number of scenarios with them that would result in a box that does not fit within the Screen dimensions. The only implementing code I have seen checks to that the width height are = 1. Can I/Should I handle -x values ? What if the requested bounds exceed the screen ? If we are making assumptions that the requested box is inside the screen then why don't we document that fact and add a check in the Robot class (instead of relying on the native impls). If we are assuming the requested box does not have to lie within the screen bounds - what should the returned values be for the pixels outside the screen ? Pixel Black ? (Currently I think Lens would return 0x instead of 0xff00) My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. This code is internal API, so I expect the real impact would be on SQE.
Re: Failure to find any font (probably on Embedded)
Unless someone has removed font files from the Java directory tree - in which
case all bets are off - this won’t happen with the JRE or JDK for any platform.
It will only happen with Java SE Embedded Compact Profiles. So referring them
to “the release notes for Java SE Embedded” seems reasonable. We can verify
with the version system properties that this is actually SE Embedded before
showing that message.
Daniel
On Feb 12, 2014, at 1:53 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:
A more informative message and an earlier detection both sound good. Not sure
about the pointer to the Wiki page, though. We haven't done that in the past
that I am aware of. If we do want to go down that path, I would suggest a
pointer to a single, well-known support page that could describe various
end-user configuration issues that we might want to document.
-- Kevin
David Hill wrote:
I am chasing a edge case that probably only happens in certain Embedded
configurations. If we don't find *any* fonts, then we quietly fail and blame
it on CSS :-)
I say blame it on CSS because the resulting hard failure is:
Exception in thread JavaFX Application Thread
java.lang.NoClassDefFoundError: Could not initialize class
javafx.scene.CssStyleHelper
This is because CSS needs a font for various calculations.
With Embedded, if libfontconfig is not present (or improperly configured)
you will not find any fonts.
I would like thoughts on my putting a more informative error message out,
and making zero fonts an earlier hard failure.
What I would really like to do is to be able to put a URL to a Fonts wiki
page (like: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but
not sure how well that would stand up to the test of time.
The code point in FontConfigManager is:
if (anyFont == null) {
if (debugFonts) {
System.err.println(Fontconfig returned no fonts at all.);
}
fontConfigFailed = true;
return;
8u20: Request for feedback on unit test proposal
Hi, I put up on https://javafx-jira.kenai.com/browse/RT-35396 a draft of what our unit tests might look like if we were to run them on top of the real Quantum Toolkit instead of StubToolkit. The main problem is how to solve the threading: tests that use StubToolkit are all accessing the toolkit and scene graph on the main thread, which you can’t do in Quantum. A webrev is here: http://cr.openjdk.java.net/~dblaukop/webrev-20140123-1559-RT-35330/webrev It’s not complete. I rewrote some tests to correct the threading, but many other problems remain, like that tests call methods on StubToolkit that are not part of the Toolkit interface. For a start I’d like feedback on how we get around the threading problems in JUnit. Thanks, Daniel
Re: 8u20: Request for feedback on unit test proposal
It will run with whatever combination of Quantum, Glass and Prism you throw at it. If you run it with -Dheadless=true, FXUnit will run with the headless configuration of Monocle (not the VNC configuration, but you could just as well use that instead). On Jan 30, 2014, at 8:09 PM, Tom Eugelink t...@tbee.org wrote: Am I to understand that this is using the VNC server? Because I'm not seeing the tell-tale -D parameters in the gradle.build. Or is this actually running on-screen? Tom On 2014-1-30 18:40, Daniel Blaukopf wrote: Hi, I put up on https://javafx-jira.kenai.com/browse/RT-35396 a draft of what our unit tests might look like if we were to run them on top of the real Quantum Toolkit instead of StubToolkit. The main problem is how to solve the threading: tests that use StubToolkit are all accessing the toolkit and scene graph on the main thread, which you can’t do in Quantum. A webrev is here: http://cr.openjdk.java.net/~dblaukop/webrev-20140123-1559-RT-35330/webrev It’s not complete. I rewrote some tests to correct the threading, but many other problems remain, like that tests call methods on StubToolkit that are not part of the Toolkit interface. For a start I’d like feedback on how we get around the threading problems in JUnit. Thanks, Daniel
Re: Monocle with VNC for Jenkins [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Hi Tom, You have it right. Currently the VNC server is always running on port 5901, but feel free to open a JIRA to change that. If you want to test this today you need to build OpenJFX yourself (https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX). We don’t have snapshots of 8u20 on java.net yet, although I hope we will soon. Thanks, Daniel On Jan 22, 2014, at 9:41 AM, Tom Eugelink t...@tbee.org wrote: What also is very interesting is headless testing. Let me see if I'm getting this. Normally Jenkins would start a VNC server (xvnc), which provides some kind of graphics API against which an UI program can paint. JavaFX is not picking that up however. But, as I read it, in this case JavaFX starts its own VNC server, so it takes of everything itself. All one would need to do is specify the -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw And additionally a port to run the VNC server on (so multiple Jenkins jobs don't interfere). Am I correct? How can I test this (aka in which version is the VNC server available)? Tom
Re: Monocle with VNC for Jenkins [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Hi Uwe, On Jan 22, 2014, at 2:19 PM, Uwe Sander usan...@tesis.de wrote: Hi, I'm interested in headless testing, too. I tried to use StubToolkit for including TestFX tests in a headless build, but all I got was a CNFE. If anyone is interested to give me a hand on this, details can be found at http://stackoverflow.com/questions/21137039/how-to-use-stubtoolkit-instead-of-quantum-toolkit-for-my-javafx-application. As Tom explained, Monocle would provide another way for headless testing. Does it replace StubToolkit? Monocle uses the same Quantum toolkit that other JavaFX implementation use - not StubToolkit, which is only used in testing. As I see it, there is a place for tests using StubToolkit, and a place for tests using a real Toolkit implementation. For example, QuantumToolkit has a very specific threading model, but this is not enforced by StubToolkit. StubToolkit is useful for isolated tests of the upper parts of the JavaFX stack. For a real application you need to test on a real Toolkit, and headless Monocle is one way to do that. We have https://javafx-jira.kenai.com/browse/RT-35330 open on removing StubToolkit. I’m not convinced that is the right thing to do. https://javafx-jira.kenai.com/browse/RT-35396 would open up possibilities for a new class of automated test, without requiring us to rewrite existing tests that use StubToolkit. Thanks, Daniel Cheers, Uwe Tom Eugelink t...@tbee.org , 22/1/2014 8:46 AM: What also is very interesting is headless testing. Let me see if I'm getting this. Normally Jenkins would start a VNC server (xvnc), which provides some kind of graphics API against which an UI program can paint. JavaFX is not picking that up however. But, as I read it, in this case JavaFX starts its own VNC server, so it takes of everything itself. All one would need to do is specify the -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw And additionally a port to run the VNC server on (so multiple Jenkins jobs don't interfere). Am I correct? How can I test this (aka in which version is the VNC server available)? Tom
Re: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Thanks John! I agree that in an IoT environment where you can have many devices, a central gateway and a fast local network, a solution based on remote display could work well. Daniel On Jan 22, 2014, at 1:07 AM, John Smith john_sm...@symantec.com wrote: Monocle is a very interesting and exciting development for the JavaFX team. I think that it is an avenue of approach which may help enable the development of various innovative solutions, both in providing access to JavaFX applications through traditional web UIs or providing remote GUI access to myriad small devices which make up the Internet of Things. Ø Since WebSockets are part of Java EE I don't think this is something that could be part of the standard JavaFX build Yes, I agree. There are some excellent existing WebSocket solutions for Java, such as Tyrus https://tyrus.java.net/ and Kaazing. Though the WebSocket protocol is simple to users, there are many tricky pitfalls in creating a robust WebSocket server, so using those complete and well-tested solutions is the best route. As the client app would actually be installed on the server much like a normal JEE app, using a standard JEE lib is perfectly appropriate I think. The tricky part (at least for me) would be to take the VNC (or OpenGL) commands and tunnel them through a WebSocket system. Anyway, something to think about in my spare time. Thanks a lot for the replies and posting to the list Daniel. John From: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] Sent: Tuesday, January 21, 2014 2:45 PM To: John Smith; openjfx-dev@openjdk.java.net Subject: Re: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end] Hi John, On 01/22/2014 12:24 AM, John Smith wrote: Would it be possible to develop a web based VNC client rendering to HTML canvas that connects to the Monocle VNC server over WebSockets such as that discussed in Kanaka’s answer here: http://stackoverflow.com/a/3902817/1155209? I’m just interested in the feasibility of the approach as a basis for future development of a potential 3rd party JavaFX app deployment solution outside of JavaFX core. I understand that this is probably not the primary reason the Monocle VNC work was implemented, but I’m curious if it could be repurposed for this mechanism. Essentially, my goal here is to enable AppStreaming JavaFX http://aws.amazon.com/appstream/ without requiring a proprietary amazon solution. In your opinion, would such a solution be a feasible basis for developing a distribution mechanism for JavaFX applications which does not require anything on the client outside of an HTML5 compliant browser? It would absolutely be feasible, although the lag would probably be annoying. Since WebSockets are part of Java EE I don't think this is something that could be part of the standard JavaFX build, but Monocle allows for pluggable screen implementations and it shouldn't be much work to modify VNCScreen.java to do this. Alternatively we could put just enough of an implementation of WebSockets in VNCScreen to be able to talk to the browser directly. Fromhttp://www.websocket.org/aboutwebsocket.html the protocol doesn't look complicated. Unless you need a secure authenticated connection of course, in which case the answer would have to be Java EE. However, what would be 100x better in terms of perfomance would be to stream the OpenGL commands to a WebGL client. We'd still have the lag though. We did an experiment for a few days last month in the JavaFX team with marshalling up OpenGL calls into a stream and sending them down the wire to a client doing the rendering on another device, and the performance looked promising. A bit like http://sourceforge.net/projects/virtualgl/, but without the video stream. Thanks, Daniel Thanks, John From: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] Sent: Tuesday, January 21, 2014 12:53 PM To: John Smith; openjfx-dev@openjdk.java.net Subject: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end] Hi John, This is a mostly complete implementation of Glass that instead of rendering to the screen, renders to an offscreen buffer and serves the buffer up to clients using the RFB protocol. So you should be able to connect to it with most VNC clients, although I haven't been able to get it to work with desktop sharing on the Mac. You can also provide mouse input to JavaFX using the VNC client. To use (BTW, this is noted in the JIRA https://javafx-jira.kenai.com/browse/RT-35441): Run with: -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw Connect with a VNC client to port 5901. I used TigerVNC (http://sourceforge.net/projects/tigervnc/files/) since the OS X desktop sharing client didn't like the 15-year old version of the RFB protocol
Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
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#CodeReviews-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F Northover steve.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 Bair richard.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
8u20 review request: RT-35443 Provide a headless glass implementation integrated with our JUnit tests
Hi Steve and Anthony, Would you review the following change to our build/test scripts to allow running JUnit tests in headless Monocle on desktop platforms? https://javafx-jira.kenai.com/browse/RT-35443 http://cr.openjdk.java.net/~dblaukop/webrev-20140121-1743-RT-35443/webrev/ Currently all tests run with this patch pass. Thanks, Daniel
Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Re: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
8u20 review request: RT-35355 - Software rendering ports of Monocle need notification of pixel upload end
Hi Kevin and Anthony, Would you review the following change to have Quantum notify Glass when it has finished rendering all scenes? This is to enable double-buffering on embedded and headless systems. https://javafx-jira.kenai.com/browse/RT-35355 http://cr.openjdk.java.net/~dblaukop/webrev-20140116-2022-RT-35355/webrev/ Thanks, Daniel
Re: 8u20 review request: RT-35355 - Software rendering ports of Monocle need notification of pixel upload end
Dave suggested another way of does this, which I tried out and it seemed to work. Notes and link to patch are in the JIRA. Either approach is OK with me, but others might feel more strongly about it. Daniel On Jan 16, 2014, at 10:31 PM, Daniel Blaukopf daniel.blauk...@oracle.com wrote: Hi Kevin and Anthony, Would you review the following change to have Quantum notify Glass when it has finished rendering all scenes? This is to enable double-buffering on embedded and headless systems. https://javafx-jira.kenai.com/browse/RT-35355 http://cr.openjdk.java.net/~dblaukop/webrev-20140116-2022-RT-35355/webrev/ Thanks, Daniel
Re: 8u20 review request: RT-35355 - Software rendering ports of Monocle need notification of pixel upload end
Dave suggested another way of does this, which I tried out and it seemed to work. Notes and link to patch are in the JIRA. Either approach is OK with me, but others might feel more strongly about it. Daniel On Jan 16, 2014, at 10:31 PM, Daniel Blaukopf daniel.blauk...@oracle.com wrote: Hi Kevin and Anthony, Would you review the following change to have Quantum notify Glass when it has finished rendering all scenes? This is to enable double-buffering on embedded and headless systems. https://javafx-jira.kenai.com/browse/RT-35355 http://cr.openjdk.java.net/~dblaukop/webrev-20140116-2022-RT-35355/webrev/ Thanks, Daniel
Announcing Monocle, an experimental port of Glass for embedded systems
Hi, A few of us in the JavaFX team have been trying over the holidays to put together an embedded implementation of Glass that has minimal native code. When developing the existing embedded Glass implementation, Lens, we had noticed that there were a few problems were were running into again and again: - We were duplicating data structures between C and Java. - Logic was split between C and Java, making it hard to debug effectively. - In many cases we needed to make expensive JNI up-calls from C to Java. - Each additional platform we added support for increased the complexity of the system and frequently required similar changes in Glass and Prism. - Any level of pluggability in C needs a lot of setup to do, both for the platform porting layer (on which we did make some progress) and the ability to use custom input handlers (on which we didn’t) Monocle is an attempt to resolve these problems. It’s in a very basic state right now, but it is enough to play with. There is a description of the components and how to run up at https://wiki.openjdk.java.net/display/OpenJFX/Monocle. Monocle is currently buildable for all platforms, but on desktop platforms it only works in headless mode. It can render on BeagleBoard xM, Freescale i.MX6 and in embedded emulation mode on Linux/x86. Your feedback is welcome, on this alias and in JIRA. Daniel
Re: Announcing Monocle, an experimental port of Glass for embedded systems
On the radar but not implemented yet. On Jan 9, 2014, at 3:24 AM, Scott Palmer swpal...@gmail.com wrote: What's the situation on Raspberry Pi? I got one for Christmas and made a quick memory game for my daughter with JavaFX - works great. Should I bother trying or do you already know it doesn't work? Scott On Wed, Jan 8, 2014 at 7:00 PM, Daniel Blaukopf daniel.blauk...@oracle.com wrote: Hi, A few of us in the JavaFX team have been trying over the holidays to put together an embedded implementation of Glass that has minimal native code. When developing the existing embedded Glass implementation, Lens, we had noticed that there were a few problems were were running into again and again: - We were duplicating data structures between C and Java. - Logic was split between C and Java, making it hard to debug effectively. - In many cases we needed to make expensive JNI up-calls from C to Java. - Each additional platform we added support for increased the complexity of the system and frequently required similar changes in Glass and Prism. - Any level of pluggability in C needs a lot of setup to do, both for the platform porting layer (on which we did make some progress) and the ability to use custom input handlers (on which we didn’t) Monocle is an attempt to resolve these problems. It’s in a very basic state right now, but it is enough to play with. There is a description of the components and how to run up at https://wiki.openjdk.java.net/display/OpenJFX/Monocle. Monocle is currently buildable for all platforms, but on desktop platforms it only works in headless mode. It can render on BeagleBoard xM, Freescale i.MX6 and in embedded emulation mode on Linux/x86. Your feedback is welcome, on this alias and in JIRA. Daniel
[8u] Code Review Request - RT-34951: Provide a way to exit when the screen is first rendered
Hi Kevin, Please review this extension to PulseLogger to exit after processing a given number of pulses. This is for benchmarking VM startup time using FX samples. https://javafx-jira.kenai.com/browse/RT-34951 http://cr.openjdk.java.net/~dblaukop/webrev-20140106-2341-RT-34951/webrev/ Thanks, Daniel
Re: Platform.isSupported behavior
Hi Stas, Yes, you have a good point here. The behavior you are seeing is what I would expect, but I agree we could do better in how we specify this. Currently, States reported by Platform.isSupported are updated when input devices are added and removed Controls check the connected input devices at startup time. They do not change their behavior on the fly as input devices are added and removed. Enabling listening to state changes certainly makes sense - probably by defining state in ObservableProperties. I’m not sure we actually want controls to reconfigure themselves dynamically and automatically though. Maybe someone working on controls can comment on this, but it seems like it would be a complex transition with many edge cases to deal with. Why change caching of input device state in Lens and Quantum though? Lens needs to cache the state of input devices in order to be able to report on what input features are available. I’m not sure Quantum is doing any caching of this state at all - as far as I know it is going directly to Glass to query input device features. Controls do of course cache input device state. A thought about API for listening to state changes. What if we added an API to Platform like Platform.isSupported that instead of returning a boolean returned an ObservableBooleanValue? This listener would never be notified on conditional features like EFFECT or SCENE3D but would be notified on those conditional features that reflect input device state. Thanks, Daniel On Nov 19, 2013, at 10:09 AM, Stas Smirnov stanislav.smir...@oracle.com wrote: Hello, Lately I have faced a strange behavior while I was using JavaFX Embedded and touch screen. As far as I understand there is no spec where I can find this information, that is why I decided to ask the community. I have developed a simple application with one text field and a button. I run it using JavaFX Embedded runtime with LCD+touch monitor connected to an abstract board. As a result I can see touch mode in the application, the virtual keyboard and other touch features. However if I plug out the touch part, connect mouse, at the runtime, the application does not change its appearance and behavior, the vk is still available with all touch features. So only restart of the application disables touch mode. I know that there is Platform.isSupported method to detect different states, and touch is one of them. So I have checked, that, when I during the runtime plug in/out touch and press the button to check Platform.isSupported value, I can see it changes every time I plug in/out the touch screen. I assume it happens, because every time I call Platform.isSupported the real check is being performed and because of that its value changes. But once again, there is no spec to check it. I have a proposal: * what if there will be some kind of listener to handle state changes * add this listener to the controls where they ask Platform.isSupported to make controls change their appearance and behavior * disable caching of the state in the platform(lens, quantum) * create specification where the realization will be described -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
Re: Platform.isSupported behavior
Hi Stas, On Nov 19, 2013, at 12:02 PM, Stas Smirnov stanislav.smir...@oracle.com wrote: Hi Daniel, about caching, I placed it in the list, because there is no spec telling about it, and anyone can add/remove it, that why it is an object of concern. It will be great to hear from Controls team, cause from my point of view, dynamical change of controls behavior will improve usability. Talking about ObservableBooleanValue, nice idea, I think it will be really better, than having boolean return value. Are you going to implement it? Eventually and after more discussion. From my point of view none of this discussion is about Java 8 - there aren’t going to be any more API changes or non-critical changes to controls behavior in that time frame. Would you open a JIRA for this, targeted at 9? Thanks, Daniel 19.11.2013 13:32, Daniel Blaukopf пишет: Hi Stas, Yes, you have a good point here. The behavior you are seeing is what I would expect, but I agree we could do better in how we specify this. Currently, States reported by Platform.isSupported are updated when input devices are added and removed Controls check the connected input devices at startup time. They do not change their behavior on the fly as input devices are added and removed. Enabling listening to state changes certainly makes sense - probably by defining state in ObservableProperties. I’m not sure we actually want controls to reconfigure themselves dynamically and automatically though. Maybe someone working on controls can comment on this, but it seems like it would be a complex transition with many edge cases to deal with. Why change caching of input device state in Lens and Quantum though? Lens needs to cache the state of input devices in order to be able to report on what input features are available. I’m not sure Quantum is doing any caching of this state at all - as far as I know it is going directly to Glass to query input device features. Controls do of course cache input device state. A thought about API for listening to state changes. What if we added an API to Platform like Platform.isSupported that instead of returning a boolean returned an ObservableBooleanValue? This listener would never be notified on conditional features like EFFECT or SCENE3D but would be notified on those conditional features that reflect input device state. Thanks, Daniel On Nov 19, 2013, at 10:09 AM, Stas Smirnov stanislav.smir...@oracle.com wrote: Hello, Lately I have faced a strange behavior while I was using JavaFX Embedded and touch screen. As far as I understand there is no spec where I can find this information, that is why I decided to ask the community. I have developed a simple application with one text field and a button. I run it using JavaFX Embedded runtime with LCD+touch monitor connected to an abstract board. As a result I can see touch mode in the application, the virtual keyboard and other touch features. However if I plug out the touch part, connect mouse, at the runtime, the application does not change its appearance and behavior, the vk is still available with all touch features. So only restart of the application disables touch mode. I know that there is Platform.isSupported method to detect different states, and touch is one of them. So I have checked, that, when I during the runtime plug in/out touch and press the button to check Platform.isSupported value, I can see it changes every time I plug in/out the touch screen. I assume it happens, because every time I call Platform.isSupported the real check is being performed and because of that its value changes. But once again, there is no spec to check it. I have a proposal: * what if there will be some kind of listener to handle state changes * add this listener to the controls where they ask Platform.isSupported to make controls change their appearance and behavior * disable caching of the state in the platform(lens, quantum) * create specification where the realization will be described -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
Review request:
Hi Assaf and Dave, Would you review a fix for the ChalkBoard Electronics 7” touch screen? https://javafx-jira.kenai.com/browse/RT-34338 The patch is in the JIRA comments. Thanks, Daniel
Re: Two Level Focus
Hi John, TWO_LEVEL_FOCUS is a feature developed for embedded platforms. However it can be enabled for desktop platforms by setting a system property in the way you describe. The kind of input device you have is exactly a match for two level focus. On embedded platforms the criterion for setting two level focus is that arrow and select keys are available but not a full PC keyboard. Unfortunately there are a number of bugs currently filed against two level focus and we are not going to be fixing all of them for the upcoming Java 8 release. I do encourage you to file JIRAs on specific issues you run into so that we can track them in update releases. If you can include sample code and information on what JavaFX key codes are generated by your remote, that will help. Thanks, Daniel Yes, you can enable TWO_LEVEL_FOCUS on non-embedded platforms On Nov 16, 2013, at 5:22 PM, John Hendrikx hj...@xs4all.nl wrote: Hi list, I'm wondering how well the Conditional Feature TWO_LEVEL_FOCUS works, and if it is allowed to be used on non-embedded platforms. My main JavaFX project is basically a Windows/Linux application that runs without focus and is controlled with a remote control (no mouse or keyboard, although keyboard events are synthesized). This means I often run into problems related to the Window not having focus (controls donot show it, combobox drop downs close automatically, etc.) While fixing yet another of these problems in custom controls / skins, I ran into the Conditional Feature above, which quite accurately describes what I'm doing (remote control only has left/right/up/down and an OK button... and a back button) which qualifies as two level navigation I think. So I tried turning this on on Windows using: System.setProperty(com.sun.javafx.twoLevelFocus, true); ...which I dug up out of Jira. This changes ComoBox control atleast to not respond to up and down keys when it has the focus, allowing me to move away from it. However, if you do click on it with the mouse (by selecting one of its items), focus is stuck there and cannot be moved anymore with just the 5 buttons. Anyway, this sounds like it is exactly what I need and may save me a lot of work, any more information about it is appreciated! --John
Re: discussion about touch events
(hopefully) it can be perfected. Right now I can't see any other algorithm that would work well and would result in more efficient implementation (the search for overlapping nodes and closest borders etc. is going to be pretty complicated as well, if it's even possible to make it work). What do you think? Any better ideas? Pavel On 13.11.2013 22:09, Daniel Blaukopf wrote: Hi Seeon, Summarizing our face to face talk today: I see that the case described by Pavel is indeed a problem and agree with you that not every node needs to be a participant in the competition for which grabs touch input. However I’m not keen on the idea of changing behavior based on which nodes have listeners on them. CSS seems like the place to do this (as I think Pavel suggested earlier). In Pavel’s case, either: - the upper child node has the CSS tag saying “enable extended capture zone” and the lower child doesn’t: then the upper child’s capture zone will extend over the lower child - or both will have the CSS tag, in which case the upper child’s capture zone would be competing with the lower child’s capture zone. As in any other competition between capture zones the nearest node should win. The effect would be the same as if the regular matching rules were applied on the upper child. It would also be the same as if only the lower child had an extended capture zone. However, I’d consider this case to be bad UI programming. We agreed that “in a competition between capture zones, pick the node whose border is nearest the touch point” was a reasonable way to resolve things. Thanks, Daniel On Nov 13, 2013, at 12:31 PM, Seeon Birger seeon.bir...@oracle.com wrote: 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
Re: discussion about touch events
Hi Seeon, Summarizing our face to face talk today: I see that the case described by Pavel is indeed a problem and agree with you that not every node needs to be a participant in the competition for which grabs touch input. However I’m not keen on the idea of changing behavior based on which nodes have listeners on them. CSS seems like the place to do this (as I think Pavel suggested earlier). In Pavel’s case, either: - the upper child node has the CSS tag saying “enable extended capture zone” and the lower child doesn’t: then the upper child’s capture zone will extend over the lower child - or both will have the CSS tag, in which case the upper child’s capture zone would be competing with the lower child’s capture zone. As in any other competition between capture zones the nearest node should win. The effect would be the same as if the regular matching rules were applied on the upper child. It would also be the same as if only the lower child had an extended capture zone. However, I’d consider this case to be bad UI programming. We agreed that “in a competition between capture zones, pick the node whose border is nearest the touch point” was a reasonable way to resolve things. Thanks, Daniel On Nov 13, 2013, at 12:31 PM, Seeon Birger seeon.bir...@oracle.com wrote: 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
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 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 closest to the center of the touch? There is always something directly on the center of the touch (possibly the scene background, but it can have event handlers too). That's what we pick right now. Pavel What Seeon, Assaf and I discussed earlier was building some fuzziness into the node picker so that instead of each node capturing only events directly on top of it: Non-fuzzy picker: http://i.imgur.com/uszql8V.png ..nodes at each level of the hierarchy would capture events beyond their borders as well: Fuzzy picker: http://i.imgur.com/ELWamYp.png In the above, “Parent” would capture touch events within a certain radius around it, as would its children “Child 1” and “Child 2”. Since “Child 1” and “Child 2” are peers, they would have a sharp division between them, a watershed on either side of which events would go to one child node or the other. This would also apply if the peer nodes were further apart; they would divide the no-man’s land between them. Of course this no-man’s land would be part of “Parent” and could could be touch-sensitive - but we won’t consider “Parent” as an event target until we have ruled out using one of its children’s extended capture zones. The capture radius could either be a styleable property on the nodes, or could be determined by the X and Y size of a touch point as reported by the touch screen. We’d still be reporting a touch point, not a touch area. The touch target would be, as now, a single node. This would get us more reliable touch capture at leaf nodes of the node hierarchy at the expense of it being harder to tap the background. This is likely to be a good trade-off. Daniel Tomas Maybe the draw order / order in the scene graph / z buffer value might be sufficient to model what would happen in the real, physical world. Am 11.11.2013 13:05 schrieb Assaf Yavnai assaf.yav...@oracle.com mailto:assaf.yav...@oracle.com: 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
Re: CFV: New OpenJFX Committer: Rafi Tayar
Vote: Yes Daniel On Nov 5, 2013, at 5:59 PM, David Hill david.h...@oracle.com wrote: [ resending it with a corrected subject line. The dangers of reusing a form] I hereby nominate Rafi Tayar to OpenJFX Committer. Rafi is a member of JavaFX Embedded team at Oracle. Rafi's changes are in Glass/Lens support code: hg log -M -u Rafi Tayar An incomplete list of Rafi's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=tayar Votes are due by Nov 19, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
Re: CFV: New OpenJDK Committer: Lisa Selle
Vote: yes Daniel On Sep 25, 2013, at 6:30 PM, Artem Ananiev artem.anan...@oracle.com wrote: I hereby nominate Lisa Selle to OpenJFX Committer. Lisa is a member of JavaFX Embedded team. Her changes are all over the JavaFX code, from cursors and input events to makefiles and virtual keyboard. The list of Lisa's commits in the workspace: hg log -u Lisa Selle hg log -u Lisa.Selle Incomplete list is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle Votes are due to Oct 09, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: CFV: New OpenJFX Committer: Joseph Andresen
Vote: yes Daniel On Sep 25, 2013, at 6:17 PM, Artem Ananiev artem.anan...@oracle.com wrote: I hereby nominate Joe Andresen to OpenJFX Committer. Joe is a member of JavaFX Graphics team at Oracle. His first changeset in Prism is dated by 2009, and total number of commits is close to one hundred. Full list of Joe's changesets in the open workspace is available from command line: hg log -u Joseph Andresen Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
