Re: Reloading stylesheets
That doesn't work in 2.x because the CSS is cached on a scene base! A trick that could work is to load the CSS with an URL like this like: my.css?timestamp=123456789 but I have not tried that and don't know if this would work. Tom On 10.12.13 13:41, Scott Palmer wrote: Have you tried simply removing and re-adding the stylesheet to the scene? Scott On Tue, Dec 10, 2013 at 7:21 AM, Werner Lehmann lehm...@media-interactive.de wrote: Hi, is there a way to reload previously loaded stylesheets (in FX2)? Currently I have to restart the application each time I am changing the css. It would be nice to just close and reopen that window instead to see the new styles. I'd like to unload css automatically when closing a window - in debug mode - in order to avoid the application restart. Or, even better, define a hotkey to update css immediately. Much like shift+ctrl+8 for ScenicView (only works in FX2 as far as I know). Rgds Werner
Re: Reloading stylesheets
Hmm.. I'll have to take a look at what I was doing, because I had something that appeared to work with 2.x and I'm pretty sure I wasn't using internal APIs. Perhaps it was only working by chance. Scott On Tue, Dec 10, 2013 at 7:46 AM, Tom Schindl tom.schi...@bestsolution.atwrote: That doesn't work in 2.x because the CSS is cached on a scene base! A trick that could work is to load the CSS with an URL like this like: my.css?timestamp=123456789 but I have not tried that and don't know if this would work. Tom On 10.12.13 13:41, Scott Palmer wrote: Have you tried simply removing and re-adding the stylesheet to the scene? Scott On Tue, Dec 10, 2013 at 7:21 AM, Werner Lehmann lehm...@media-interactive.de wrote: Hi, is there a way to reload previously loaded stylesheets (in FX2)? Currently I have to restart the application each time I am changing the css. It would be nice to just close and reopen that window instead to see the new styles. I'd like to unload css automatically when closing a window - in debug mode - in order to avoid the application restart. Or, even better, define a hotkey to update css immediately. Much like shift+ctrl+8 for ScenicView (only works in FX2 as far as I know). Rgds Werner
Re: Reloading stylesheets
Thanks, Tom. Somehow it does not work for me. Any idea? Basically this is what I am doing: Parent root = ... root.getStyleSheets().add(...stylesheets...) Scene scene = new Scene(root) StyleManager.getInstance().reloadStylesheets(scene) Then I show the scene in a JFXPanel, change and save the stylesheet in Eclipse, and reopen the window which repeats all of the above. But the css changes are not reflected until I restart the application. On 10.12.2013 13:30, Tom Schindl wrote: com.sun.javafx.css.StyleManager.getInstance().reloadStylesheets(scene);
[8] Review request for RT-34784: [TextField, PasswordField, TextArea] Selected text is removed on focus leaving
Hi Petr, Alexander, Please review a fix for https://javafx-jira.kenai.com/browse/RT-34784 -- best regards, Anthony
Re: Reloading stylesheets
Got it. The key was to move the stylesheets from the root node to the
scene before reloading them:
scene.styleSheets.clear
scene.styleSheets.addAll(root.styleSheets)
root.styleSheets.clear
styleManager.reload(scene)
The hotkey also works now: shift+ctrl+7 reloads CSS while the scene is
visible. This works by using a custom scene, overriding
impl_processKeyEvent. Even better would be automatic change-detection
(in debug mode only) but I don't have time to do this now. Previously
you said that reloading is not needed on FX8... does this work out of
the box then?
Werner
On 10.12.2013 14:10, Tom Schindl wrote:
My code does:
// Force CSS-Reloading
if( isJavaFX2() ) {
ReflectiveInvoke.onStyleManagerClass(scene);
}
scene.getStylesheets().clear();
scene.getStylesheets().addAll(contentData.cssFiles);
A difference I see is that your stylesheets are on the Root-Container
whereas mine are directly on the Scene.
Tom
Re: Reloading stylesheets
No on FX8 you need to remove and readd them! So the only thing different
is that you omit the reload-call on FX8.
Tom
On 10.12.13 16:10, Werner Lehmann wrote:
Got it. The key was to move the stylesheets from the root node to the
scene before reloading them:
scene.styleSheets.clear
scene.styleSheets.addAll(root.styleSheets)
root.styleSheets.clear
styleManager.reload(scene)
The hotkey also works now: shift+ctrl+7 reloads CSS while the scene is
visible. This works by using a custom scene, overriding
impl_processKeyEvent. Even better would be automatic change-detection
(in debug mode only) but I don't have time to do this now. Previously
you said that reloading is not needed on FX8... does this work out of
the box then?
Werner
On 10.12.2013 14:10, Tom Schindl wrote:
My code does:
// Force CSS-Reloading
if( isJavaFX2() ) {
ReflectiveInvoke.onStyleManagerClass(scene);
}
scene.getStylesheets().clear();
scene.getStylesheets().addAll(contentData.cssFiles);
A difference I see is that your stylesheets are on the Root-Container
whereas mine are directly on the Scene.
Tom
Re: Reloading stylesheets
Interesting. Assuming the stylesheets are still cached, how would it know when to reload and not use the cached sheet? Or has sheet processing been optimized so much that caching is not necessary anymore... On 10.12.2013 16:15, Tom Schindl wrote: No on FX8 you need to remove and readd them! So the only thing different is that you omit the reload-call on FX8.
hg: openjfx/8/graphics/rt: [Samples Only][RT-33754] Ensemble Icons
Changeset: cbc187e97bb8 Author:John Yoon john.y...@oracle.com Date: 2013-12-10 07:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cbc187e97bb8 [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/choicebox/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/choicebox/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/colorpicker/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/colorpicker/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/datepicker/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/datepicker/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/htmleditor/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/htmleditor/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/hyperlink/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/hyperlink/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/listview/horizontallistview/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/listview/horizontallistview/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/listview/listviewcellfactory/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/listview/listviewcellfactory/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/listview/simplelistview/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/listview/simplelistview/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/menu/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/menu/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/pagination/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/pagination/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/progressbar/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/progressbar/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/progressindicator/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/progressindicator/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/radiobutton/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/radiobutton/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/scrollbar/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/scrollbar/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/splitpane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/splitpane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/tab/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/tab/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/tablecellfactory/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/tablecellfactory/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/tableview/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/tableview/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/advancedlabel/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/advancedlabel/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/bidi/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/bidi/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/insettext/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/insettext/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/searchbox/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/searchbox/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/simplelabel/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/simplelabel/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/textfield/preview.png !
Re: Reloading stylesheets
The way it works in 8.0 is that there is a cache of loaded stylesheets. When a scene or parent adds a stylesheet, the stylesheet is added to the cache. Any other scene or parent that uses the same stylesheet will get the one from cache. If a scene or parent later removes the stylesheet, the stylesheet is removed from the cache and the css style cache for any scene or parent that referenced that stylesheet is cleared (since the set of styles may have changed). Any scene or parent that referenced the now removed stylesheet is told to reapply its styles. Since the stylesheet is no longer in cache, it will be re-parsed (or reloaded if there is a binary version of the stylesheet) when it is called for by a scene or parent. The way it worked in 2.x was an abomination. On Dec 10, 2013, at 10:30 AM, Werner Lehmann lehm...@media-interactive.de wrote: Interesting. Assuming the stylesheets are still cached, how would it know when to reload and not use the cached sheet? Or has sheet processing been optimized so much that caching is not necessary anymore... On 10.12.2013 16:15, Tom Schindl wrote: No on FX8 you need to remove and readd them! So the only thing different is that you omit the reload-call on FX8.
Re: Reloading stylesheets
Makes sense. Thanks! On 10.12.2013 17:09, David Grieve wrote: The way it works in 8.0 is that there is a cache of loaded stylesheets. [...]
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany
Fwd: Reloading stylesheets
It would be nice if there were some documentation for how to get around the memory leak in stylesheets in 7x (since most of us won't be upgrading to 8 until it's actually released). And in general if there were some performance guidelines for JavaFX that would be really helpful. There was some mention of when (and when not) to use *Platform.runLater*. Avoiding memory leaks in multi-threaded code, guidelines for threadpool tuning so that apps stay responsive, etc. The Best Practiceshttp://docs.oracle.com/javafx/2/best_practices/jfxpub-best_practices.htm document provides a start but more details would be useful. Cheers, Mark -- Forwarded message -- From: Werner Lehmann lehm...@media-interactive.de Date: Tue, Dec 10, 2013 at 9:03 AM Subject: Re: Reloading stylesheets To: Cc: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net Makes sense. Thanks! On 10.12.2013 17:09, David Grieve wrote: The way it works in 8.0 is that there is a cache of loaded stylesheets. [...]
hg: openjfx/8/graphics/rt: [Samples Only][RT-33754] Ensemble Icons
Changeset: 3852407693a0 Author:John Yoon john.y...@oracle.com Date: 2013-12-10 09:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3852407693a0 [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/changelistener/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/changelistener/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/observablelist/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/observablelist/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/stringbinding/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/stringbinding/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/swing/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/language/swing/prev...@2x.png
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am
hg: openjfx/8/graphics/rt: [Samples Only][RT-33754] Ensemble Icons
Changeset: 6a8c274547fa Author:John Yoon john.y...@oracle.com Date: 2013-12-10 10:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a8c274547fa [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/anchorpane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/anchorpane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/borderpane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/borderpane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/flowpane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/flowpane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/gridpane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/gridpane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/hbox/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/hbox/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/stackpane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/stackpane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/tilepane/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/tilepane/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/vbox/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/layout/vbox/prev...@2x.png
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/ mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until
hg: openjfx/8/graphics/rt: RT-21569: Document that applications should avoid flooding FX with Platform.runLater calls
Changeset: 2a14ca6aedf3 Author:kcr Date: 2013-12-10 10:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2a14ca6aedf3 RT-21569: Document that applications should avoid flooding FX with Platform.runLater calls Reviewed-by: anthony ! modules/graphics/src/main/java/javafx/application/Platform.java
hg: openjfx/8/graphics/rt: [Samples Only][RT-33754] Ensemble Icons
Changeset: 8a1e5a4a8a19 Author:John Yoon john.y...@oracle.com Date: 2013-12-10 10:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8a1e5a4a8a19 [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/advancedmedia/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/advancedmedia/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/alphamediaplayer/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/alphamediaplayer/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/audioclip/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/audioclip/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/overlaymediaplayer/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/overlaymediaplayer/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/streamingmediaplayer/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/streamingmediaplayer/prev...@2x.png
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Right, I guess what I was really asking was is there any way to craft a LW/HW integration solution that *doesn't* have nasty limitations? On 11 December 2013 07:11, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was critical that your application do something like embed Excel, then it could live with the limitations. Perhaps you work in a company where you have a custom native control that you are already embedding in Swing and you want to migrate to FX. These sorts of applications could live with the limitations. Steve On 2013-12-10 3:03 PM, Felix Bembrick wrote: Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: a434b613d697 Author:mv157916 Date: 2013-12-06 11:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a434b613d697 RT-34731: Update the JDK 8 build number to b119 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 8e8958c52331 Author:kcr Date: 2013-12-10 12:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8e8958c52331 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fdt ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fdx ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fnm ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.frq ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.nrm ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.prx ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.tii ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.tis ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/segments_1 - apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/timeline/timeline/TimelineApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/timeline/timelineevents/TimelineEventsApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/canvas/fireworks/FireworksApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/canvas/fireworks/Particle.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/canvas/fireworks/SanFranciscoFireworks.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bubble/chart/BubbleChartApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/Candle.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/CandleStickChart.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/CandleStickChartApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/CandleStickExtraValues.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/TooltipContent.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/DailySales.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/GetDailySalesService.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/GetDailySalesTask.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/ServiceApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/task/DailySales.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/task/GetDailySalesTask.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/task/TaskApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/splitpane/hiddensplitpane/HiddenSplitPaneApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/tab/tabpane/TabPaneApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/Person.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tableview/Person.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tableview/TableViewApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Part.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/fxml/fxmldemo/Authenticator.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/fxml/fxmldemo/FXMLLoginDemoApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/fxml/fxmldemo/LoginController.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/fxml/fxmldemo/ProfileController.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/fxml/fxmldemo/User.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/Ball.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BallsPane.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BallsScreen.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BouncingBallsApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/Constants.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Ball.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Bat.java -
hg: openjfx/8/graphics/rt: [Doc only] RT-26385: Finish javadoc for FX 8 3D API
Changeset: 35d622e670f1 Author:Chien Yang chien.y...@oracle.com Date: 2013-12-10 12:43 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/35d622e670f1 [Doc only] RT-26385: Finish javadoc for FX 8 3D API Reviewed-by: kcr, vadim ! modules/graphics/src/main/java/javafx/scene/SubScene.java ! modules/graphics/src/main/java/javafx/scene/paint/PhongMaterial.java
RE: Reloading stylesheets
And in general if there were some performance guidelines for JavaFX that would be really helpful. There is an open-jfx wiki page for JavaFX Performance Tips and Tricks, you could check that and see if it is helpful (if it's not maybe you could edit it and add a new section on performance issues you would like to see discussed or documented): https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks There are some JavaOne presentations on Performance topic: http://www.youtube.com/watch?feature=player_embeddedv=ddJpDi5SWFc http://parleys.com/play/514892290364bc17fc56c3c5/chapter26/about John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mark Fortner Sent: Tuesday, December 10, 2013 9:39 AM To: openjfx-dev@openjdk.java.net Subject: Fwd: Reloading stylesheets It would be nice if there were some documentation for how to get around the memory leak in stylesheets in 7x (since most of us won't be upgrading to 8 until it's actually released). And in general if there were some performance guidelines for JavaFX that would be really helpful. There was some mention of when (and when not) to use *Platform.runLater*. Avoiding memory leaks in multi-threaded code, guidelines for threadpool tuning so that apps stay responsive, etc. The Best Practiceshttp://docs.oracle.com/javafx/2/best_practices/jfxpub-best_practices.htm document provides a start but more details would be useful. Cheers, Mark -- Forwarded message -- From: Werner Lehmann lehm...@media-interactive.de Date: Tue, Dec 10, 2013 at 9:03 AM Subject: Re: Reloading stylesheets To: Cc: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net Makes sense. Thanks! On 10.12.2013 17:09, David Grieve wrote: The way it works in 8.0 is that there is a cache of loaded stylesheets. [...]
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-33410 Ensemble8: BrickBreaker jumps sometimes
Changeset: afa4eebb73b8 Author:Alexander Kouznetsov Date: 2013-12-10 11:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/afa4eebb73b8 Ensemble8: Fix for RT-33410 Ensemble8: BrickBreaker jumps sometimes ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics2d/brickbreaker/BrickBreakerApp.java
