Fwd: hg: openjfx/8/graphics/rt: RT-32032 Android: VM hangs when application finishes.
Tomas, which VM do you mean in this bug report ;)? Tobi Anfang der weitergeleiteten Nachricht: Von: hang...@oracle.com Betreff: hg: openjfx/8/graphics/rt: RT-32032 Android: VM hangs when application finishes. Datum: 6. August 2013 08:33:26 MESZ An: openjfx-dev@openjdk.java.net Changeset: 521cced8d920 Author:tb115823 tomas.branda...@oracle.com Date: 2013-08-06 08:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/521cced8d920 RT-32032 Android: VM hangs when application finishes. Detach correctly all threads. Send notification to FXActivity that VM has shutdown. ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java ! modules/graphics/src/android/java/com/oracle/dalvik/NativePipeReader.java ! modules/graphics/src/android/java/com/oracle/dalvik/VMLauncher.java ! modules/graphics/src/main/native-glass/lens/android/android.c ! modules/graphics/src/main/native-glass/lens/android/android.h ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.c ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c
Re: JavaFX and iOS - it will remain a dream
Yes Felix, it *has* to be this year…. We do not port our swing based commercial apps if JavaFX does not run on tablets as well. Am 30.07.2013 um 21:06 schrieb Felix Bembrick felix.bembr...@gmail.com: Hi Tobi, I know how you feel. As much as I am impressed with JavaFX, clearly its long-term survival does depend on it being viable on mobiles and tablets. All I can say is don't give up yet. I am certainly not giving up. I really hope we see something at JavaOne this year that will please us all. It *has* to be this year! Felix On 31 July 2013 02:40, Tobias Bley t...@ultramixer.com wrote: Hi, after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT compiling… we hade no success…too complicated build process…no demos available for iOS… So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no big company like Oracle or IBM who actively develops a VM for iOS and Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big winner for the most use cases on Desktop and mobile… Best, Tobi
Re: current state of gradle script for Android?
Hi Tomas, thanks for your hints. Where can I find the „FXApplication“ class? There is only a „FXActivity“ and a „VMLauncher“ class… Could you please give me a hint how to start to build a JavaFX launcher for Dalvik? Thanks, Tobi Am 02.08.2013 um 10:59 schrieb tomas.brandalik tomas.branda...@oracle.com: On 08/01/2013 11:41 PM, Tobias Bley wrote: Thanks Tomas, after changing android.gradle script line defineProperty(ANDROID_CROSS_TOOLS_VER, arm-linux-androideabi-4.4.3“)“ to defineProperty(ANDROID_CROSS_TOOLS_VER, If toolchain version changed you just need to pass property -PANDROID_CROSS_TOOLS_VER=arm-linux-androideabi-4.6 arm-linux-androideabi-4.6“)“ and def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? macosx : linux-x86““ to „def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? darwin-x86_64 : linux-x86““ I could successfully build OpenJFX for Android von Mac OS X 10.9! I will have a look at it. So now I’m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in „com.oracle.dalvik“ package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? The fx project for android looks like usual android project except that it bundles with the vm image. All essential parameters (main class, debug port, parametets etc) are in AndroidManifest.xml If you look at FXApplication you will realize that it installs vm first and then launches fx application on that vm. FXApplication activity does very little just prepares a surface where to draw opengl stuff. I'm sure you see the catch ... the vm is not available yet. Another option to consider is to run on dalvik which I think is doable with a rewriting the launcher and using compatibility project javafx78 (or how's that called). -Tomas Best regards, Tobi Am 01.08.2013 um 16:00 schrieb tomas.brandalik tomas.branda...@oracle.com: The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. http://developer.android.com/sdk/index.html http://developer.android.com/tools/sdk/ndk/index.html -Tomas On 08/01/2013 03:41 PM, Tobias Bley wrote: Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? Thanks! Tobi Am 31.07.2013 um 16:42 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, it works on linux only right now. Set properties for cross build and android sdk/ndk. -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true Closed source parts web and font-t2k will be missing. -Tomas On 07/29/2013 11:22 PM, Tobias Bley wrote: Hi, can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? Best regards, Tobi
Re: JavaFX and iOS - it will remain a dream
How did you go with using Maven for your iOS stuff Tobi? Did it work out for you? Has anyone else had a chance to get into it? I was hoping for more feedback on what works and what doesn't. Also hoping to see some open source demo iOS apps popup to start highlighting what works and what doesn't. http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/ We all know 'Oracle' has a stupid stance on this, and reading between the lines the 'JFX' team are more on our side of the fence but are hamstrung. My personal feel is that the only hope is for the community to get the momentum going and to use that to then pressure Oracle into doing more. I've done what I can on the Maven front, trying to make it easy for developers to build apps. It's taken a lot of late nights and burnt up a lot of weekends (I even had to go buy a friggen Mac). I've reached my max for investing at this stage and need to take a little time to catch up on slipping day job work before the next round of fixes and enhancements. It would be great to see a real community effort here and see some people take up the baton and run the next leg of the relay. Both Niklas and Danno have done massive contributions so far too and I don't think they can be expected to carry the load alone. If you want to help give jfx iOS an actual fighting chance then consider: - writing some demo apps using the maven stuff, blogging about it, feeding back problems and issues so we can start fixing them - helping Niklas get robovm performant and feature rich (eg build a bundle for deployment to the app store) - talk to Niklas about financially sponsoring his work - if a company or two were willing to pay for him to work on it an extra day or two a week I suspect we'd see rapid gains - help maintain the backport run by Danno. Every time there are changes to the main jfx code we need to merge these into the backport. This is no small task. - help document the Maven plugin and generate usage information including a getting started guide and show how to do things like use FXML, change the app icon, change plists, run on older versions of ios, etc. On 07/08/2013, at 5:19 PM, Tobias Bley t...@ultramixer.com wrote: Yes Felix, it *has* to be this year…. We do not port our swing based commercial apps if JavaFX does not run on tablets as well. Am 30.07.2013 um 21:06 schrieb Felix Bembrick felix.bembr...@gmail.com: Hi Tobi, I know how you feel. As much as I am impressed with JavaFX, clearly its long-term survival does depend on it being viable on mobiles and tablets. All I can say is don't give up yet. I am certainly not giving up. I really hope we see something at JavaOne this year that will please us all. It *has* to be this year! Felix On 31 July 2013 02:40, Tobias Bley t...@ultramixer.com wrote: Hi, after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT compiling… we hade no success…too complicated build process…no demos available for iOS… So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no big company like Oracle or IBM who actively develops a VM for iOS and Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big winner for the most use cases on Desktop and mobile… Best, Tobi
JavaFX for Android build is broken
Hi (Tomas), I tried to build JavaFX for Android again but was getting the follow build errors: /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c: In function 'Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onKeyEventNative': /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c:240:5: warning: implicit declaration of function 'describe_key_action' [-Wimplicit-function-declaration] /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c: At top level: /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c:332:7: error: conflicting types for 'describe_key_action' /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c:240:5: note: previous implicit declaration of 'describe_key_action' was here :graphics:ccAndroidSurface FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':graphics:ccAndroidSurface'. org.gradle.process.internal.ExecException: Process 'command '/Applications/Developer/Java/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc'' finished with non-zero exit value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
Fwd: current state of gradle script for Android?
Hey Danno, could you please merge the latest changes to your jfx78 project? Thank you very much! Tobi Anfang der weitergeleiteten Nachricht: Von: tomas.brandalik tomas.branda...@oracle.com Betreff: Aw: current state of gradle script for Android? Datum: 7. August 2013 10:15:25 MESZ An: Tobias Bley t...@ultramixer.com Kopie: openjfx-dev@openjdk.java.net Mailing openjfx-dev@openjdk.java.net Hi, this was a typo :( I meant FXActivity not FXApplication. You can get some hints from FXActivity.java.jfx78 source file if you look at launchFXApplication(). But this is just an old launcher which is not functional now. I will to give it a try when there is backport of javafx (https://bitbucket.org/narya/jfx78) updated to latest status of openjfx. It should be fairly easy to write launcher for dalvik. -Tomas On 08/07/2013 09:35 AM, Tobias Bley wrote: Hi Tomas, thanks for your hints. Where can I find the „FXApplication“ class? There is only a „FXActivity“ and a „VMLauncher“ class… Could you please give me a hint how to start to build a JavaFX launcher for Dalvik? Thanks, Tobi Am 02.08.2013 um 10:59 schrieb tomas.brandalik tomas.branda...@oracle.com: On 08/01/2013 11:41 PM, Tobias Bley wrote: Thanks Tomas, after changing android.gradle script line defineProperty(ANDROID_CROSS_TOOLS_VER, arm-linux-androideabi-4.4.3“)“ to defineProperty(ANDROID_CROSS_TOOLS_VER, If toolchain version changed you just need to pass property -PANDROID_CROSS_TOOLS_VER=arm-linux-androideabi-4.6 arm-linux-androideabi-4.6“)“ and def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? macosx : linux-x86““ to „def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? darwin-x86_64 : linux-x86““ I could successfully build OpenJFX for Android von Mac OS X 10.9! I will have a look at it. So now I’m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in „com.oracle.dalvik“ package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? The fx project for android looks like usual android project except that it bundles with the vm image. All essential parameters (main class, debug port, parametets etc) are in AndroidManifest.xml If you look at FXApplication you will realize that it installs vm first and then launches fx application on that vm. FXApplication activity does very little just prepares a surface where to draw opengl stuff. I'm sure you see the catch ... the vm is not available yet. Another option to consider is to run on dalvik which I think is doable with a rewriting the launcher and using compatibility project javafx78 (or how's that called). -Tomas Best regards, Tobi Am 01.08.2013 um 16:00 schrieb tomas.brandalik tomas.branda...@oracle.com: The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. http://developer.android.com/sdk/index.html http://developer.android.com/tools/sdk/ndk/index.html -Tomas On 08/01/2013 03:41 PM, Tobias Bley wrote: Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? Thanks! Tobi Am 31.07.2013 um 16:42 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, it works on linux only right now. Set properties for cross build and android sdk/ndk. -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true Closed source parts web and font-t2k will be missing. -Tomas On 07/29/2013 11:22 PM, Tobias Bley wrote: Hi, can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? Best regards, Tobi
Re: Swing and JavaFX thread merge
Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
hg: openjfx/8/graphics/rt: Android: Handle back key. Map it to javafx ESC keyode. It doesn't have default behaviour like on Android application has to handle it.
Changeset: 7b91d799fbda Author:tb115823 tomas.branda...@oracle.com Date: 2013-08-07 13:50 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7b91d799fbda Android: Handle back key. Map it to javafx ESC keyode. It doesn't have default behaviour like on Android application has to handle it. ! modules/graphics/src/main/native-glass/lens/android/android.c ! modules/graphics/src/main/native-glass/lens/android/android.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.h
hg: openjfx/8/graphics/rt: RT-32168 Android: Build has to better support various toolchains.
Changeset: 3f66d861ed68 Author:tb115823 tomas.branda...@oracle.com Date: 2013-08-07 13:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3f66d861ed68 RT-32168 Android: Build has to better support various toolchains. ! buildSrc/android.gradle
hg: openjfx/8/controls/rt: 59 new changesets
Changeset: d8637798fb3e Author:dmasada Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d8637798fb3e RT-31630 Ensemble8 CurveFittedAreaChart and some others get NPE in NGRegion ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/charts/area/curvefitted/CurveFittedAreaChart.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/searchbox/SearchBox.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayer.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayer.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayer.css Changeset: 430db69d45c7 Author:Chien Yang chien.y...@orcale.com Date: 2013-07-30 14:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/430db69d45c7 Fix to RT-31914: occlusion culling fails to work correctly on pure 2d shapes scene with 3d transform Reviewed by Kevin and Martin ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: 673aece90319 Author:Chien Yang chien.y...@orcale.com Date: 2013-07-30 14:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/673aece90319 Fix to RT-30829: DepthTest flag on Graphics is set by Node but never cleared, misbehaving with multiple dirty regions Reviewed by Kevin ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: a9eb573ffc6e Author:tb115823 tomas.branda...@oracle.com Date: 2013-07-31 09:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a9eb573ffc6e Android: Add vmlauncher netbeans project. + netbeans/android/vmlauncher/Android.mk + netbeans/android/vmlauncher/nbproject/configurations.xml + netbeans/android/vmlauncher/nbproject/project.xml Changeset: 4f9d8e9fb4aa Author:tb115823 tomas.branda...@oracle.com Date: 2013-07-31 09:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4f9d8e9fb4aa Android: Rename netbeans projects. - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml + netbeans/android/native-glass/Android.mk + netbeans/android/native-glass/nbproject/configurations.xml + netbeans/android/native-glass/nbproject/project.xml = netbeans/android/native-vmlauncher/Android.mk netbeans/android/vmlauncher/Android.mk = netbeans/android/native-vmlauncher/nbproject/configurations.xml netbeans/android/vmlauncher/nbproject/configurations.xml ! netbeans/android/native-vmlauncher/nbproject/project.xml netbeans/android/vmlauncher/nbproject/project.xml Changeset: fbd46f5535b5 Author:tb115823 tomas.branda...@oracle.com Date: 2013-07-31 09:59 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fbd46f5535b5 Android: Add netbeans project native-prism-es2. + netbeans/android/native-prism-es2/Android.mk + netbeans/android/native-prism-es2/nbproject/configurations.xml + netbeans/android/native-prism-es2/nbproject/project.xml Changeset: 74cc6f8d1fc9 Author:Artem Ananiev artem.anan...@oracle.com Date: 2013-07-31 14:03 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74cc6f8d1fc9 RT-31964: Quantum cleanup: don't force headless AWT on Mac Reviewed-by: Kevin Rushforth ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 61bcda9f2a59 Author:tb115823 tomas.branda...@oracle.com Date: 2013-07-31 13:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/61bcda9f2a59 Android: Fix hyphens in native libraries names. Remove absolete NativeActivity class. ! buildSrc/android.gradle - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java Changeset: fda3c077e769 Author:tb115823 tomas.branda...@oracle.com Date: 2013-07-31 13:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fda3c077e769 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java Changeset: 4d6d71a5fdb5 Author:David Pulkrabek david.pulkra...@oracle.com Date: 2013-07-31 13:28 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4d6d71a5fdb5 iOS build: introduced a new property for closed build ! buildSrc/ios.gradle Changeset: dd02ad45b83c Author:flar james.gra...@oracle.com Date: 2013-07-31 06:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dd02ad45b83c Fix RT-30223, RT-30826, RT-31044 - Canvas clears clip on Windows/D3D ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DContext.java !
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: fbfd5d489bcf Author:peterz Date: 2013-08-07 18:20 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbfd5d489bcf Upgraded to webview-deps-1.1 ! build.gradle Changeset: 79f9597ebf00 Author:Oldrich Maticka oldrich.mati...@oracle.com Date: 2013-08-07 16:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/79f9597ebf00 iOS: updating crosslibs to ios-libs-06; adjusting JavaFXMain, launcher ! buildSrc/ios.gradle
Re: Multiple JFXPanel?
Hi Pedro, On 05.08.2013 2:13, Pedro Duque Vieira wrote: Hi Anton, Thanks for your reply. Actually I wasn't clear enough when I explained my app. My app is composed of a MDI style interface but each window belongs to the same JFrame, so there is only one JFrame but multiple internal frames. One of these internal frames has a JFXPanel with a scene in it. I intend to migrate the rest of the internal frames to javafx one by one using this approach. Sorry, I didn't get it. My question was is this a viable way to do this? Or am I going to pay a performance penalty from having multiple JFXPanels (hence multiple scenes) inside the same app (the same JFrame)? Actually, it doesn't matter for an embedded scene where you embed it, to a separate frame or to an internal one. In both the cases the embedded scene will have the same machinery behind. Just for curiosity, I've modified my testcase to be MDI like and got the same performance scores. So, your case should not bring any additional performance decrease, except for the difference b/w your fx swing implementations which may depend. Thanks, Anton. From what people have told me in this mailing list, they are using multiple JFXPanels without any significant performance penalty, anyway it would be interesting hearing the opinion from you, JavaFX dev team guys. Thanks once again for your replies, best regards, On Fri, Aug 2, 2013 at 8:55 AM, Anton V. Tarasov anton.tara...@oracle.com mailto:anton.tara...@oracle.com wrote: Hi Pedro, I've made the following experiment. I've created two simple test cases: one is pure fx stage showing WebView which animated some guimark2 benchmarks, another one is the same WebView wrapped with JFXPanel put in JFrame. I ran each test case with a single, two or four toplevels (Stages or JFrames, appropriately) and measured performance difference. I noticed that for the swing test case, adding more toplevels decreased performance with the same proportion like the fx test case did (despite the fact that fx performed relatively faster, of course). For instance, for the Vector Charting Test the ratio was directly proportional to the number of toplevels, that is doubling the toplevels decreased performance by two times equally for both fx and swing cases. This more or less proves the fact that adding another embedded scene into your app doesn't bring anything except another scene. Thanks, Anton. On 01.08.2013 2:45, Pedro Duque Vieira wrote: Hi, I have a doubt. I have a swing app with embed javafx scene. My app has kind of a MDI style interface. Right now only one window has been converted to JavaFX, basically it's a window with a JFXPanel in it. My question is if I want to convert the other windows as well should I also put a JFXPanel in them? I would than have 2 JFXPanels in my app, does that mean I would have 2 JavaFX scenes? Is that the way to do it? Would that seriously hurt performance? Thank you in advance, best regards, -- Pedro Duque Vieira
Proposal to move default style-class from Control to SkinBase
Currently, a control has a default style-class. For example, you can use
.button in a style-sheet to style a Button. I propose to move the default
style-class from the control to the skin (RT-32186). The impetus for this
change is two-fold.
Firstly, it can be argued that setting the style-class of a control should be
left to the developer, that imposing a default style-class is implementation
detail leaking into the public API. Moving the default style-class from the
control to the skin addresses this concern.
The second motive has to do with CSS processing itself. When a skin is set on a
control, the control adopts the styles of the skin and css is reapplied to the
control in order to pick up the new styles. Thus, it takes two CSS passes to
fully style a control. By moving the default style-class to the skin, the
control no longer has to adopt the skin's styles. Styles still have to be
applied to the skin, but this can be done from the skinProperty's invalidated
method. These subtle changes - not adopting the styles and applying css to the
skin from skinProperty's invalidated method - will simplify the code in
Control.
The reason for moving the default from Control to SkinBase and not Skin is that
there is no API in Skin for getting style-class (or any other css selector
attributes). Skin could implement the Styleable interface, but that would not
be backward compatible.
Another issue related to CSS processing has to do with looking up cached,
matching styles for a node. When the skin is set on the node and adopts the
styles of the skin, css is reapplied. This means that the css implementation
will look for matching styles for the control. There is a map that has a node's
simple class name, style-class, and id (the 'css selector' aspects of a node)
as a key and the matching styles as a value. Since none of the 'css selector'
aspects of the node have changed, the previously cached value is returned from
the map. Then when the styles are applied to the node, css says 'oh, I've
already calculated values for this kind of node' and doesn't bother looking up
the properties that were added by the skin. This causes problems such as
https://javafx-jira.kenai.com/browse/RT-31691.
The cache lookup issue can be resolved in other ways, such as adding the list
of properties to the key, or adding a flag to cause css to calculate a value if
there is no previously calculated value found. But I believe that moving the
default style-class will lead to cleaner code.
If a control no longer adopts the skin's styles, then the control and the skin
could be styled as separate entities. This would mean that instead of
.tool-bar { -fx-orientation: vertical; -fx-spacing: 3; }
one would have to write
ToolBar { -fx-orientation: vertical; } .tool-bar: { -fx-spacing: 3; }
since orientation is a property of ToolBar and spacing a property of
ToolBarSkin. This is an issue for maintaining backward compatibility with
existing stylesheets. This isn't a issue for caspian or modena but is for
author style-sheets and inline styles. I have some ideas here, but all of them
rather clunky and kludgey. My question on this point is whether or not this is
a real concern.
Re: Multiple JFXPanel?
Hi Anton, Thank you very much for your effort! Best regards, On Sat, Jul 6, 2013 at 3:39 PM, Anton V. Tarasov anton.tara...@oracle.comwrote: Hi Pedro, On 05.08.2013 2:13, Pedro Duque Vieira wrote: Hi Anton, Thanks for your reply. Actually I wasn't clear enough when I explained my app. My app is composed of a MDI style interface but each window belongs to the same JFrame, so there is only one JFrame but multiple internal frames. One of these internal frames has a JFXPanel with a scene in it. I intend to migrate the rest of the internal frames to javafx one by one using this approach. Sorry, I didn't get it. My question was is this a viable way to do this? Or am I going to pay a performance penalty from having multiple JFXPanels (hence multiple scenes) inside the same app (the same JFrame)? Actually, it doesn't matter for an embedded scene where you embed it, to a separate frame or to an internal one. In both the cases the embedded scene will have the same machinery behind. Just for curiosity, I've modified my testcase to be MDI like and got the same performance scores. So, your case should not bring any additional performance decrease, except for the difference b/w your fx swing implementations which may depend. Thanks, Anton. From what people have told me in this mailing list, they are using multiple JFXPanels without any significant performance penalty, anyway it would be interesting hearing the opinion from you, JavaFX dev team guys. Thanks once again for your replies, best regards, On Fri, Aug 2, 2013 at 8:55 AM, Anton V. Tarasov anton.tara...@oracle.com wrote: Hi Pedro, I've made the following experiment. I've created two simple test cases: one is pure fx stage showing WebView which animated some guimark2 benchmarks, another one is the same WebView wrapped with JFXPanel put in JFrame. I ran each test case with a single, two or four toplevels (Stages or JFrames, appropriately) and measured performance difference. I noticed that for the swing test case, adding more toplevels decreased performance with the same proportion like the fx test case did (despite the fact that fx performed relatively faster, of course). For instance, for the Vector Charting Test the ratio was directly proportional to the number of toplevels, that is doubling the toplevels decreased performance by two times equally for both fx and swing cases. This more or less proves the fact that adding another embedded scene into your app doesn't bring anything except another scene. Thanks, Anton. On 01.08.2013 2:45, Pedro Duque Vieira wrote: Hi, I have a doubt. I have a swing app with embed javafx scene. My app has kind of a MDI style interface. Right now only one window has been converted to JavaFX, basically it's a window with a JFXPanel in it. My question is if I want to convert the other windows as well should I also put a JFXPanel in them? I would than have 2 JFXPanels in my app, does that mean I would have 2 JavaFX scenes? Is that the way to do it? Would that seriously hurt performance? Thank you in advance, best regards, -- Pedro Duque Vieira -- Pedro Duque Vieira
Re: JavaFX Sightings (forked from Re: Can JavaFX do CAD?)
On Wed, 07 Aug 2013 16:54:37 +0200, Mark Fortner phidia...@gmail.com wrote: The showcase sounds like a good idea, but if the goal is to be able to use it to convince people that JavaFX is a viable platform, wouldn't it be better if you could download and try the application (maybe even web start it)? After all, the proof of the pudding is in the eating. Guys, if the application is available, this is a plus, but there's plenty of non-distributable applications. Even better if the application is open source, so people can check it out, but not all applications are open source. When the interview include the developers, who talk also in name of the company, this is very valuable information. So, let's just provide the best information possible, case by case. Rich client apps are strong mostly in the industry, and most of the stuff here is proprietary. Anyway, let's not forget that in most cases decisions about which technology to use are done and/or approved by managers, and they usually don't download and run applications. They are assured if they see a widespread adoption of the technology. Bad or good, they reason in terms of powerpoint slides and diagrams about the market share. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Form of ProgressIndicator
Hi guys, I've just realized that the ProgressIndicator in Modena isn't shown as a rotating circle. It looks like somebody pried apart the ProgressWheel and left it apart. Has there been a change in the UI of ProgressIndicator or is this a bug and if so should I file a bug? Regards, Martin
Re: Form of ProgressIndicator
https://javafx-jira.kenai.com/browse/RT-31196 On Aug 7, 2013, at 12:35 PM, Martin Klähn grazer...@gmail.com wrote: Hi guys, I've just realized that the ProgressIndicator in Modena isn't shown as a rotating circle. It looks like somebody pried apart the ProgressWheel and left it apart. Has there been a change in the UI of ProgressIndicator or is this a bug and if so should I file a bug? Regards, Martin
Re: Proposal to move default style-class from Control to SkinBase
Since day 1 of writing controls for JFX I've used the approach that a skin sets
its own style class, and that class is used in the CSS. If a control should not
be aware of how it is rendered, what sense does it make to have visual styling
set on it?
So in a skin I do: this.getStyleClass().add( AgendaWeekSkin );
And in the CSS: .AgendaWeekSkin { ... }
In this way I already have separate styling between control and the active
skin. So I can only +1 any change that more clearly moves any visual aspect
closer to the skin.
That said, of course there are certain things of a control that are very
generic, like a textfield having font styling. These styling could/should still
be stylable on the control and not the skin. OTOH, usually such things are set
on a more abstract level.
Tom
On 2013-08-07 17:08, David Grieve wrote:
Currently, a control has a default style-class. For example, you can use
.button in a style-sheet to style a Button. I propose to move the default
style-class from the control to the skin (RT-32186). The impetus for this
change is two-fold.
Firstly, it can be argued that setting the style-class of a control should be
left to the developer, that imposing a default style-class is implementation
detail leaking into the public API. Moving the default style-class from the
control to the skin addresses this concern.
The second motive has to do with CSS processing itself. When a skin is set on a
control, the control adopts the styles of the skin and css is reapplied to the
control in order to pick up the new styles. Thus, it takes two CSS passes to
fully style a control. By moving the default style-class to the skin, the
control no longer has to adopt the skin's styles. Styles still have to be
applied to the skin, but this can be done from the skinProperty's invalidated
method. These subtle changes - not adopting the styles and applying css to the
skin from skinProperty's invalidated method - will simplify the code in Control.
The reason for moving the default from Control to SkinBase and not Skin is that
there is no API in Skin for getting style-class (or any other css selector
attributes). Skin could implement the Styleable interface, but that would not
be backward compatible.
Another issue related to CSS processing has to do with looking up cached,
matching styles for a node. When the skin is set on the node and adopts the
styles of the skin, css is reapplied. This means that the css implementation
will look for matching styles for the control. There is a map that has a node's
simple class name, style-class, and id (the 'css selector' aspects of a node)
as a key and the matching styles as a value. Since none of the 'css selector'
aspects of the node have changed, the previously cached value is returned from
the map. Then when the styles are applied to the node, css says 'oh, I've
already calculated values for this kind of node' and doesn't bother looking up
the properties that were added by the skin. This causes problems such as
https://javafx-jira.kenai.com/browse/RT-31691.
The cache lookup issue can be resolved in other ways, such as adding the list
of properties to the key, or adding a flag to cause css to calculate a value if
there is no previously calculated value found. But I believe that moving the
default style-class will lead to cleaner code.
If a control no longer adopts the skin's styles, then the control and the skin
could be styled as separate entities. This would mean that instead of
.tool-bar { -fx-orientation: vertical; -fx-spacing: 3; }
one would have to write
ToolBar { -fx-orientation: vertical; } .tool-bar: { -fx-spacing: 3; }
since orientation is a property of ToolBar and spacing a property of
ToolBarSkin. This is an issue for maintaining backward compatibility with
existing stylesheets. This isn't a issue for caspian or modena but is for
author style-sheets and inline styles. I have some ideas here, but all of them
rather clunky and kludgey. My question on this point is whether or not this is
a real concern.
RE: Proposal to move default style-class from Control to SkinBase
Hi David, I'm not going to directly answer your question but I'm rather gonna touch on a problem I see regarding JavaFX CSS. Forgive me for not directly sticking to the subject of your email. The issue I see is that JavaFX CSS significantly differs from W3C CSS, that is the CSS that is used on the web. I've already touch this subject before but didn't have much answer from this mailing list. The reason why I bring it back again is that the more I do web development the more this seems unappropriated. Having JavaFX CSS differ from W3C CSS has the following disadvantages: - Designers coming from web development (they are the majority) will struggle with JavaFX CSS - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing out on this tooling that significantly enhances CSS. You can do really cool stuff with Compass. - Cannot reuse what already is out there on the web. And there are a huge amount of examples there. - Re-inventing the wheel. My personal opinion is that you should try to harness the work that already exists especially when you have few resources. People have already spent some time on this, tested and fixed issues with it. So why not stand on the shoulder of giants. I'm not saying you should introduce CSS layout, that is a headache and a problem that they're trying to solve in CSS3, but all the rest can be changed to be the same as CSS. You can even have both working side by side, the current JavaFX CSS and a newer more W3C conforming CSS so that you don't break existing apps. I don't see any advantage of having a CSS different from W3C one, if I was going to make one different I would have created a newer more simpler language to express an apps appearance. Not used CSS. Thanks, best regards, -- Pedro Duque Vieira
Re: Proposal to move default style-class from Control to SkinBase
Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX. Tom On 07.08.13 22:56, Tom Schindl wrote: If I get your complain right what you want has nothing to do with CSS but you are requesting that the complete FX API is remodeled, CSS is simply a way to set properties of your Nodes in the SceneGraph, in a none intrusive way. You need to differiate between CSS as a language and the properties one can set on DOM/SceneGraph-Nodes. From the selector point (language) of view FX-CSS support all important selector types, but because the nodes in the DOM (=SceneGraph in FX) are different you have other properties. So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. Tom On 07.08.13 22:41, Pedro Duque Vieira wrote: Hi David, I'm not going to directly answer your question but I'm rather gonna touch on a problem I see regarding JavaFX CSS. Forgive me for not directly sticking to the subject of your email. The issue I see is that JavaFX CSS significantly differs from W3C CSS, that is the CSS that is used on the web. I've already touch this subject before but didn't have much answer from this mailing list. The reason why I bring it back again is that the more I do web development the more this seems unappropriated. Having JavaFX CSS differ from W3C CSS has the following disadvantages: - Designers coming from web development (they are the majority) will struggle with JavaFX CSS - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing out on this tooling that significantly enhances CSS. You can do really cool stuff with Compass. - Cannot reuse what already is out there on the web. And there are a huge amount of examples there. - Re-inventing the wheel. My personal opinion is that you should try to harness the work that already exists especially when you have few resources. People have already spent some time on this, tested and fixed issues with it. So why not stand on the shoulder of giants. I'm not saying you should introduce CSS layout, that is a headache and a problem that they're trying to solve in CSS3, but all the rest can be changed to be the same as CSS. You can even have both working side by side, the current JavaFX CSS and a newer more W3C conforming CSS so that you don't break existing apps. I don't see any advantage of having a CSS different from W3C one, if I was going to make one different I would have created a newer more simpler language to express an apps appearance. Not used CSS. Thanks, best regards,
Re: Swing and JavaFX thread merge
I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Is there a secret setting that has a different default with JAWS? jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote: Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
hg: openjfx/8/graphics/rt: RT-32199: drawText doing work when the glyphlist#getGlyphCount() == 0
Changeset: 747685094fb1 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-08-07 14:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/747685094fb1 RT-32199: drawText doing work when the glyphlist#getGlyphCount() == 0 ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGText.java
hg: openjfx/2u/dev/rt: 2 new changesets
Changeset: aef521116893 Author:hudson Date: 2013-08-02 09:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/aef521116893 Added tag 2.2.40-b37 for changeset c2c325536f52 ! .hgtags Changeset: 34e462c596ce Author:hudson Date: 2013-08-07 11:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/34e462c596ce Added tag 2.2.40-b38 for changeset aef521116893 ! .hgtags
JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. +1 to this idea (in a 3rd party lib). The issue I see is that JavaFX CSS significantly differs from W3C CSS It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 need to reconcile JavaFX CSS with W3C CSS3 0 votes (no interest at all?). In terms of conversion of existing html css resources to javafx css, you may be interested in a QA with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. Below is a copy and paste from an earlier JavaFX forum post on this topic: You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000 tests to w3c just to cover only a subset of the css rules available in browsers today. The webkit project lists almost a thousand open CSS bugs: https://bugs.webkit.org/buglist.cgi?product=WebKitcomponent=CSSresolution=---. So implementing even partial w3c CSS support is a complex project. When I first started using JavaFX CSS I found the differences to w3c CSS quite jarring, and it was hard to account for them. Now that I am used to JavaFX CSS, I don't have as much of an issue. The difference in names and semantics is going to be an impediment to designers working on JavaFX who are familar with w3c CSS - but the designers will quickly also discover that FXML is not HTML and Java is not JavaScript and JavaFX deployment is not HTML deployment. So, perhaps, in the larger picture, it is not as big a deal as it would seem. Still, one can't help think that any impediment to people easily picking up and adopting JavaFX is doing the technology a disservice. There are other advantages in having the JavaFX CSS in its own namespace to w3c css, in that it can evolve seperately, it is not expected to be exactly the same because it has a different name, it is not expected to fully implement w3c css as browsers do because it's clearly a different thing by name, etc. There is even precedent for it in the use by mozilla of moz- CSS prefixes and webkit css properties http://css-infos.net/properties/webkit - the web as not as standard as a lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and not an HTML rendering engine. It is quite remarkable that Oracle was able to build and make available a CSS model for JavaFX that feels as familiar as it does to w3c css, as w3c css is targeted very strongly toward styling a completely different technology set (HTML markup and document object model). It would be useful to have a tool which translates w3c css to approximations of JavaFX css and vice versa, or the ability for JavaFX to have a mode (perhaps a boolean value when a stylesheet is loaded) to perform an automatic alias or mapping of w3c css to javafx (at least for the subset of w3c css which would make sense to automatically translate to JavaFX css). (David commented on this part previously - Closing the gap between JavaFX CSS and W3C CSS will be an evolutionary process. It would be nice to use a standard's based stylesheet but there is not always a 1-1 mapping to JavaFX. But for those properties that can be mapped, it is something that should be supported. For example, we should be able to handle font or -fx-font.) Comments above relate to the naming and semantic meanings of css tags, and not the syntax and parsing of css (as both w3c css and javaFX css seem to be equivalent in the later regard). The JavaFX css model is really powerful and I have found really useful some of the additions that it adds above the baseline 2.1 css that is found consistently in browsers. With the upcoming Java CSS object model http://javafx-jira.kenai.com/browse/RT-17293 CSS Style Object Model in Java 23 votes, you will also get better programmatic access from Java, which seems to be a highly requested feature. Regards, John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday,
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
I couldn't resist - http://tomsondev.bestsolution.at/2013/08/07/using-less-in-javafx/ Tom On 08.08.13 01:08, John Smith wrote: So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. +1 to this idea (in a 3rd party lib). The issue I see is that JavaFX CSS significantly differs from W3C CSS It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 need to reconcile JavaFX CSS with W3C CSS3 0 votes (no interest at all?). In terms of conversion of existing html css resources to javafx css, you may be interested in a QA with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. Below is a copy and paste from an earlier JavaFX forum post on this topic: You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000 tests to w3c just to cover only a subset of the css rules available in browsers today. The webkit project lists almost a thousand open CSS bugs: https://bugs.webkit.org/buglist.cgi?product=WebKitcomponent=CSSresolution=---. So implementing even partial w3c CSS support is a complex project. When I first started using JavaFX CSS I found the differences to w3c CSS quite jarring, and it was hard to account for them. Now that I am used to JavaFX CSS, I don't have as much of an issue. The difference in names and semantics is going to be an impediment to designers working on JavaFX who are familar with w3c CSS - but the designers will quickly also discover that FXML is not HTML and Java is not JavaScript and JavaFX deployment is not HTML deployment. So, perhaps, in the larger picture, it is not as big a deal as it would seem. Still, one can't help think that any impediment to people easily picking up and adopting JavaFX is doing the technology a disservice. There are other advantages in having the JavaFX CSS in its own namespace to w3c css, in that it can evolve seperately, it is not expected to be exactly the same because it has a different name, it is not expected to fully implement w3c css as browsers do because it's clearly a different thing by name, etc. There is even precedent for it in the use by mozilla of moz- CSS prefixes and webkit css properties http://css-infos.net/properties/webkit - the web as not as standard as a lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and not an HTML rendering engine. It is quite remarkable that Oracle was able to build and make available a CSS model for JavaFX that feels as familiar as it does to w3c css, as w3c css is targeted very strongly toward styling a completely different technology set (HTML markup and document object model). It would be useful to have a tool which translates w3c css to approximations of JavaFX css and vice versa, or the ability for JavaFX to have a mode (perhaps a boolean value when a stylesheet is loaded) to perform an automatic alias or mapping of w3c css to javafx (at least for the subset of w3c css which would make sense to automatically translate to JavaFX css). (David commented on this part previously - Closing the gap between JavaFX CSS and W3C CSS will be an evolutionary process. It would be nice to use a standard's based stylesheet but there is not always a 1-1 mapping to JavaFX. But for those properties that can be mapped, it is something that should be supported. For example, we should be able to handle font or -fx-font.) Comments above relate to the naming and semantic meanings of css tags, and not the syntax and parsing of css (as both w3c css and javaFX css seem to be equivalent in the later regard). The JavaFX css model is really powerful and I have found really useful some of the additions that it adds above the baseline 2.1 css that is found consistently in browsers. With the upcoming Java CSS object model http://javafx-jira.kenai.com/browse/RT-17293 CSS Style Object Model in Java 23 votes, you will also get better programmatic access from Java, which seems to be a
Re: Proposal to move default style-class from Control to SkinBase
Hi David,
Currently, a control has a default style-class. For example, you can use
.button in a style-sheet to style a Button. I propose to move the default
style-class from the control to the skin (RT-32186). The impetus for this
change is two-fold.
Firstly, it can be argued that setting the style-class of a control should be
left to the developer, that imposing a default style-class is implementation
detail leaking into the public API. Moving the default style-class from the
control to the skin addresses this concern.
The second motive has to do with CSS processing itself. When a skin is set on
a control, the control adopts the styles of the skin and css is reapplied to
the control in order to pick up the new styles. Thus, it takes two CSS passes
to fully style a control. By moving the default style-class to the skin, the
control no longer has to adopt the skin's styles. Styles still have to be
applied to the skin, but this can be done from the skinProperty's invalidated
method. These subtle changes - not adopting the styles and applying css to
the skin from skinProperty's invalidated method - will simplify the code in
Control.
It seems like removing the built-in style classes would be quite a breaking
change. One pattern used today in order to turn off the default styles
(without having to wholly replace the skins) is to clear the styleClass list.
But if the styleClass list is already empty, this pattern won't work and
existing code will break. Another problem is that existing CSS styles just say
.tool-bar { -fx-orientation: vertical; }, and those would no longer work.
Is there another way to accomplish your second motive?
I need more time to work through the rest of this, maybe we can chat offline to
get me up to speed, but my initial concern is that removing the style class
will break people fairly substantially.
Richard
hg: openjfx/8/controls/rt: 3 new changesets
Changeset: 779268099d54 Author:jgiles Date: 2013-08-08 09:47 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/779268099d54 [DOC ONLY] Added javadoc to TableView to explain the new sorted list functionality. ! modules/controls/src/main/java/javafx/scene/control/TableView.java Changeset: 41bec1a02dd2 Author:jgiles Date: 2013-08-08 10:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/41bec1a02dd2 RT-32201: 8.0-controls-scrum-702: Controls.TableView-Sort performance benchmark fails with ClassCastException ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: bfc4fa2ec8fd Author:jgiles Date: 2013-08-08 17:01 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bfc4fa2ec8fd RT-31015: javafx.scene.control.TableView: TableCell.cancelEdit should not be called twice on cancelling editing ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java
