hg: openjfx/8u-dev/rt: [doc-only] Fix RT-37611: GraphicsContext methods are poorly documented.
Changeset: c771f928a886 Author:flar james.gra...@oracle.com Date: 2014-06-23 00:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c771f928a886 [doc-only] Fix RT-37611: GraphicsContext methods are poorly documented. ! modules/graphics/src/main/java/javafx/scene/canvas/GraphicsContext.java
WebView and Dygraph
I have a problem with WebView, it can't display charts with Dygraph: http://dygraphs.com/gallery/#g/annotations Lines are not visible: http://piccy.info/view3/6591894/dfeafc2dc2af39ed0760afcb9d508546/ The same page loaded in QtWeb browser (also based on Webkit): http://piccy.info/view3/6591897/6216c3ba4fd54e3c908ecc0380c323bd/
Re: Testing accessibility / sample apps
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 kevin.rushfo...@oracle.com: * What went wrong: Execution failed for task ':fxpackager:buildJavaPackager'. Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' When I've seen this in the past it's been related to the compiler install. Do you have VS 2010 SP1 or something else? -- Kevin Jann Schneider wrote: Hi, Well on windows it's always a bit more difficult i guess :-) After setting up my build environment as described on the wiki i first tried $ gradle tasks This works as expected! When running $ gradle sdk or just gradle without any target i get the following error: FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':fxpackager:buildJavaPackager'. Could not call NativeCompileTask.compile() on task ':fxpackager:buildJavaPackager' Is this a known issue and do you know what's going wrong here? Should i post more info or debug output, too? Thanks Jann 2014-06-20 21:58 GMT+02:00, Stephen F Northover steve.x.northo...@oracle.com: Being non-Unix, Windows is always a pain. Steve On 2014-06-20, 3:42 PM, Kevin Rushforth wrote: I hope you have similar success with the Windows build. -- Kevin Jann Schneider wrote: Hi all, The build instructions for linux where very good! I was able to build the project without any problems. Regards Jann 2014-06-20 19:27 GMT+02:00, Kevin Rushforth kevin.rushfo...@oracle.com: To be clear, you will still use the 8u-dev repo at the existing URL:
Re: WebView and Dygraph
Please file a bug at https://javafx-jira.kenai.com/secure/CreateIssue!default.jspa -- best regards, Anthony On 6/23/2014 1:53 PM, edartuz wrote: I have a problem with WebView, it can't display charts with Dygraph: http://dygraphs.com/gallery/#g/annotations Lines are not visible: http://piccy.info/view3/6591894/dfeafc2dc2af39ed0760afcb9d508546/ The same page loaded in QtWeb browser (also based on Webkit): http://piccy.info/view3/6591897/6216c3ba4fd54e3c908ecc0380c323bd/
Re: JavaFX at JavaOne 2014
Community members such as Gerrit Grunwald have already demonstrated an application with a single JavaFX code base running on Windows, MacOS, Linux, Android, iOS and even Raspberry Pi. BTW, I totally disagree with you on your comments about the similarities of the desktop UIs and some sort of unique, device-specific UI on mobiles and tablets. The truth is, the desktop OS UIs are vastly more sophisticated than phone or tablet UIs and much harder to make look good in a cross-platform way. By contrast, there is usually very little to the actual native look and feel of iOS or Android and skinning a JavaFX app and supporting touch/gesture interfaces etc. is comparatively much easier. I think it's fair to say that (random) iOS apps 1 2 will typically look more different from each other than Windows apps 1 2. There is no point in focusing exclusively on a desktop solution as the majority of *new* app/application development is occurring in mobile and embedded space. It's true that there are several classes of application that will *always* require a desktop OS but we must move forward and ensure that JavaFX apps achieve a separation score of zero when evaluated against my 6 Degrees of Separation defined here: http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation/ To me, JavaFX is the Holy Grail we have been looking for... or at least it *will* be when the iOS and Android ports are kicking arse. And I have *every* confidence in those fine people looking after those ports that they can do just that. Felix On 23 June 2014 21:17, 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 HTML which just evolved. This leaves deployment as the primary problem. For this reason Danno is my current fav member of the JavaFX team :) Nothing personal guys, I just see cross-platform deployment of *reasonable sized* apps to be the biggest competitive weakness right now.
Re: Exposing native surface or opengl handle
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, Jun 13, 2014 at 1:48 PM, Scott Palmer swpal...@gmail.com wrote: This is critical, but I don't think we need to focus on a specific technology like Direct3D or OpenGL. As a first step all we need is a mechanism to get a native reference to the Window. Just like we can with JAWT. I'm guessing that JavaFX doesn't use heavyweight child windows so we could add a new child window that we manage with our own code and it would appear on top of the JavaFX content. Scott On Jun 13, 2014, at 3:08 AM, Felix Bembrick felix.bembr...@gmail.com wrote: I absolutely agree that such a feature is critical for the success and longevity of JavaFX. I am *really* hoping for some heavily beefed-up 3D support in a JFX 8.* release or JFX 9. I need my graphics toolkit (currently JavaFX) to be able to handle everything from simple UIs with basic controls to complex 3D visualisations, just like the underlying graphics API is capable of (i.e. OpenGL or Direct3D). I strongly suspect though that focusing on OpenGL exclusively is the only viable way to go from a cost perspective which would mean JavaFX supporting OpenGL on Windows. On 13 June 2014 16:57, Robert Krüger krue...@lesspain.de wrote: Hi, it has been discussed a number of time in the passed but let me quickly summarize: A number of people have requested a feature that provides the ability to have native code draw into a surface provided by a JavaFX application as fast as technically possible, i.e. with no indirection or copying because use cases for this were mostly cases where performance was critical, e.g. HD/UHD video players, real-time visualization etc. where losing even e few percent would make a software written in JavaFX unable to compete with native products (e.g. in the video area nobody will use a video player that is not able to play the content smoothly that VLC player or Quicktime can on the same machine). Some people already have libraries of native code that they have built over the years and would like to reuse. I would even go so far to say that our product will probably never be able to move to JFX (apart from mixing it a bit with Swing, which we currently see rather aa a migration strategy and not as the end result) without this problem solved. In the past the reactions/signals from the Oracle team in this respect were mixed but some of it indicated that this topic was discussed in the past and might be revisited after the release of JFX 8. Now that the latter has happened I would like to ask what the plans for this are. Is there a Jira Issue where we can track the progress of it? If not, does it make sense if I open one, so people (probably the same ones that have participated in these discussions in the past like Scott and the Ultramixer guys etc.) can collect their requirements/thoughts? Even if Oracle should decide not to do something about it, it would still be nice to get pointers in the code base to where this would be possible, even if it is non-portable. I know that for our product it
Re: JavaFX at JavaOne 2014
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 HTML which just evolved. This leaves deployment as the primary problem. For this reason Danno is my current fav member of the JavaFX team :) Nothing personal guys, I just see cross-platform deployment of *reasonable sized* apps to be the biggest competitive weakness right now. -- Pedro Duque Vieira
Re: Exposing native surface or opengl handle
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, Jun 13, 2014 at 1:48 PM, Scott Palmer swpal...@gmail.com wrote: This is critical, but I don't think we need to focus on a specific technology like Direct3D or OpenGL. As a first step all we need is a mechanism to get a native reference to the Window. Just like we can with JAWT. I'm guessing that JavaFX doesn't use heavyweight child windows so we could add a new child window that we manage with our own code and it would appear on top of the JavaFX content. Scott On Jun 13, 2014, at 3:08 AM, Felix Bembrick felix.bembr...@gmail.com wrote: I absolutely agree that such a feature is critical for the success and longevity of JavaFX. I am *really* hoping for some heavily beefed-up 3D support in a JFX 8.* release or JFX 9. I need my graphics toolkit (currently JavaFX) to be able to handle everything from simple UIs with basic controls to complex 3D visualisations, just like the underlying graphics API is capable of (i.e. OpenGL or Direct3D). I strongly suspect though that focusing on OpenGL exclusively is the only viable way to go from a cost perspective which would mean JavaFX supporting OpenGL on Windows. On 13 June 2014 16:57, Robert Krüger krue...@lesspain.de wrote: Hi, it has been discussed a number of time in the passed but let me quickly summarize: A number of people have requested a feature that provides the ability to have native code draw into a surface provided by a JavaFX application as fast as technically possible, i.e. with no indirection or copying because use cases for this were mostly cases where performance was critical, e.g. HD/UHD video players, real-time visualization etc. where losing even e few percent would make a software written in JavaFX unable to compete with native products (e.g. in the video area nobody will use a video player that is not able to play the content smoothly that VLC player or Quicktime can on the same machine). Some people already have libraries of native code that they have built over the years and would like to reuse. I would even go so far to say that
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 HTML which just evolved. This leaves deployment as the primary problem. For this reason Danno is my current fav member of the JavaFX team :) Nothing personal guys, I just see cross-platform deployment of *reasonable sized* apps to be the biggest competitive weakness right now. -- Pedro Duque Vieira
Re: Exposing native surface or opengl handle
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, Jun 13, 2014 at 1:48 PM, Scott Palmer swpal...@gmail.com wrote: This is critical, but I don't think we need to focus on a specific technology like Direct3D or OpenGL. As a first step all we need is a mechanism to get a native reference to the Window. Just like we can with JAWT. I'm guessing that JavaFX doesn't use heavyweight child windows so we could add a new child window that we manage with our own code and it would appear on top of the JavaFX content. Scott On Jun 13, 2014, at 3:08 AM, Felix Bembrick felix.bembr...@gmail.com wrote: I absolutely agree that such a feature is critical for the success and longevity of JavaFX. I am *really* hoping for some heavily beefed-up 3D support in a JFX 8.* release or JFX 9. I need my graphics toolkit (currently JavaFX) to be able to handle everything from simple UIs with basic controls to complex 3D visualisations, just like the underlying graphics API is capable of (i.e. OpenGL or Direct3D). I strongly suspect though that focusing on OpenGL exclusively is the only viable way to go from a cost perspective which would mean JavaFX supporting OpenGL on Windows. On 13 June 2014 16:57, Robert Krüger krue...@lesspain.de wrote: Hi, it has been discussed a number of time in the passed but let me quickly summarize: A number of people have requested a feature that provides the ability to have native code draw into a surface provided by a JavaFX application as fast as technically possible, i.e. with no indirection or copying because use cases for this were mostly cases where performance was critical, e.g. HD/UHD video players, real-time visualization etc. where losing even e few percent would make a software written in JavaFX unable to compete with native products (e.g. in the video
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. It's not so much the toolkit, but the layouts. Yes, you could probably make a JavaFX that runs OK on iOS/Android though the API would be necessarily incompatible e.g. no inter-application drag and drop, only one stage, no exposed file system, very different ideas about menus and toolbars etc. But, you'd still need to design completely new layouts/FXMLs to handle the different screen sizes and conventions. And that probably means quite some changes to your controllers, CSS and animation code as well. In the end, you'd still need two versions of your app. The only difference is how much knowledge can be reused? Most of the code would be the same.
RE: JavaFX at JavaOne 2014
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 HTML which just evolved. This leaves deployment as the primary problem. For this reason Danno is my current fav member of the JavaFX team :) Nothing personal guys, I just see cross-platform deployment of *reasonable sized* apps to be the biggest competitive weakness right now.
hg: openjfx/8u-dev/rt: [CLEANUP] Update copyright year to 2014 in properties files
Changeset: 31915f16ec3d Author:kcr Date: 2014-06-23 17:19 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/31915f16ec3d [CLEANUP] Update copyright year to 2014 in properties files ! build.properties ! gradle.properties.template
Re: JavaFX at JavaOne 2014
That first article was so wrong about nearly everything mentioned in it that it made me want to vomit. On Jun 23, 2014, at 2:31 PM, John Smith john_sm...@symantec.com wrote: 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
hg: openjfx/8u-dev/rt: RT-37536: [Accessibility] Put a11y code back
Changeset: 451301b279ed Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-06-23 20:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/451301b279ed RT-37536: [Accessibility] Put a11y code back ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SliderSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/Button.java ! modules/controls/src/main/java/javafx/scene/control/ButtonBase.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/ComboBoxBase.java ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java ! modules/controls/src/main/java/javafx/scene/control/Hyperlink.java ! modules/controls/src/main/java/javafx/scene/control/Label.java ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! modules/controls/src/main/java/javafx/scene/control/MenuBar.java ! modules/controls/src/main/java/javafx/scene/control/MenuButton.java ! modules/controls/src/main/java/javafx/scene/control/Pagination.java ! modules/controls/src/main/java/javafx/scene/control/PasswordField.java ! modules/controls/src/main/java/javafx/scene/control/ProgressBar.java ! modules/controls/src/main/java/javafx/scene/control/ProgressIndicator.java ! modules/controls/src/main/java/javafx/scene/control/RadioButton.java ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/SplitMenuButton.java ! modules/controls/src/main/java/javafx/scene/control/TabPane.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TextArea.java ! modules/controls/src/main/java/javafx/scene/control/TextField.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java ! modules/controls/src/main/java/javafx/scene/control/ToggleButton.java ! modules/controls/src/main/java/javafx/scene/control/ToolBar.java ! modules/controls/src/main/java/javafx/scene/control/Tooltip.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java !
