hg: openjfx/8u-dev/rt: RT-37409 [DatePicker, RTL, Regression] RTL DatePicker drop down positioned in the wrong place after changing showWeekNumbers property (regression)
Changeset: 70b72d969e74 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-12 08:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/70b72d969e74 RT-37409 [DatePicker, RTL, Regression] RTL DatePicker drop down positioned in the wrong place after changing showWeekNumbers property (regression) Reviewed by: dgrieve ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java
Blurry strokes and zooming via scale transforms
Hi all, I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, e.g. for a non-integer stroke width, or a stroke width of 1 and StrokeType.CENTERED. So far my 'solution' to this problem has been to round layout values to integers, or to round and add 0.5 in the StrokeType.CENTERED case. However this approach is pretty useless if I apply a scale transform afterwards, which is the simplest way I know to create a zooming mechanism. So my question is: is there any way I can round things to integer values *after* transforms have been applied? Or tell the renderer to not try to approximate strokes drawn 'off-pixel' but instead to round move them to the nearest pixel so that lines look sharp and clean? Any tips would be appreciated. Cheers, Rob
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: a208c5310449 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-12 11:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a208c5310449 RT-37516 JavaBeanObjectPropertyBuilder not reusable when used with different classes ! modules/base/src/main/java/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java ! modules/base/src/test/java/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelperTest.java Changeset: 2118045d6f67 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-12 11:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2118045d6f67 RT-37493 [StackedAreaChart] does not test for empty series causing AIOOBE Reviewed by: jgiles Contributed by: snorthov ! modules/controls/src/main/java/javafx/scene/chart/StackedAreaChart.java
Re: Blurry strokes and zooming via scale transforms
I recently had a similar situation, but then because certain properties were calculated-via-binding and the resulting value was not snapped to good values either. This resulted in my suggestion to allow custom calculations in bindings, which would then snap the value. https://javafx-jira.kenai.com/browse/RT-37255 And transformations on such values have the same effect of course. I was wondering, similar to the binding suggestion, would it be possible to apply a snapping transformation as the last transformation? Tom On 2014-6-12 10:56, Robert Fisher wrote: Hi all, I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, e.g. for a non-integer stroke width, or a stroke width of 1 and StrokeType.CENTERED. So far my 'solution' to this problem has been to round layout values to integers, or to round and add 0.5 in the StrokeType.CENTERED case. However this approach is pretty useless if I apply a scale transform afterwards, which is the simplest way I know to create a zooming mechanism. So my question is: is there any way I can round things to integer values *after* transforms have been applied? Or tell the renderer to not try to approximate strokes drawn 'off-pixel' but instead to round move them to the nearest pixel so that lines look sharp and clean? Any tips would be appreciated. Cheers, Rob
AW: Blurry strokes and zooming via scale transforms
Well suppose I have a Rectangle with a size of 100x100 and stroke-width of 1, and I apply a scale transform to zoom in to 150%. Then I would like to see a size of 150x150 pixels and still see a sharp border stroke, let's say with a width of 2 pixels. I'm not sure how I could apply a snapping transformation to just correct stroke widths and not disturb the size of the shapes themselves. Cheers, Rob -Ursprüngliche Nachricht- Von: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] Im Auftrag von Tom Eugelink Gesendet: Donnerstag, 12. Juni 2014 11:42 An: openjfx-dev@openjdk.java.net Betreff: Re: Blurry strokes and zooming via scale transforms I recently had a similar situation, but then because certain properties were calculated-via-binding and the resulting value was not snapped to good values either. This resulted in my suggestion to allow custom calculations in bindings, which would then snap the value. https://javafx-jira.kenai.com/browse/RT-37255 And transformations on such values have the same effect of course. I was wondering, similar to the binding suggestion, would it be possible to apply a snapping transformation as the last transformation? Tom On 2014-6-12 10:56, Robert Fisher wrote: Hi all, I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, e.g. for a non-integer stroke width, or a stroke width of 1 and StrokeType.CENTERED. So far my 'solution' to this problem has been to round layout values to integers, or to round and add 0.5 in the StrokeType.CENTERED case. However this approach is pretty useless if I apply a scale transform afterwards, which is the simplest way I know to create a zooming mechanism. So my question is: is there any way I can round things to integer values *after* transforms have been applied? Or tell the renderer to not try to approximate strokes drawn 'off-pixel' but instead to round move them to the nearest pixel so that lines look sharp and clean? Any tips would be appreciated. Cheers, Rob
[8u26] Review request RT-37508: [Monocle] Support 16-bit software-rendered framebuffer
Hi Dave, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37508 Thanks, Daniel
[8u26] Review request RT-37512: [Monocle] Provide a software-rendered cursor
Hi Dave and Lisa, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37512 Thanks, Daniel
hg: openjfx/8u-dev/rt: RT-36960 [Monocle] A switch to change between frame buffers
Changeset: 9a539116a956 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-06-12 15:11 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9a539116a956 RT-36960 [Monocle] A switch to change between frame buffers Reviewed-by: kselle ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanAcceleratedScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/FBDevScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxFrameBuffer.java ! modules/graphics/src/main/native-glass/monocle/dispman/DispmanAcceleratedScreen.c
[8u26] Review Request RT-37513 [Monocle] Should not show an exception trace when falling back to software rendering
Hi Daniel, Please review the proposed fix for https://javafx-jira.kenai.com/browse/RT-37513 Details in jira. Thanks, Lisa
hg: openjfx/8u-dev/rt: RT-35729 [Monocle/TESTS] Swipe does not work on Monocle in HelloSanity
Changeset: 286217918102 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-06-12 18:51 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/286217918102 RT-35729 [Monocle/TESTS] Swipe does not work on Monocle in HelloSanity + tests/system/src/test/java/com/sun/glass/ui/monocle/input/SwipeTest.java
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: ec2c900e6037 Author:hudson Date: 2014-06-10 21:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ec2c900e6037 Added tag 8u20-b18 for changeset 63955f844c0c ! .hgtags Changeset: 169d6b8b6386 Author:kcr Date: 2014-06-12 09:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/169d6b8b6386 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8u/master/jfx/rt
RE: Blurry strokes and zooming via scale transforms
A couple of related stackoverflow questions won't solve your problem, but will provide some background info: http://stackoverflow.com/questions/16089304/javafx-imageview-without-any-smoothing http://stackoverflow.com/questions/11886230/how-to-draw-a-crisp-opaque-hairline-in-javafx-2-2 http://stackoverflow.com/questions/11881834/what-are-a-lines-exact-dimensions-in-javafx-2 -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Robert Fisher Sent: Thursday, June 12, 2014 3:10 AM To: openjfx-dev@openjdk.java.net Subject: AW: Blurry strokes and zooming via scale transforms Well suppose I have a Rectangle with a size of 100x100 and stroke-width of 1, and I apply a scale transform to zoom in to 150%. Then I would like to see a size of 150x150 pixels and still see a sharp border stroke, let's say with a width of 2 pixels. I'm not sure how I could apply a snapping transformation to just correct stroke widths and not disturb the size of the shapes themselves. Cheers, Rob -Ursprüngliche Nachricht- Von: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] Im Auftrag von Tom Eugelink Gesendet: Donnerstag, 12. Juni 2014 11:42 An: openjfx-dev@openjdk.java.net Betreff: Re: Blurry strokes and zooming via scale transforms I recently had a similar situation, but then because certain properties were calculated-via-binding and the resulting value was not snapped to good values either. This resulted in my suggestion to allow custom calculations in bindings, which would then snap the value. https://javafx-jira.kenai.com/browse/RT-37255 And transformations on such values have the same effect of course. I was wondering, similar to the binding suggestion, would it be possible to apply a snapping transformation as the last transformation? Tom On 2014-6-12 10:56, Robert Fisher wrote: Hi all, I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, e.g. for a non-integer stroke width, or a stroke width of 1 and StrokeType.CENTERED. So far my 'solution' to this problem has been to round layout values to integers, or to round and add 0.5 in the StrokeType.CENTERED case. However this approach is pretty useless if I apply a scale transform afterwards, which is the simplest way I know to create a zooming mechanism. So my question is: is there any way I can round things to integer values *after* transforms have been applied? Or tell the renderer to not try to approximate strokes drawn 'off-pixel' but instead to round move them to the nearest pixel so that lines look sharp and clean? Any tips would be appreciated. Cheers, Rob
please review: RT-36335: [Accessibility] Hide prototype API
Hi, Please review https://javafx-jira.kenai.com/browse/RT-36335 http://cr.openjdk.java.net/~fheidric/RT36335/webrev/ Note: JDK 8u20 Build b18 is the last build in the 8u20 serie to include accessibility. The accessibility code will be put back in the 8u-dev repo after the 8u20 fork, and it will be available again in the first 8u40 build. We don’t have a build schedule for 8u40, but it should start a few weeks after the 8u20 fork. Thanks Felipe
Adding application-wide stylesheet
Hi, RT-18543 has been closed as not an issue with the following explanation: API exists in Application for this: http://download.java.net/jdk8/jfxdocs/javafx/application/Application.html#setUserAgentStylesheet-java.lang.String- But that does not the same thing as it replaces the default (modena) stylesheet, which is not what people asking this including the original poster usually want (see also http://stackoverflow.com/questions/16318517/how-do-i-dynamically-add-and-remove-css-for-the-whole-javafx-application). What is the reason not to expose what StyleManager.getInstance().addUserAgentStylesheet(...) does somewhere in public API like in Application? Thanks, Robert
Re: Adding application-wide stylesheet
In 8u20, you can use @import in your .css file. That, along with Application#setUserAgentStylesheet(String), should do the trick. If I'm missing something, then please feel free to create a new feature request in JIRA. On 6/12/14, 4:57 PM, Robert Krüger wrote: Hi, RT-18543 has been closed as not an issue with the following explanation: API exists in Application for this: http://download.java.net/jdk8/jfxdocs/javafx/application/Application.html#setUserAgentStylesheet-java.lang.String- But that does not the same thing as it replaces the default (modena) stylesheet, which is not what people asking this including the original poster usually want (see also http://stackoverflow.com/questions/16318517/how-do-i-dynamically-add-and-remove-css-for-the-whole-javafx-application). What is the reason not to expose what StyleManager.getInstance().addUserAgentStylesheet(...) does somewhere in public API like in Application? Thanks, Robert
Re: Adding application-wide stylesheet
How would one reference the stylesheet location of the default style sheet packaged with the JRE in the import statement? On Thu, Jun 12, 2014 at 11:34 PM, David Grieve david.gri...@oracle.com wrote: In 8u20, you can use @import in your .css file. That, along with Application#setUserAgentStylesheet(String), should do the trick. If I'm missing something, then please feel free to create a new feature request in JIRA. On 6/12/14, 4:57 PM, Robert Krüger wrote: Hi, RT-18543 has been closed as not an issue with the following explanation: API exists in Application for this: http://download.java.net/jdk8/jfxdocs/javafx/application/Application.html#setUserAgentStylesheet-java.lang.String- But that does not the same thing as it replaces the default (modena) stylesheet, which is not what people asking this including the original poster usually want (see also http://stackoverflow.com/questions/16318517/how-do-i-dynamically-add-and-remove-css-for-the-whole-javafx-application). What is the reason not to expose what StyleManager.getInstance().addUserAgentStylesheet(...) does somewhere in public API like in Application? Thanks, Robert -- Robert Krüger Managing Partner Lesspain GmbH Co. KG www.lesspain-software.com
hg: openjfx/8u-dev/rt: RT-37538: TableView SelectionModel selected items listener can cause an infinite loop.
Changeset: 9f5303fb78fb Author:jgiles Date: 2014-06-13 12:36 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9f5303fb78fb RT-37538: TableView SelectionModel selected items listener can cause an infinite loop. ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java
[8u20] review request: RT-37539: [Builders] Web builder classes not built unless COMPILE_WEBKIT=true
David, Please review the following simple patch. https://javafx-jira.kenai.com/browse/RT-37539 The patch is in the JIRA. -- Kevin
Re: Proportional TableColumn resizing
Kirill, This is not presently possible (as far as I know - although with enough courage I'm sure a custom column resize policy could be set on the TableView to do this). You might also want to look at the existing TableView constrained resize policy - this may help you out a little (as it forces the columns to take up all available space). There is a jira issue for percentage sizing: https://javafx-jira.kenai.com/browse/RT-17180 I suggest you leave any thoughts or votes on that issue. Currently it is untargeted. -- Jonathan On 12/06/2014 2:56 a.m., Kirill Kirichenko wrote: Hi all. How is it possible to create TableColumns (preferably in fxml) such that they have some proportional width say in percents rather than in pixels with a feature that when we resize the table the columns get resized proportionally ? Default behaviour is that when the window containing a table is grown in width all columns keep the width and one extra column appear that has no data. K
Re: Bundler question for Mac OS X...
Hi Danno, I am using 1.8.0.0 and it does not work. Only the main menu item changes with the name. I will download prod 8u5 and try this. Where can I download the pkg for 8U20? Thanks, -Tony On Wednesday, June 11, 2014 9:48 AM, Tony Anecito adanec...@yahoo.com wrote: Thanks Danno I will try tonight with your suggestion. I will let you know the results. This is the last thing holding up approval of my app for the store. Best Regards, -Tony On Wednesday, June 11, 2014 8:22 AM, Danno Ferrin danno.fer...@oracle.com wrote: It does change the sub-menu items (Hide foo/Quit foo), at least the 8u20 toolchain does. I would expect the 8u5 toolchain to change it too because it looks the same, but I haven’t worked on those builds recently. On Jun 11, 2014, at 8:05 AM, Tony Anecito adanec...@yahoo.com wrote: I will try your suggestion to see if the sub-menu items name changes with what you sugggested. Thanks, -Tony On , Tony Anecito adanec...@yahoo.com wrote: Hi, The name attribute affects the main menu item but not the sub-menu items. Not sure if you understood what I meant by sub-menu items. It would be better if the sub-menu items did not use the starting/launcher class name. I even found examples googleing where java main.startupclassname was shown for sub-menu items. Apple iTunes store will reject java apps becuase of this issue. They want the app name to match everywhere on the app including the sub-menu item names. Thanks, -Tony On Wednesday, June 11, 2014 7:50 AM, Danno Ferrin danno.fer...@oracle.com wrote: This will be upgraded in the 8u20 release. For pre8u20 in the ant script the menu bar name is the name attribute from the application element. fx:deploy … !-- … -- fx:application id=“com.example.your.mac.App” name=“Your App”/ !-- … -- /fx:deploy (This will still work in 8u20, if it doesn’t it is a bug to me I will fix). The down side is that some of those value have double use when using multiple platforms. For example the id attribute is also the UUID for MSI bundles. The name is also the name of the launcher file too, and pre 8u20 they are tied together (unless you do a drop in resource to manually fix the identifier). Starting with 8u20 you can specify bundle params, and I have done my best to eliminate the overlapping values, or at least allow you to set specific values that will fall back to overlapping values. fx:deploy … !-- … -- fx:bundleArgument arg=“mac.CFBundleIdentifier” value=“com.example.your.mac.App”/ fx:bundleArgument arg=“mac.CFBundleName” value=“Your App”/ !-- … -- /fx:deploy Since the windows bundlers don’t understand those arguments they will ignore them. And the bundle name can be different from the launcher name now as well. On Jun 11, 2014, at 4:16 AM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi Tony, I don't know the exact syntax for the FX deploy script (is it the -title or -name option for the javafxpackager [1] ?), however [2] suggests that the CFBundleName key in Info.plist can be used to set the application name. I can confirm that Glass reads the value and assigns it to the application name. The Quit menu item then uses this name for its text label. Does setting the CFBundleName work for you? [1] http://docs.oracle.com/javafx/2/deployment/javafxpackager.htm [2] https://javafx-jira.kenai.com/browse/RT-18563 -- best regards, Anthony On 6/11/2014 7:54 AM, Tony Anecito wrote: Hi All, I noticed the menu bar for OS X is probably using my class name that has the static main in it. How do I override that in the JavFX Deploy ant script? The About, Hide and Quit sub-menu items are using a different name than what I want. The main menu item is correct. Thanks! Tony
