Re: The rise and fall of Builders
I know, the question was based on the best to cycle off builders remark, then what is advised to use as an alternative? Tom On 2013-08-30 06:56, Richard Bair wrote: You can still use your own Builders and plug them into FXML. Its just that the built in set won't be there. But the Builder base class and all the FXML support is still there. All mentioned in that long thread :-D Richard On Aug 29, 2013, at 9:50 PM, Tom Eugelink t...@tbee.org wrote: This week I ran into the problem that I needed to provide a date format (attribute in FXML) to one of my controls. So I needed a way to convert a string to DateFormat, or even a comma separated list to a list of DateFormats. This I solved with a builder for that control. How would one solved that without builders? (What is the alternative to builders?) Tom On 2013-08-29 22:42, Richard Bair wrote: Deprecated in 8 and removed from the JavaDoc, gone in 9 (will be available as a separately downloadable Jar so you can keep using them, but they won't be updated). We're removing them from samples. Best to cycle off the builders. Richard On Aug 29, 2013, at 12:42 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Thanks Jonathan, So what is Oracle's current position on this? Are Builders in or out? If out, when will they be removed and how? On 30 August 2013 05:31, Jonathan Giles jonathan.gi...@oracle.com wrote: You can catch up on the back story here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-March/006725.html -- Jonathan On 30/08/2013 7:06 a.m., Felix Bembrick wrote: I was not privy to the original discussion but I am lead to believe that Builders are no longer considered fashionable and that we are advised not to use them. While I realise that every type of Node basically needed its own Builder, could someone please outline why this situation has arisen? Is it something to do with fluent APIs themselves or some other reason? Thanks, Felix
Re: The rise and fall of Builders
Using your own builders is fine, I mean you best not use the deprecated ones as they will be disappearing. On Aug 29, 2013, at 10:56 PM, Tom Eugelink t...@tbee.org wrote: I know, the question was based on the best to cycle off builders remark, then what is advised to use as an alternative? Tom On 2013-08-30 06:56, Richard Bair wrote: You can still use your own Builders and plug them into FXML. Its just that the built in set won't be there. But the Builder base class and all the FXML support is still there. All mentioned in that long thread :-D Richard On Aug 29, 2013, at 9:50 PM, Tom Eugelink t...@tbee.org wrote: This week I ran into the problem that I needed to provide a date format (attribute in FXML) to one of my controls. So I needed a way to convert a string to DateFormat, or even a comma separated list to a list of DateFormats. This I solved with a builder for that control. How would one solved that without builders? (What is the alternative to builders?) Tom On 2013-08-29 22:42, Richard Bair wrote: Deprecated in 8 and removed from the JavaDoc, gone in 9 (will be available as a separately downloadable Jar so you can keep using them, but they won't be updated). We're removing them from samples. Best to cycle off the builders. Richard On Aug 29, 2013, at 12:42 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Thanks Jonathan, So what is Oracle's current position on this? Are Builders in or out? If out, when will they be removed and how? On 30 August 2013 05:31, Jonathan Giles jonathan.gi...@oracle.com wrote: You can catch up on the back story here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-March/006725.html -- Jonathan On 30/08/2013 7:06 a.m., Felix Bembrick wrote: I was not privy to the original discussion but I am lead to believe that Builders are no longer considered fashionable and that we are advised not to use them. While I realise that every type of Node basically needed its own Builder, could someone please outline why this situation has arisen? Is it something to do with fluent APIs themselves or some other reason? Thanks, Felix
hg: openjfx/8/graphics/rt: RT-32603: Bad analysis in NGGroup#computeRenderRoot results in Nodes being rendered that need not be
Changeset: a2677d23fe0e Author:rbair Date: 2013-08-30 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a2677d23fe0e RT-32603: Bad analysis in NGGroup#computeRenderRoot results in Nodes being rendered that need not be ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGTestBase.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/OcclusionCullingTest.java
Re: Bad quality of Node.snapshot
Might be this one: https://javafx-jira.kenai.com/browse/RT-31909 On Aug 30, 2013, at 1:47 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been using Node.snapshot() and found out that the quality of the snapshots is very bad (on OS-X Retina?). Take a look at http://downloads.efxclipse.org/screenshot.png the upper one is the really rendered element and the 2nd is a snapshot take from the control and rendered as an image. An idea why? Tom
Re: Bad quality of Node.snapshot
Actually I was just on my way to fix this (and a couple other Region bugs) :-) On Aug 30, 2013, at 2:07 PM, Richard Bair richard.b...@oracle.com wrote: Might be this one: https://javafx-jira.kenai.com/browse/RT-31909 On Aug 30, 2013, at 1:47 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been using Node.snapshot() and found out that the quality of the snapshots is very bad (on OS-X Retina?). Take a look at http://downloads.efxclipse.org/screenshot.png the upper one is the really rendered element and the 2nd is a snapshot take from the control and rendered as an image. An idea why? Tom
Re: Bad quality of Node.snapshot
seems to be the same whe Gerrit Grunwald Westfalenstrasse 93 48165 Münster - Germany - mailhan.s...@muenster.de webharmonic-code.org twitter @hansolo_ Am 30.08.2013 um 22:47 schrieb Tom Schindl tom.schi...@bestsolution.at: Hi, I've been using Node.snapshot() and found out that the quality of the snapshots is very bad (on OS-X Retina?). Take a look at http://downloads.efxclipse.org/screenshot.png the upper one is the really rendered element and the 2nd is a snapshot take from the control and rendered as an image. An idea why? Tom
hg: openjfx/8/graphics/rt: RT-32639: NGRegion can avoid invalidating the backgroundInsets if the Background in question does not have any percentage-based CornerRadii on any BackgroundFills
Changeset: 49f80deda70a Author:rbair Date: 2013-08-30 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/49f80deda70a RT-32639: NGRegion can avoid invalidating the backgroundInsets if the Background in question does not have any percentage-based CornerRadii on any BackgroundFills ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/javafx/scene/layout/Background.java ! modules/graphics/src/test/java/javafx/scene/layout/BackgroundTest.java
hg: openjfx/8/controls/rt: RT-31349: TextField, bidi text drifts when caret moves to bidi boundary.
Changeset: 089d0e8cb4d6 Author:leifs Date: 2013-08-30 14:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/089d0e8cb4d6 RT-31349: TextField, bidi text drifts when caret moves to bidi boundary. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java
Static FXMLLoader load method deprecation
The static methods on FXMLLoader are very confusing. It is very easy to create errors by writing code that mixes static and instance FXMLLoader methods. Everything that can be done with static load methods, can be done with instance FXMLLoader methods. Other than confusion, the static load methods seem to provide little value to me. Is it possible to have the static FXMLLoader methods deprecated for Java 8?
Re: Static FXMLLoader load method deprecation
+1 On 31/08/2013, at 8:54 AM, John Smith john_sm...@symantec.com wrote: The static methods on FXMLLoader are very confusing. It is very easy to create errors by writing code that mixes static and instance FXMLLoader methods. Everything that can be done with static load methods, can be done with instance FXMLLoader methods. Other than confusion, the static load methods seem to provide little value to me. Is it possible to have the static FXMLLoader methods deprecated for Java 8?
hg: openjfx/8/graphics/rt: Minor comment fixes to NGRegion, also minor change to RegionImageCache to have the constructor take a ResourceFactory instead of a Graphics object (since the Graphics object
Changeset: a8e13d82e298 Author:rbair Date: 2013-08-30 22:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a8e13d82e298 Minor comment fixes to NGRegion, also minor change to RegionImageCache to have the constructor take a ResourceFactory instead of a Graphics object (since the Graphics object was only used to get at its resource factory, and it is better style to pass what is really needed instead of a carrier). ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/RegionImageCache.java
