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 +
Re: Exposing native surface or opengl handle
Hey all, it's great to have a new thread like this. Robert exactly pointed out what we actually need. I have seen an approach to integrate JFX in JOGL and vice versa. This approach is always been a copying of the pixel buffers between those two frameworks. From my perspective this is not a real good approach because of obvious performance issues. Yesterday, I had a better idea. my idea: I know it is very hard to have JFX exposing a real GLCanvas/Context. I used JOGL for quite some time and I know the JFX rendering pipeline a bit. Please correct me if I am wrong. The most applications need some point to draw. The best pointer would be an exposed FBO from Prism that can be used by Jogl/LWJGL. Additionally we would need a possibility to share the JFX OGL-Context with another one, so we could reuse this FBO in a second window. Okay, this wouldn't needed if I could share textures over scenes. I know there is one major limitation. In windows Prism is using DirectX by default, so there won't be a possible interaction with Jogl. I am sure some DirectX guys really like to have there hands on the surface-layer as well ;) Well, to used the Jogl way above we would also need a stable OGL implementation of Prism for Windows. Last time I tried it it was not even comparable. I am not sure why, but OGL on Mac and Linux works pretty good. Matthias -- Matthias Hänel Geschäftsführer/ Managing Director UltraMixer Digital Audio Solutions Am Waldschlößchen 2 01099 Dresden - i...@ultramixer.com http://www.ultramixer.com Am 23.06.2014 um 17:43 schrieb Robert Krüger krue...@lesspain.de: Thanks a lot for the valuable and very encouraging info! I will track that issue and use that for further communication. Robert On Mon, Jun 23, 2014 at 5:15 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: I'm sorry this thread scrolled away into the bitbucket in the sky. Last JavaOne, we wrote a prototype that showed native integration on OS X. We parented a native sheet dialog in an FX stage and providing an OpenGL node. The code was a prototype that worked only on OS X. The Open GL node allowed drawing JOGL and LWJGL to draw on a texture that was created by FX. This mean that the OpenGL node could take part in FX animations and effects. I will attach the prototype code to https://javafx-jira.kenai.com/browse/RT-36215. I need to find it and make sure that it still compiles and works. This week is M5 RDP2 and today is likely to be a write off for a number of reasons. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Please ping me in the JIRA if the code doesn't show up sometime this week. The prototype is the basis of one possible implementation and needs some work. There are other possible implementations and this is not the final word on the issue. Steve On 2014-06-23, 10:03 AM, Robert Krüger wrote: Sorry, my last reply did not go to the list. That was unintended. Oracle-Team, please someone comment on this, at least on what should be done regarding a Jira Issue (or several ones?) to track any progress on this and collect ideas requirements. Best regards, Robert On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger krue...@lesspain.de wrote: Thanks for the hint. I think this is similar to what a colleague of mine did a while ago as a proof of concept using other com.sun.api that then went away. As long as we're bundling the JRE with our product and we're desperate enough to get it working, we might do something like this but it's of course just a last resort. Lets hope someone from Oracle says something. On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer swpal...@gmail.com wrote: That’s basically it. It isn’t perfect, but its so simple I don’t see why it can’t be done quickly. We are already talking about using native code to render. That said, com.sun.glass.ui.Window contains the field we want: // Native object handle (HWND, or NSWindow*, etc.) long ptr; You could be evil and hack it now with reflection, but it relies on internal implementation details. In my application I already create a native window for video preview… though not as a child of the FX window. The problem is that there isn’t a straight-forward, reliable, supported way to get the window handle to use for the parent (JavaFX) window. There are ways to hack it, but they aren’t pretty. Scott On Jun 13, 2014, at 7:55 AM, Robert Krüger krue...@lesspain.de wrote: Just for my understanding: Your approach would be to get the native window handle for the hosting JFX stage, then leave an open space in the layout for e.g. the player canvas that will be implemented natively and then create a native child window that just reacts to move and resize events of its native parent? On Fri,
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
hg: openjfx/8u-dev/rt: RT-37639: Gtk: dead keys don't work on European keyboard layouts
Changeset: a193ba23a602 Author:Anthony Petrov anthony.pet...@oracle.com Date: 2014-06-25 18:09 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a193ba23a602 RT-37639: Gtk: dead keys don't work on European keyboard layouts Summary: Enable/disable IM on focus gained/lost events Reviewed-by: azvegint Contributed-by: Alexander Zvegintsev alexander.zvegint...@oracle.com ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp
Re: Windows updates might damage the build
Thanks for posting this.I know a few others have run into this before, too (including me a couple months ago). We should put this on the Wiki. -- Kevin Jann Schneider wrote: Hi all, I just wanted to share this info in case someone else runs into this Problems: Yesterday i got some updates on my Windows 7. Afterwards i wasn't able to build jfx anymore. Just got a linker error (lnk 1123). After googling around a bit for this stuff it turned out that there is an update for the update ;-) You'll just have to install the Service pack 1 for Visual Studio 2010 in order to make it work again. (you can get it via the MS download Center) After installing that patch the build works fine again. Regards Jann!
Re: Testing accessibility / sample apps
I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider jann.schnei...@googlemail.com: Yes looks like i have an issue with looking up cl.exe. This was the output when running with --stacktrace: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:buildJavaPackager'. ... Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' ... Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe'' ... Caused by: java.io.IOException: Cannot run program C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe (in directory D:\jann\sandbox\java\openjfx\modules\fxpackager): CreateProcess error=2, Das System kann die angegebene Datei nicht finden ... Caused by: java.io.IOException: CreateProcess error=2, Das System kann die angegebene Datei nicht finden (file not found) Actually cl.exe is located at: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin - but it looks for ...bin/amd64/cl.exe I've also tried to run the build from the cygwin terminal and as well from the visual studio command prompt where i could call cl.exe directly .. Always the same result. Is there a parameter to specify where theVS compiler and stuff is located? btw. i checked that the %VS100COMNTools% variable is set properly. What else could i check? Thanks in advance :) Jann 2014-06-20 23:30 GMT+02:00, Kevin Rushforth
Re: Testing accessibility / sample apps
Ok thx Am 25.06.2014 16:51 schrieb Kevin Rushforth kevin.rushfo...@oracle.com: I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com : Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider jann.schnei...@googlemail.com: Yes looks like i have an issue with looking up cl.exe. This was the output when running with --stacktrace: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:buildJavaPackager'. ... Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' ... Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe'' ... Caused by: java.io.IOException: Cannot run program C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe (in directory D:\jann\sandbox\java\openjfx\modules\fxpackager): CreateProcess error=2, Das System kann die angegebene Datei nicht finden ... Caused by: java.io.IOException: CreateProcess error=2, Das System kann die angegebene Datei nicht finden (file not found) Actually cl.exe is located at: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin - but it looks for ...bin/amd64/cl.exe I've also tried to run the build from the cygwin terminal and as well from the visual studio command prompt where i could call cl.exe directly .. Always the same result. Is there a parameter to specify where theVS compiler and stuff is located? btw. i checked
Re: Testing accessibility / sample apps
I think you also need to spec the native-dlls location else there's the chance of a mismatch because the dlls are loaded from the JRE and might not match the java-classes. Tom On 25.06.14 16:51, Kevin Rushforth wrote: I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider jann.schnei...@googlemail.com: Yes looks like i have an issue with looking up cl.exe. This was the output when running with --stacktrace: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:buildJavaPackager'. ... Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' ... Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe'' ... Caused by: java.io.IOException: Cannot run program C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe (in directory D:\jann\sandbox\java\openjfx\modules\fxpackager): CreateProcess error=2, Das System kann die angegebene Datei nicht finden ... Caused by: java.io.IOException: CreateProcess error=2, Das System kann die angegebene Datei nicht finden (file not found) Actually cl.exe is located at: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin - but it looks for ...bin/amd64/cl.exe I've also tried to run the build from the cygwin terminal and as well from the visual studio
Re: Testing accessibility / sample apps
If you use build/sdk/rt/lib/ext/jfxrt.jar then it will find the corresponding DLLs, but if you use the built class files rather than jfxrt.jar then you are right in that you need to specify -Djava.library.path to point to the native DLLs. -- Kevin Tom Schindl wrote: I think you also need to spec the native-dlls location else there's the chance of a mismatch because the dlls are loaded from the JRE and might not match the java-classes. Tom On 25.06.14 16:51, Kevin Rushforth wrote: I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider jann.schnei...@googlemail.com: Yes looks like i have an issue with looking up cl.exe. This was the output when running with --stacktrace: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:buildJavaPackager'. ... Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' ... Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe'' ... Caused by: java.io.IOException: Cannot run program C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe (in directory D:\jann\sandbox\java\openjfx\modules\fxpackager): CreateProcess error=2, Das System kann die angegebene Datei nicht finden ... Caused by: java.io.IOException: CreateProcess error=2, Das System kann die angegebene Datei nicht finden (file not found)
Re: Testing accessibility / sample apps
The following line of crap works for me on Windows to run Ensemble: java -cp /Users/Steve/Documents/jfx-8u20/jfx/rt/build/sdk/rt/lib/ext/jfxrt.jar;/Users/Steve/Documents/jfx-8u20/jfx/rt/apps/samples/Ensemble8/dist/Ensemble8.jar ensemble.EnsembleApp I just checked the wiki and it's not documented. I will update it. Steve On 2014-06-25, 11:04 AM, Kevin Rushforth wrote: If you use build/sdk/rt/lib/ext/jfxrt.jar then it will find the corresponding DLLs, but if you use the built class files rather than jfxrt.jar then you are right in that you need to specify -Djava.library.path to point to the native DLLs. -- Kevin Tom Schindl wrote: I think you also need to spec the native-dlls location else there's the chance of a mismatch because the dlls are loaded from the JRE and might not match the java-classes. Tom On 25.06.14 16:51, Kevin Rushforth wrote: I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider jann.schnei...@googlemail.com: Yes looks like i have an issue with looking up cl.exe. This was the output when running with --stacktrace: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:buildJavaPackager'. ... Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' ... Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/amd64/cl.exe'' ... Caused by: java.io.IOException: Cannot run program C:/Program Files (x86)/Microsoft Visual
Re: Testing accessibility / sample apps
While you are there, if the Wiki doesn't already say it (I think it does) then note that this presumes you have removed jfxrt.jar from the jre/lib/ext directory of your JDK. -- Kevin Stephen F Northover wrote: The following line of crap works for me on Windows to run Ensemble: java -cp /Users/Steve/Documents/jfx-8u20/jfx/rt/build/sdk/rt/lib/ext/jfxrt.jar;/Users/Steve/Documents/jfx-8u20/jfx/rt/apps/samples/Ensemble8/dist/Ensemble8.jar ensemble.EnsembleApp I just checked the wiki and it's not documented. I will update it. Steve On 2014-06-25, 11:04 AM, Kevin Rushforth wrote: If you use build/sdk/rt/lib/ext/jfxrt.jar then it will find the corresponding DLLs, but if you use the built class files rather than jfxrt.jar then you are right in that you need to specify -Djava.library.path to point to the native DLLs. -- Kevin Tom Schindl wrote: I think you also need to spec the native-dlls location else there's the chance of a mismatch because the dlls are loaded from the JRE and might not match the java-classes. Tom On 25.06.14 16:51, Kevin Rushforth wrote: I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider jann.schnei...@googlemail.com: Yes looks like i have an issue with looking up cl.exe. This was the output when running with --stacktrace: * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':fxpackager:buildJavaPackager'. ... Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' ... Caused by: java.util.concurrent.ExecutionException:
hg: openjfx/8u/rt: Added tag 8u20-b20 for changeset c771f928a886
Changeset: 10c61801aaab Author:hudson Date: 2014-06-25 09:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8u/rt/rev/10c61801aaab Added tag 8u20-b20 for changeset c771f928a886 ! .hgtags
Re: Testing accessibility / sample apps
When in doubt you can always specify -Djavafx.verbose=true and observed the libraries are begin loaded. In Steve’s example you should see something like Loaded /Users/Steve/Documents/jfx-8u20/jfx/rt/build/sdk/rt/lib/libglass.dylib … Felipe On Jun 25, 2014, at 8:51 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: While you are there, if the Wiki doesn't already say it (I think it does) then note that this presumes you have removed jfxrt.jar from the jre/lib/ext directory of your JDK. -- Kevin Stephen F Northover wrote: The following line of crap works for me on Windows to run Ensemble: java -cp /Users/Steve/Documents/jfx-8u20/jfx/rt/build/sdk/rt/lib/ext/jfxrt.jar;/Users/Steve/Documents/jfx-8u20/jfx/rt/apps/samples/Ensemble8/dist/Ensemble8.jar ensemble.EnsembleApp I just checked the wiki and it's not documented. I will update it. Steve On 2014-06-25, 11:04 AM, Kevin Rushforth wrote: If you use build/sdk/rt/lib/ext/jfxrt.jar then it will find the corresponding DLLs, but if you use the built class files rather than jfxrt.jar then you are right in that you need to specify -Djava.library.path to point to the native DLLs. -- Kevin Tom Schindl wrote: I think you also need to spec the native-dlls location else there's the chance of a mismatch because the dlls are loaded from the JRE and might not match the java-classes. Tom On 25.06.14 16:51, Kevin Rushforth wrote: I usually add jfxrt.jar to the bootclasspath, but as long as you have removed jfxrt.jar from your JDK, classpath will work, too. -- Kevin Jann Schneider wrote: Hi Felipe! thanks, this are good News :-) Well yesterday i had some issues with the build bc the famous Windows updates Feature screwed things up .. however, i've recently fixed it so i'll try it today. Just another question concerning testing with the build from sources: i guess i can just run the example apps located in openjfx/apps/ ? What would be the proper way to invoke one of them and make sure the proper jfx is loaded? Do i have to add it to the boot cp? Or is it enough to just put it on the classpath? Regards Jann 2014-06-25 7:17 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, I have re-enabled all the accessibility code in hg.openjdk.java.net/openjfx/8u-dev/rt Notes: I have also released the fix for JAWS (RT-37530). But before testing text edits you will need to add a setting to JAWS, see https://javafx-jira.kenai.com/browse/RT-37609 You still need the -Djavafx.accessible.force=true on Windows 7, but very soon that will not be needed anymore, see: https://javafx-jira.kenai.com/browse/RT-37702 Internally we did virtually all our testing using Narrator and VoiceOver, which are the native screen readers on Windows and MacOSX respectively. I believe you will be the first to try JAWS and NVDA on Windows 7. Let me know how it goes. Regards Felipe On Jun 23, 2014, at 3:50 AM, Jann Schneider jann.schnei...@googlemail.com wrote: Hi Felipe, i tried with the latest available EA build, java -version tells me: java version 1.8.0_20-ea Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b19) Java HotSpot(TM) Client VM (build 25.20-b19, mixed mode, sharing) Also i used Jaws 15 (-.0.9 i think) and as an alternative NVDA 14.2. Hum, not quite sure about the narrator tool: i guess thats the one that shipps with windows? Well i can try this too though i'm not really used to it :) Maybe it's better to just wait until the code is back and test with the current sources.. So we have the same base and know exactly what we expect for the tests. Regards Jann 2014-06-21 5:16 GMT+02:00, Felipe Heidrich felipe.heidr...@oracle.com: Hi Jann, That is great that you got to build JavaFX, it will make much easier to test patches and fixes going forward. That said, assuming that you downloaded jdk1.8.0_20 b19 or less, accessibility should have worked. What is the output of java -version ? Can you try Narrator ? I’ll put the code back early next week, either Monday or Tuesday. You can track the progress here: https://javafx-jira.kenai.com/browse/RT-37536 I’ll email the list when the code is out. Regards, Felipe On Jun 20, 2014, at 4:00 PM, Jann Schneider jann.schnei...@googlemail.com wrote: ok i just rebuild using the 32 bit jdk and this works! $ gradle clean sdk ... BUILD SUCCESSFUL :-) I think i've just installed the 32 bit C++ compilers only. Maybe i missed a setting in the installer of visual studio .. btw. i build with the VS 2010 express (as suggested at the wiki). So i'll wait until the accessibility portion is back in the repo and try with that included then. Thanks for your help so fahr! @Steve: could you please send a short message to the list if the accessibility sources are in the repo again? Regards Jann 2014-06-20 23:50 GMT+02:00, Jann Schneider
hg: openjfx/8u-dev/rt: RT-37702: [Accessibility] enable a11y by default on supported platforms
Changeset: a4b44bda860f Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-25 09:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a4b44bda860f RT-37702: [Accessibility] enable a11y by default on supported platforms ! modules/graphics/src/main/java/com/sun/glass/ui/View.java
hg: openjfx/8u-dev/rt: [Accessibility] Change Attribute.ENABLED to Attribute.DISABLED (so match JavaFX name Node#isDisabled())
Changeset: 758e1f790da3 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-25 09:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/758e1f790da3 [Accessibility] Change Attribute.ENABLED to Attribute.DISABLED (so match JavaFX name Node#isDisabled()) ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Attribute.java
hg: openjfx/8u-dev/rt: [Accessibility] Change Attribute.ENABLED to Attribute.DISABLED - missed ContextMenuContent.java
Changeset: d74b74fe1442 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-25 09:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d74b74fe1442 [Accessibility] Change Attribute.ENABLED to Attribute.DISABLED - missed ContextMenuContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java
Re: JavaFX at JavaOne 2014
For those who worry, Applications created with the JavaFX Android SDK work fine on ART (as expected). After all, we're following Android's rules. - Johan 2014-06-23 20:31 GMT+02:00 John Smith john_sm...@symantec.com: I don't know much about Android, but does it have to be a VM, or could you use ART or an ART equivalent: http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life https://source.android.com/devices/tech/dalvik/art.html John -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Herve Girod Sent: Monday, June 23, 2014 8:20 AM To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: Re: JavaFX at JavaOne 2014 There are no reasons that JavaFX could not work well on mobile platforms, providing there is a JVM. I was convinced that mobile UI toolkits were very specific, but it's really not the case. Android UI Toolkit has really very few mobile specificities for example. 2014-06-23 16:46 GMT+02:00 Pedro Duque Vieira pedro.duquevie...@gmail.com : People have tried HTML5 as a way to create apps for mobile platforms. Most of the big names who tried this e.g. Facebook have abandoned it. They've abandoned it but not because of the reasons you imply but rather due to HTML5 limitations of providing a good native experience in regards to performance, fluid animations, etc. And also there's a reason why all of them started using HTML5 in the first place: faster delivery time. You only need a code base and with few small adjustments can deliver an app for all mobile platforms. Later you can start concentrating on delivering the best experience on each platform. BTW I don't think JavaFX can fade away given that it's starting from obscurity already ;) Truth is the world lacks a convincing cross platform UI toolkit at the moment: there's Qt, which is fine for C++ but is not so pleasant from other languages, there's Swing, there's HTML5. JavaFX is already undoubtedly one of the best cross platform (desktop cross platform) UI toolkits out there. But that isn't enough as desktop is becoming less and less important. Thanks, On Mon, Jun 23, 2014 at 12:17 PM, Mike Hearn m...@plan99.net wrote: If it is correct that JavaFX won't be supporting iOS or Android (officially), IMO JavaFX will start fading away as soon as there is a reliable technology that can create apps for all platforms. People have tried HTML5 as a way to create apps for mobile platforms. Most of the big names who tried this e.g. Facebook have abandoned it. Personally, I don't care much about JavaFX on Android or iOS because mobile has such different UI requirements and conventions to desktop platforms. I can write a JFX GUI that looks and feels good across Mac/Win/Linux with very little platform specific code because those platforms are all quite similar and anyway, the respective developers of those platforms trained users to expect apps to not fit in perfectly. On mobile, things are different: you can't just use a desktop UI, you need a totally new UI and maybe even feature set built from scratch. On Android the UI toolkit is closely linked with the lifecycle rules. And UI's tend to be a lot more consistent, with the worst offenders being apps that weren't updated to the latest UI conventions yet rather than apps which simply reinvent the look and feel from scratch. I'd actually prefer that Oracle focuses on making a great desktop solution. Hype aside there are still many apps not appropriate for mobiles or tablets. Then with a Java or JVM-language backend I can have just two UI codebases, one for desktop, one for Android and that gets most mobiles. Then RoboVM's Cocoa bindings can be used if need be for iOS. BTW I don't think JavaFX can fade away given that it's starting from obscurity already ;) Truth is the world lacks a convincing cross platform UI toolkit at the moment: there's Qt, which is fine for C++ but is not so pleasant from other languages, there's Swing, there's HTML5. Both Swing and Qt have a reputation for making ugly GUI's. That may or may not be deserved these days, but people remember the history. Plus deployment is horrible. That leaves HTML5, which despite its manifest limitations at least can be made to easily look good via CSS, follow modern fashions, work on everyone's computers and people don't have to download an extra app runtime. So for many apps it's appropriate especially when the bulk of the app logic runs on a server. JavaFX 8, at least based on my experience so far, can be used to make attractive and web-style UIs, thus matching the first of HTML5's capabilities, plus it has the benefit of actually being designed, unlike
hg: openjfx/8u-dev/rt: [Accessibility] Rename Roles to use underline where the JavaFX uses camelCase
Changeset: 8656132b02f6 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-25 10:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8656132b02f6 [Accessibility] Rename Roles to use underline where the JavaFX uses camelCase ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java ! modules/controls/src/main/java/javafx/scene/control/CheckBox.java ! modules/controls/src/main/java/javafx/scene/control/ChoiceBox.java ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/controls/src/main/java/javafx/scene/control/ToolBar.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Role.java ! modules/graphics/src/main/java/javafx/scene/image/ImageView.java
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: 10c61801aaab Author:hudson Date: 2014-06-25 09:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/10c61801aaab Added tag 8u20-b20 for changeset c771f928a886 ! .hgtags Changeset: 7312e6321ffa Author:kcr Date: 2014-06-25 11:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7312e6321ffa Automated merge with ssh://hg.openjdk.java.net/openjfx/8u/rt - .idea/rt-tests.iml - modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanAcceleratedScreen.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanCursor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanPlatform.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanPlatformFactory.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanScreen.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessPlatform.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessPlatformFactory.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/InputDevice.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/InputDeviceRegistry.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/KeyInput.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/KeyState.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/MouseInput.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/MouseInputSynthesizer.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/MouseState.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/TouchInput.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/TouchState.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/filters/AssignPointIDTouchFilter.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/filters/LookaheadTouchFilter.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/filters/NearbyPointsTouchFilter.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/filters/SmallMoveTouchFilter.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/filters/TouchFilter.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/filters/TouchPipeline.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/AbsoluteInputCapabilities.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/FBDevScreen.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/GetEvent.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/Input.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/KeyBits.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxEventBuffer.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxEventBuffers.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxFrameBuffer.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxInputDevice.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxInputDeviceRegistry.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxInputProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxKeyProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxMouseProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxPlatform.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxPlatformFactory.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxSimpleTouchProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxStatefulMultiTouchProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxStatelessMultiTouchProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxSystem.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxTouchProcessor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxTouchTransform.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/SysFS.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/Udev.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/UdevListener.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6AcceleratedScreen.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6Cursor.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6Platform.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6PlatformFactory.java - modules/graphics/src/main/java/com/sun/glass/ui/monocle/omap/OMAPCursor.java -
RE: Exposing native surface or opengl handle
Here's a link to Steve and Felipe's JavaOne presentation: http://www.parleys.com/play/524ee4dbe4b0ab14e307d7b1/about Integrating JavaFX with Native Technologies This session examines ways that applications can extend JavaFX to use native technologies, with a focus on OpenGL. It's such a great presentation. Some people do such good work. -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Matthias Hänel Sent: Wednesday, June 25, 2014 12:43 AM To: Robert Krüger Cc: openjfx-dev@openjdk.java.net Subject: Re: Exposing native surface or opengl handle Hey all, it's great to have a new thread like this. Robert exactly pointed out what we actually need. I have seen an approach to integrate JFX in JOGL and vice versa. This approach is always been a copying of the pixel buffers between those two frameworks. From my perspective this is not a real good approach because of obvious performance issues. Yesterday, I had a better idea. my idea: I know it is very hard to have JFX exposing a real GLCanvas/Context. I used JOGL for quite some time and I know the JFX rendering pipeline a bit. Please correct me if I am wrong. The most applications need some point to draw. The best pointer would be an exposed FBO from Prism that can be used by Jogl/LWJGL. Additionally we would need a possibility to share the JFX OGL-Context with another one, so we could reuse this FBO in a second window. Okay, this wouldn't needed if I could share textures over scenes. I know there is one major limitation. In windows Prism is using DirectX by default, so there won't be a possible interaction with Jogl. I am sure some DirectX guys really like to have there hands on the surface-layer as well ;) Well, to used the Jogl way above we would also need a stable OGL implementation of Prism for Windows. Last time I tried it it was not even comparable. I am not sure why, but OGL on Mac and Linux works pretty good. Matthias -- Matthias Hänel Geschäftsführer/ Managing Director UltraMixer Digital Audio Solutions Am Waldschlößchen 2 01099 Dresden - i...@ultramixer.com http://www.ultramixer.com Am 23.06.2014 um 17:43 schrieb Robert Krüger krue...@lesspain.de: Thanks a lot for the valuable and very encouraging info! I will track that issue and use that for further communication. Robert On Mon, Jun 23, 2014 at 5:15 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: I'm sorry this thread scrolled away into the bitbucket in the sky. Last JavaOne, we wrote a prototype that showed native integration on OS X. We parented a native sheet dialog in an FX stage and providing an OpenGL node. The code was a prototype that worked only on OS X. The Open GL node allowed drawing JOGL and LWJGL to draw on a texture that was created by FX. This mean that the OpenGL node could take part in FX animations and effects. I will attach the prototype code to https://javafx-jira.kenai.com/browse/RT-36215. I need to find it and make sure that it still compiles and works. This week is M5 RDP2 and today is likely to be a write off for a number of reasons. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Please ping me in the JIRA if the code doesn't show up sometime this week. The prototype is the basis of one possible implementation and needs some work. There are other possible implementations and this is not the final word on the issue. Steve On 2014-06-23, 10:03 AM, Robert Krüger wrote: Sorry, my last reply did not go to the list. That was unintended. Oracle-Team, please someone comment on this, at least on what should be done regarding a Jira Issue (or several ones?) to track any progress on this and collect ideas requirements. Best regards, Robert On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger krue...@lesspain.de wrote: Thanks for the hint. I think this is similar to what a colleague of mine did a while ago as a proof of concept using other com.sun.api that then went away. As long as we're bundling the JRE with our product and we're desperate enough to get it working, we might do something like this but it's of course just a last resort. Lets hope someone from Oracle says something. On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer swpal...@gmail.com wrote: That's basically it. It isn't perfect, but its so simple I don't see why it can't be done quickly. We are already talking about using native code to render. That said, com.sun.glass.ui.Window contains the field we want: // Native object handle (HWND, or NSWindow*, etc.) long ptr; You could be evil and hack it now with reflection, but it relies on internal implementation details. In my application I already create a native window for video preview. though not
hg: openjfx/8u-dev/rt: RT-37599: Creation of a DMG from an APP is broken (scpt fails)
Changeset: 296d878c295d Author:shemnon Date: 2014-06-25 14:25 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/296d878c295d RT-37599: Creation of a DMG from an APP is broken (scpt fails) Summary: Re-work script to depend on posix file name instead of finder presented name. ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java ! modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/DMGsetup.scpt
hg: openjfx/8u-dev/rt: [Accessibility] Replace Attributes.MENU_ITEM_TYPE with Roles RADIO_MENU_ITEM, CHECK_MENU_ITEM, and MENU
Changeset: 85685c1fe33e Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-25 16:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/85685c1fe33e [Accessibility] Replace Attributes.MENU_ITEM_TYPE with Roles RADIO_MENU_ITEM, CHECK_MENU_ITEM, and MENU ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Attribute.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Role.java
hg: openjfx/8u-dev/rt: [Accessibility] Follow-up of RT-37609. More bad casts in GlassTextRangeProvider.cpp
Changeset: 32c05f70d24a Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-25 17:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/32c05f70d24a [Accessibility] Follow-up of RT-37609. More bad casts in GlassTextRangeProvider.cpp ! modules/graphics/src/main/native-glass/win/GlassTextRangeProvider.cpp
hg: openjfx/2u/dev/rt: Added tag 2.2.80-b01 for changeset 861ad6a6305c
Changeset: 4a686b248383 Author:hudson Date: 2014-06-25 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/4a686b248383 Added tag 2.2.80-b01 for changeset 861ad6a6305c ! .hgtags
