From hang.vo at oracle.com Sat Mar 1 10:09:16 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 01 Mar 2014 18:09:16 +0000 Subject: hg: openjfx/8/master/rt: Added tag 8.0-b131 for changeset 4ef7286b9266 Message-ID: <20140301180940.3D16462433@hg.openjdk.java.net> Changeset: e2fd0ac9762b Author: hudson Date: 2014-03-01 09:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e2fd0ac9762b Added tag 8.0-b131 for changeset 4ef7286b9266 ! .hgtags From tbee at tbee.org Sat Mar 1 23:42:48 2014 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 02 Mar 2014 08:42:48 +0100 Subject: Image by CSS and popup size Message-ID: <5312E0F8.5050204@tbee.org> In the datetime textfields in JFXtras, the picker popup has an explicit close button rendered using an ImageView, the image is specified using CSS "-fx-image". This ImageView is added as the right of a BorderPane, and the BorderPane is the content of a popup. What happens is that the close image is not shown. I suspect this is because the CSS is applied after the popup is opened, so the ImageView initially has a width of 0. For the moment I enforce a width using setFitWidth(16), but that of course is not the idea of styling via CSS. Trying to preload the ImageView is not possible, because it is not part of any scene/stage until the popup is shown and therefore its CSS is not applied until then. Preloading the image is not possible, because it is styled through CSS. I'm stuck; how do I make sure the popup sizes to the correct width, taking the CSS styled image in account? Tom From hang.vo at oracle.com Sun Mar 2 00:34:41 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 02 Mar 2014 08:34:41 +0000 Subject: hg: openjfx/8u-dev/rt: [TEST-ONLY] [RT-36035] remove lens check from EGalaxTest.testDoubleClick2 Message-ID: <20140302083736.AB6306243E@hg.openjdk.java.net> Changeset: a65b185a39c3 Author: Assaf Yavnai Date: 2014-03-02 10:22 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a65b185a39c3 [TEST-ONLY] [RT-36035] remove lens check from EGalaxTest.testDoubleClick2 Summary: After RT-35536 have been fixed there is no longer a reason to exclude EGalaxTest.testDoubleClick2 test in Lens Review-by: dblaukopf ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/DoubleClickTest.java From jeff at reportmill.com Sun Mar 2 08:33:11 2014 From: jeff at reportmill.com (Jeff Martin) Date: Sun, 2 Mar 2014 10:33:11 -0600 Subject: Image by CSS and popup size In-Reply-To: <5312E0F8.5050204@tbee.org> References: <5312E0F8.5050204@tbee.org> Message-ID: Recently I had a problem where I wanted to show a popup centered about a node, so I used a little hack to trigger Window's sizing before it became visible: popup.setOpacity(0); popup.show(); popup.hide(); popup.setOpacity(1); I wonder what would happen if you added that line, then did a popup.sizeToScene() before you did the real show? jeff On Mar 2, 2014, at 1:42 AM, Tom Eugelink wrote: > > In the datetime textfields in JFXtras, the picker popup has an explicit close button rendered using an ImageView, the image is specified using CSS "-fx-image". > This ImageView is added as the right of a BorderPane, and the BorderPane is the content of a popup. > > What happens is that the close image is not shown. I suspect this is because the CSS is applied after the popup is opened, so the ImageView initially has a width of 0. For the moment I enforce a width using setFitWidth(16), but that of course is not the idea of styling via CSS. > > Trying to preload the ImageView is not possible, because it is not part of any scene/stage until the popup is shown and therefore its CSS is not applied until then. > Preloading the image is not possible, because it is styled through CSS. > > I'm stuck; how do I make sure the popup sizes to the correct width, taking the CSS styled image in account? > > Tom > > From hang.vo at oracle.com Mon Mar 3 10:03:48 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Mar 2014 18:03:48 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36038: [DND] FX sometimes forgets to invoke Node.onDragDetected() on Mac Message-ID: <20140303180455.EBFBA6246B@hg.openjdk.java.net> Changeset: bc510bc82416 Author: Anthony Petrov Date: 2014-03-03 21:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bc510bc82416 RT-36038: [DND] FX sometimes forgets to invoke Node.onDragDetected() on Mac Summary: Synthesize missing mouseUp events Reviewed-by: snorthov ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.h ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.m From hang.vo at oracle.com Mon Mar 3 10:33:08 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Mar 2014 18:33:08 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35197: Use Lambda in FX runtime and samples [experiments: 3DViewer, Modena] Message-ID: <20140303183329.D51D76246E@hg.openjdk.java.net> Changeset: a46da8e2262b Author: snorthov Date: 2014-03-03 13:26 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a46da8e2262b RT-35197: Use Lambda in FX runtime and samples [experiments: 3DViewer, Modena] Summary: This component was lambdified (unlambdified file names recorded in the JIRA) Reviewed-by: lisa.selle ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalApp.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Loader.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MConnection.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/FourWayNavControl.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Jfx3dViewerApp.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SessionManager.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SettingsController.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SkinningMesh.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SubdivisionMesh.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/utils3d/DragSupport.java ! apps/experiments/Modena/src/main/java/modena/Modena.java ! apps/experiments/Modena/src/main/java/modena/SameHeightTestController.java ! apps/experiments/Modena/src/main/java/modena/SamplePageHelpers.java ! apps/experiments/Modena/src/main/java/modena/SamplePageNavigation.java ! apps/experiments/Modena/src/main/java/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/main/java/modena/SamplePageTreeTableHelper.java ! apps/experiments/Modena/src/main/java/modena/SimpleWindowPage.java From steve.x.northover at oracle.com Mon Mar 3 12:43:13 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 03 Mar 2014 15:43:13 -0500 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <530E64C7.2080403@oracle.com> References: <530E0BF1.5050302@oracle.com> <530E64C7.2080403@oracle.com> Message-ID: <5314E961.6080602@oracle.com> Hi Anthony, Please review the lambdification of the swing component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please coordinate with me and I will re-lambdify to include the changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve From hang.vo at oracle.com Mon Mar 3 12:48:03 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Mar 2014 20:48:03 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35197: Use Lambda in FX runtime and samples [swt] Message-ID: <20140303204849.3BA4162476@hg.openjdk.java.net> Changeset: 4742b5a6eb9b Author: snorthov Date: 2014-03-03 15:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4742b5a6eb9b RT-35197: Use Lambda in FX runtime and samples [swt] Summary: This component was lambdified (unlambdified file names recorded in the JIRA) ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java ! modules/swt/src/main/java/javafx/embed/swt/SWTFXUtils.java From hang.vo at oracle.com Mon Mar 3 14:48:16 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Mar 2014 22:48:16 +0000 Subject: hg: openjfx/8u-dev/rt: While lambdifying 3DViewer, it was discovered that it no longer finds loaders when launched from the IDE. This fix looks for a well known set of loaders after first trying to load them from an external jar. Message-ID: <20140303224835.5FCE06247A@hg.openjdk.java.net> Changeset: e164a77392b6 Author: snorthov Date: 2014-03-03 17:33 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e164a77392b6 While lambdifying 3DViewer, it was discovered that it no longer finds loaders when launched from the IDE. This fix looks for a well known set of loaders after first trying to load them from an external jar. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer3D.java From hang.vo at oracle.com Mon Mar 3 15:18:06 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Mar 2014 23:18:06 +0000 Subject: hg: openjfx/8u-dev/rt: Fix RT-35452: Canvas does not allow missing initial movetos Message-ID: <20140303231823.E0F4D6247D@hg.openjdk.java.net> Changeset: a5bf93565444 Author: flar Date: 2014-03-03 15:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a5bf93565444 Fix RT-35452: Canvas does not allow missing initial movetos Reviewed by: Martin ! modules/graphics/src/main/java/javafx/scene/canvas/GraphicsContext.java ! modules/graphics/src/test/java/javafx/scene/canvas/CanvasTest.java From chien.yang at oracle.com Mon Mar 3 15:47:03 2014 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 03 Mar 2014 15:47:03 -0800 Subject: [8u20] Review request: RT-21702 - [Touch, Windows] MouseEvents generated from touch-screen action have isSynthesized() == false Message-ID: <53151477.8020901@oracle.com> JIRA: https://javafx-jira.kenai.com/browse/RT-21702 Webrev: http://cr.openjdk.java.net/~ckyang/RT-21702/webrev.00/ Thanks, - Chien From james.graham at oracle.com Mon Mar 3 17:56:34 2014 From: james.graham at oracle.com (Jim Graham) Date: Mon, 03 Mar 2014 17:56:34 -0800 Subject: 8u20 review request: RT-35058 - Zoomy gets texture lock errors on ARM Message-ID: <531532D2.5040007@oracle.com> webrev: http://cr.openjdk.java.net/~flar/RT-35058/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-35058 ...jim From hang.vo at oracle.com Mon Mar 3 19:33:22 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 03:33:22 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36002: Defender method used in SelectedCellsMap Message-ID: <20140304033530.3010E62491@hg.openjdk.java.net> Changeset: 7fac01b6f9b8 Author: jgiles Date: 2014-02-25 13:40 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7fac01b6f9b8 RT-36002: Defender method used in SelectedCellsMap Contributed-by: snorthov Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/SelectedCellsMap.java From hang.vo at oracle.com Tue Mar 4 01:18:19 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 09:18:19 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36094 javac warning No SupportedSourceVersion annotation Message-ID: <20140304092033.D0A056249B@hg.openjdk.java.net> Changeset: ca9b98508292 Author: Martin Sladecek Date: 2014-03-04 10:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ca9b98508292 RT-36094 javac warning No SupportedSourceVersion annotation ! modules/fxml/src/main/java/com/sun/javafx/fxml/annotation/FXMLAnnotationProcessor.java From hang.vo at oracle.com Tue Mar 4 03:03:55 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 11:03:55 +0000 Subject: hg: openjfx/8u-dev/rt: RT-11175: PrismSettings.isVsyncEnabled is not taken into consideration during prism-d3d initialization Message-ID: <20140304110433.C5FC5624A0@hg.openjdk.java.net> Changeset: 085d0c62f4c8 Author: vadim Date: 2014-03-04 14:55 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/085d0c62f4c8 RT-11175: PrismSettings.isVsyncEnabled is not taken into consideration during prism-d3d initialization Reviewed-by: ckyang ! modules/graphics/src/main/native-prism-d3d/D3DContext.cc ! modules/graphics/src/main/native-prism-d3d/D3DContext.h ! modules/graphics/src/main/native-prism-d3d/D3DContextInit.cc ! modules/graphics/src/main/native-prism-d3d/D3DPipelineManager.cc ! modules/graphics/src/main/native-prism-d3d/D3DPipelineManager.h From vadim.pakhnushev at oracle.com Tue Mar 4 05:18:23 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 04 Mar 2014 17:18:23 +0400 Subject: [8u20] Review request for RT-16923: The various addListener methods should throw NPE if a null listener is passed in, rather than throwing NPE when the listener list is iterated Message-ID: <5315D29F.4060404@oracle.com> Hi Felipe, Anthony, Please review this fix: https://javafx-jira.kenai.com/browse/RT-16923 http://cr.openjdk.java.net/~vadim/RT-16923/webrev.00/ Thanks, Vadim From hang.vo at oracle.com Tue Mar 4 05:18:06 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 13:18:06 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36087 JavaBeanProperty: memory leak? Message-ID: <20140304131847.57A06624A4@hg.openjdk.java.net> Changeset: 20943f5b3791 Author: Martin Sladecek Date: 2014-03-04 14:11 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/20943f5b3791 RT-36087 JavaBeanProperty: memory leak? + modules/base/src/main/java/javafx/beans/property/adapter/DescriptorListenerCleaner.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanDoubleProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanFloatProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanIntegerProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanLongProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanObjectProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanStringProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanStringProperty.java From hang.vo at oracle.com Tue Mar 4 07:18:15 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 15:18:15 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <20140304151904.59157624B0@hg.openjdk.java.net> Changeset: 1e707c916396 Author: snorthov Date: 2014-03-04 10:07 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1e707c916396 RT-35197: Use Lambda in FX runtime and samples [swing] Summary: This component was lambdified (unlambdified file names recorded in the JIRA) ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java ! modules/swing/src/main/java/javafx/embed/swing/SwingDnD.java ! modules/swing/src/main/java/javafx/embed/swing/SwingFXUtils.java ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java Changeset: 9742326fae07 Author: snorthov Date: 2014-03-04 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9742326fae07 ECLIPSE ONLY: fix .classpath ! apps/experiments/.classpath From hang.vo at oracle.com Tue Mar 4 09:03:37 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 17:03:37 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36005: [Linux] Provide support for prerm script for Debian package Message-ID: <20140304170413.A5A2A624B2@hg.openjdk.java.net> Changeset: e8e29c6f29ba Author: shemnon Date: 2014-03-04 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e8e29c6f29ba RT-36005: [Linux] Provide support for prerm script for Debian package Summary: add blank prerm and preinst scripts for deb ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxDebBundler.java ! modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxDebBundler.properties + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.preinst + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.prerm From hang.vo at oracle.com Tue Mar 4 10:03:50 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 18:03:50 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <20140304180437.17F75624BB@hg.openjdk.java.net> Changeset: b8a1db3d5a8b Author: Chien Yang Date: 2014-03-04 09:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b8a1db3d5a8b Fix to RT-21702: [Touch, Windows] MouseEvents generated from touch-screen action have isSynthesized() == false Reviewed by Anthony Petrov ! modules/graphics/src/main/native-glass/win/ViewContainer.cpp Changeset: c896cd34e781 Author: shemnon Date: 2014-03-04 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c896cd34e781 RT-29286: javafxpackager: -makeall option doesn't work at all Summary: source was locked to Java 5, and the passed in classpath was ignored for compilation ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/PackagerLib.java From steve.x.northover at oracle.com Tue Mar 4 10:18:33 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 04 Mar 2014 13:18:33 -0500 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <5314E961.6080602@oracle.com> References: <530E0BF1.5050302@oracle.com> <530E64C7.2080403@oracle.com> <5314E961.6080602@oracle.com> Message-ID: <531618F9.2070006@oracle.com> Hi Anthony, Please review the lambdification of the web component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please coordinate with me and I will re-lambdify to include the changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve From steve.x.northover at oracle.com Tue Mar 4 10:23:33 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 04 Mar 2014 13:23:33 -0500 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <531618F9.2070006@oracle.com> References: <530E0BF1.5050302@oracle.com> <530E64C7.2080403@oracle.com> <5314E961.6080602@oracle.com> <531618F9.2070006@oracle.com> Message-ID: <53161A25.2060901@oracle.com> Of course I mean Leonid, who is the owner of web, not Anthony ... On 2014-03-04 1:18 PM, Stephen F Northover wrote: > Hi Anthony, > > Please review the lambdification of the web component. You are welcome > to apply the patch, but there are numerous changes and they are all > automatic. If you have outstanding changes, please coordinate with me > and I will re-lambdify to include the changes. > > Jira: https://javafx-jira.kenai.com/browse/RT-35197 > Webrev: See patch is in the JIRA > > Steve From hang.vo at oracle.com Tue Mar 4 10:50:59 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Mar 2014 18:50:59 +0000 Subject: hg: openjfx/8/master/rt: Added tag 8.0-b132 for changeset e2fd0ac9762b Message-ID: <20140304185200.5EB51624BE@hg.openjdk.java.net> Changeset: f89b7dc932af Author: hudson Date: 2014-03-04 10:36 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f89b7dc932af Added tag 8.0-b132 for changeset e2fd0ac9762b ! .hgtags From jeff at reportmill.com Tue Mar 4 16:03:00 2014 From: jeff at reportmill.com (Jeff Martin) Date: Tue, 4 Mar 2014 18:03:00 -0600 Subject: CSS Font size in points doesn't match Node.Font.Size Message-ID: I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. Any suggestions on how I should be thinking about this (other than that this is a bug :-)? jeff From tom.schindl at bestsolution.at Tue Mar 4 16:10:02 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 5 Mar 2014 01:10:02 +0100 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: References: Message-ID: There was a thread some time ago on this List with explainations of this behavior! Tom Von meinem iPhone gesendet > Am 05.03.2014 um 01:03 schrieb Jeff Martin : > > I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. > > Any suggestions on how I should be thinking about this (other than that this is a bug :-)? > > jeff From jeff at reportmill.com Tue Mar 4 16:42:23 2014 From: jeff at reportmill.com (Jeff Martin) Date: Tue, 4 Mar 2014 18:42:23 -0600 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: References: Message-ID: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, and Nodes convert that to the real world on render? And that this is basically a bug, but it can't be fixed due to legacy considerations? jeff On Mar 4, 2014, at 6:10 PM, Tom Schindl wrote: > There was a thread some time ago on this List with explainations of this behavior! > > Tom > > Von meinem iPhone gesendet > >> Am 05.03.2014 um 01:03 schrieb Jeff Martin : >> >> I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. >> >> Any suggestions on how I should be thinking about this (other than that this is a bug :-)? >> >> jeff From hang.vo at oracle.com Tue Mar 4 19:18:12 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 03:18:12 +0000 Subject: hg: openjfx/8u-dev/rt: Fix RT-35058: ES2 texture lock warnings in CanvasTest/Zoomy on ARM Message-ID: <20140305031943.31554624E6@hg.openjdk.java.net> Changeset: df8841896a28 Author: flar Date: 2014-03-04 19:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/df8841896a28 Fix RT-35058: ES2 texture lock warnings in CanvasTest/Zoomy on ARM Reviewed by: Lisa ! modules/graphics/src/main/java/com/sun/scenario/effect/FilterContext.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrFilterContext.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrRenderer.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPStoPSWDisplacementMapPeer.java From hang.vo at oracle.com Wed Mar 5 01:03:50 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 09:03:50 +0000 Subject: hg: openjfx/8u-dev/rt: RT-16923: Toolkit addListener methods should ignore null listeners Message-ID: <20140305090420.B9251624F2@hg.openjdk.java.net> Changeset: b6f62f8bd8e6 Author: vadim Date: 2014-03-05 12:48 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b6f62f8bd8e6 RT-16923: Toolkit addListener methods should ignore null listeners Reviewed-by: anthony, kcr, fheidric ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java From hang.vo at oracle.com Wed Mar 5 01:18:36 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 09:18:36 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36088 [Popup] PopupWindow.show(Window): Wrong popup positioning on subsequent calls Message-ID: <20140305091857.7AAED624F3@hg.openjdk.java.net> Changeset: b9b901417181 Author: Martin Sladecek Date: 2014-03-05 10:04 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b9b901417181 RT-36088 [Popup] PopupWindow.show(Window): Wrong popup positioning on subsequent calls ! modules/graphics/src/main/java/javafx/stage/PopupWindow.java ! modules/graphics/src/test/java/javafx/stage/PopupTest.java From martin.sladecek at oracle.com Wed Mar 5 03:48:55 2014 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Wed, 05 Mar 2014 12:48:55 +0100 Subject: [8u20] API request: missing property for PieChart.Data's node Message-ID: <53170F27.6090501@oracle.com> Hi, JIRA: https://javafx-jira.kenai.com/browse/RT-36105 webrev: http://cr.openjdk.java.net/~msladecek/rt-36105/webrev.00/ there's a missing property for PieChart.Data.getNode(). Thanks, -Martin From rafi.tayar at oracle.com Wed Mar 5 07:19:16 2014 From: rafi.tayar at oracle.com (Rafi Tayar) Date: Wed, 5 Mar 2014 07:19:16 -0800 (PST) Subject: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox Message-ID: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> Hi Daniel, Lisa, Please review the patch in the Jira : https://javafx-jira.kenai.com/browse/RT-35616 Thanks, Rafi From lisa.selle at oracle.com Wed Mar 5 07:23:11 2014 From: lisa.selle at oracle.com (Lisa Selle) Date: Wed, 05 Mar 2014 10:23:11 -0500 Subject: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox In-Reply-To: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> References: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> Message-ID: <5317415F.30304@oracle.com> Can you check the bug number? This doesn't look right... I guess it should be https://javafx-jira.kenai.com/browse/RT-35619 On 3/5/2014 10:19 AM, Rafi Tayar wrote: > > Hi Daniel, Lisa, > > Please review the patch in the Jira : > > https://javafx-jira.kenai.com/browse/RT-35616 > > Thanks, > > Rafi > From rafi.tayar at oracle.com Wed Mar 5 07:25:04 2014 From: rafi.tayar at oracle.com (Rafi Tayar) Date: Wed, 5 Mar 2014 07:25:04 -0800 (PST) Subject: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox In-Reply-To: <5317415F.30304@oracle.com> References: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> <5317415F.30304@oracle.com> Message-ID: <17e0c0f0-2f2b-404f-a3a4-35fc6be96279@default> Right, it should be https://javafx-jira.kenai.com/browse/RT-35619 Thanks, Rafi From: Lisa Selle Sent: Wednesday, March 05, 2014 5:23 PM To: Rafi Tayar; Daniel Blaukopf Cc: openjfx-dev at openjdk.java.net List Subject: Re: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox Can you check the bug number? This doesn't look right... I guess it should be https://javafx-jira.kenai.com/browse/RT-35619 On 3/5/2014 10:19 AM, Rafi Tayar wrote: Hi Daniel, Lisa, Please review the patch in the Jira : https://javafx-jira.kenai.com/browse/RT-35616 Thanks, Rafi From kevin.rushforth at oracle.com Wed Mar 5 07:51:44 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 05 Mar 2014 07:51:44 -0800 Subject: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox In-Reply-To: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> References: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> Message-ID: <53174810.6000702@oracle.com> As a reminder (and not to pick on Rafi) this is the second time in as many days that an 8-update review has been sent out for a bug that is targeted for FX 9. In order to help us better track which bugs are going into which release, please set the release target as appropriate before starting to work on a bug. Thanks. -- Kevin Rafi Tayar wrote: > Hi Daniel, Lisa, > > > > Please review the patch in the Jira : > > > > https://javafx-jira.kenai.com/browse/RT-35616 > > > > Thanks, > > Rafi > > > From kevin.rushforth at oracle.com Wed Mar 5 07:56:53 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 05 Mar 2014 07:56:53 -0800 Subject: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox In-Reply-To: <53174810.6000702@oracle.com> References: <4b74b3ef-016c-4a87-b0aa-825581ef1af1@default> <53174810.6000702@oracle.com> Message-ID: <53174945.5050904@oracle.com> Oops. I didn't read Lisa's and Rafi's follow-on messages about the bug ID being wrong. Sorry about that. -- Kevin Kevin Rushforth wrote: > As a reminder (and not to pick on Rafi) this is the second time in as > many days that an 8-update review has been sent out for a bug that is > targeted for FX 9. In order to help us better track which bugs are > going into which release, please set the release target as appropriate > before starting to work on a bug. > > Thanks. > > -- Kevin > > > > Rafi Tayar wrote: >> Hi Daniel, Lisa, >> >> >> >> Please review the patch in the Jira : >> >> >> https://javafx-jira.kenai.com/browse/RT-35616 >> >> >> >> Thanks, >> >> Rafi >> >> >> From felipe.heidrich at oracle.com Wed Mar 5 08:09:40 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Wed, 5 Mar 2014 08:09:40 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: References: Message-ID: <388EEE7C-6DC6-4E66-8D70-EDBB2AE82453@oracle.com> Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: > Thanks Tom! I assume the thread was this one: > > Font.font() says it is point size but it looks like it are pixels > http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html > > I guess the final word is that CSS assumes 1pt==1/92in, Yes > and Nodes convert that to the real world on render? > On the printer yes, on the display it assumes 72 (pt=px). > And that this is basically a bug, but it can't be fixed due to legacy considerations? > Yes Felipe > > On Mar 4, 2014, at 6:10 PM, Tom Schindl wrote: > >> There was a thread some time ago on this List with explainations of this behavior! >> >> Tom >> >> Von meinem iPhone gesendet >> >>> Am 05.03.2014 um 01:03 schrieb Jeff Martin : >>> >>> I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. >>> >>> Any suggestions on how I should be thinking about this (other than that this is a bug :-)? >>> >>> jeff > From pedro.duquevieira at gmail.com Wed Mar 5 09:10:56 2014 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 5 Mar 2014 17:10:56 +0000 Subject: Poor font rendering.. Message-ID: Hi, As evidenced by the screenshots in http://pixelduke.wordpress.com/ blog posts about JMetro, javafx as noticeably poor font rendering visuals. The most recent screenshots were taken on a windows 8.1 machine and the older ones on windows 7, using Segoe UI (windows 7 & 8 system font). 1- As this been reported? 2- Is the javafx team working on it? 3- Is there something the developer can do to increase font rendering quality? Thanks! Best regards, -- Pedro Duque Vieira From steve.x.northover at oracle.com Wed Mar 5 09:30:01 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 05 Mar 2014 12:30:01 -0500 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: <53175F19.7020400@oracle.com> Hi Pedro, Font rendering in FX8 is using the native rasterizer so the glyphs should be identical to what the operating system is rendering. That said, we may have a bug. Please enter a JIRA with sample code and a screen shot of the bad rendering. That will give us something concrete to work with. Thanks, Steve On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: > Hi, > > As evidenced by the screenshots in http://pixelduke.wordpress.com/ blog > posts about JMetro, javafx as noticeably poor font rendering visuals. The > most recent screenshots were taken on a windows 8.1 machine and the older > ones on windows 7, using Segoe UI (windows 7 & 8 system font). > > 1- As this been reported? > > 2- Is the javafx team working on it? > > 3- Is there something the developer can do to increase font rendering > quality? > > Thanks! > Best regards, > > From jeff at reportmill.com Wed Mar 5 09:51:15 2014 From: jeff at reportmill.com (Jeff Martin) Date: Wed, 5 Mar 2014 11:51:15 -0600 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <388EEE7C-6DC6-4E66-8D70-EDBB2AE82453@oracle.com> References: <388EEE7C-6DC6-4E66-8D70-EDBB2AE82453@oracle.com> Message-ID: <8504D8B4-652E-4F87-8E1D-07C32F3287FC@reportmill.com> So what is the best approach to dealing with pt sizes in CSS? Do I multiply every pt size by 3/4 in CSS? Will this always result in Node Fonts that are 4/3 times the specified CSS value? I assume I can't just use px and expect Node Fonts to have the identical value, only in points, regardless of the display. Maybe Region should have a new attribute called FixCSSPoints that we could set after adding style sheets? jeff On Mar 5, 2014, at 10:09 AM, Felipe Heidrich wrote: > Hi > > On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: > >> Thanks Tom! I assume the thread was this one: >> >> Font.font() says it is point size but it looks like it are pixels >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >> >> I guess the final word is that CSS assumes 1pt==1/92in, > > Yes > >> and Nodes convert that to the real world on render? >> > > On the printer yes, on the display it assumes 72 (pt=px). > > >> And that this is basically a bug, but it can't be fixed due to legacy considerations? >> > > Yes > > Felipe > >> >> On Mar 4, 2014, at 6:10 PM, Tom Schindl wrote: >> >>> There was a thread some time ago on this List with explainations of this behavior! >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>>> Am 05.03.2014 um 01:03 schrieb Jeff Martin : >>>> >>>> I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. >>>> >>>> Any suggestions on how I should be thinking about this (other than that this is a bug :-)? >>>> >>>> jeff >> > From hang.vo at oracle.com Wed Mar 5 10:48:30 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 18:48:30 +0000 Subject: hg: openjfx/8u-dev/rt: [TEST-ONLY] change TestBase to initialize toolkit in @BeforeClass method Message-ID: <20140305185003.5575462512@hg.openjdk.java.net> Changeset: a080ea040a9c Author: kcr Date: 2014-03-05 10:36 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a080ea040a9c [TEST-ONLY] change TestBase to initialize toolkit in @BeforeClass method Summary: This change matches what we do elsewhere and avoids waiting in the static block which will deadlock whenn we change to using lambdas (see JDK-8036728) ! modules/web/src/test/java/javafx/scene/web/TestBase.java From hang.vo at oracle.com Wed Mar 5 11:33:24 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 19:33:24 +0000 Subject: hg: openjfx/8u-dev/rt: [TOYS] HelloFonts, correcting table cell handling to get rid of bogus error msg Message-ID: <20140305193352.CDE9462515@hg.openjdk.java.net> Changeset: cbb89489baea Author: ddhill Date: 2014-03-05 14:13 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cbb89489baea [TOYS] HelloFonts, correcting table cell handling to get rid of bogus error msg ! apps/toys/Hello/src/main/java/hello/HelloFonts.java From felipe.heidrich at oracle.com Wed Mar 5 12:03:20 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Wed, 5 Mar 2014 12:03:20 -0800 Subject: Poor font rendering.. In-Reply-To: <53175F19.7020400@oracle.com> References: <53175F19.7020400@oracle.com> Message-ID: 1. Maybe https://javafx-jira.kenai.com/browse/RT-35402 2. Sure. The above bug is in my TODO list as a matter of fact, 3. Things to try: a) Text#setFontSmoothingType(LCD) ? b) -Dprism.text=t2k (in the command line) c) if the font size is bigger than 80 JavaFX renders text using paths, try font size < 80 (so that glyph images are used) d) make sure the text node does not lay in a transparent cached parent, or any other type node that is internally rendered using intermediate transparent texture. See https://javafx-jira.kenai.com/browse/RT-31100 for details. e) if the node is cached (with or without background set), make sure the node is not scaled up. Question to you, does it look good on Windows 7 and bad on Windows 8 ? Please, use the jira to report results. Thank you Felipe On Mar 5, 2014, at 9:30 AM, Stephen F Northover wrote: > Hi Pedro, > > Font rendering in FX8 is using the native rasterizer so the glyphs should be identical to what the operating system is rendering. That said, we may have a bug. Please enter a JIRA with sample code and a screen shot of the bad rendering. That will give us something concrete to work with. > > Thanks, > Steve > > On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> Hi, >> >> As evidenced by the screenshots in http://pixelduke.wordpress.com/ blog >> posts about JMetro, javafx as noticeably poor font rendering visuals. The >> most recent screenshots were taken on a windows 8.1 machine and the older >> ones on windows 7, using Segoe UI (windows 7 & 8 system font). >> >> 1- As this been reported? >> >> 2- Is the javafx team working on it? >> >> 3- Is there something the developer can do to increase font rendering >> quality? >> >> Thanks! >> Best regards, >> >> > From pedro.duquevieira at gmail.com Wed Mar 5 12:39:15 2014 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 5 Mar 2014 20:39:15 +0000 Subject: CSS Font size in points doesn't match Node.Font.Size Message-ID: Hi Tom, Jeff, Felipe... Having bugs stay in to maintain backwards compatibility sounds very weird to me IMHO. If we go down that road aren't we creating a library that will some day have too many glitches and as such less appeal to programmers looking for UI libraries? Thanks, > Hi > On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: > > Thanks Tom! I assume the thread was this one: > > > > Font.font() says it is point size but it looks like it are pixels > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html > > > > I guess the final word is that CSS assumes 1pt==1/92in, > Yes > > and Nodes convert that to the real world on render? > > > On the printer yes, on the display it assumes 72 (pt=px). > > > And that this is basically a bug, but it can't be fixed due to legacy > considerations? > > > Yes > Felipe -- Pedro Duque Vieira From steve.x.northover at oracle.com Wed Mar 5 12:41:24 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 05 Mar 2014 15:41:24 -0500 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <5316FB51.3020508@oracle.com> References: <5316FB51.3020508@oracle.com> Message-ID: <53178BF4.1050205@oracle.com> Hi Kirill, Please review the lambdification of the base component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please commit them and I will lambdify once more, Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve From steve.x.northover at oracle.com Wed Mar 5 12:44:23 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 05 Mar 2014 15:44:23 -0500 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <53178BF4.1050205@oracle.com> References: <5316FB51.3020508@oracle.com> <53178BF4.1050205@oracle.com> Message-ID: <53178CA7.9050504@oracle.com> .. of course I mean the media component, not base. I just change the template to say "your component" ... Steve On 2014-03-05 3:41 PM, Stephen F Northover wrote: > Hi Kirill, > > Please review the lambdification of the base component. You are > welcome to apply the patch, but there are numerous changes and they > are all automatic. If you have outstanding changes, please commit > them and I will lambdify once more, > > Jira: https://javafx-jira.kenai.com/browse/RT-35197 > Webrev: See patch is in the JIRA > > Steve > From hang.vo at oracle.com Wed Mar 5 12:48:51 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 20:48:51 +0000 Subject: hg: openjfx/8u-dev/rt: ECLIPSE ONLY: fix .classpath Message-ID: <20140305204928.605C36252A@hg.openjdk.java.net> Changeset: dc63b991dc39 Author: snorthov Date: 2014-03-05 15:39 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dc63b991dc39 ECLIPSE ONLY: fix .classpath ! modules/media/.classpath From hang.vo at oracle.com Wed Mar 5 13:14:54 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 21:14:54 +0000 Subject: hg: openjfx/2u/dev/rt: Added tag 2.2.60-b09 for changeset 53d0f8119d8c Message-ID: <20140305211458.B73AA6252B@hg.openjdk.java.net> Changeset: 143b27648d96 Author: hudson Date: 2014-03-05 09:01 -0800 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/143b27648d96 Added tag 2.2.60-b09 for changeset 53d0f8119d8c ! .hgtags From felipe.heidrich at oracle.com Wed Mar 5 13:51:48 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Wed, 5 Mar 2014 13:51:48 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <8504D8B4-652E-4F87-8E1D-07C32F3287FC@reportmill.com> References: <388EEE7C-6DC6-4E66-8D70-EDBB2AE82453@oracle.com> <8504D8B4-652E-4F87-8E1D-07C32F3287FC@reportmill.com> Message-ID: <318AD140-FEA9-484D-A2FF-83ABF40E0CA5@oracle.com> I?m not a CSS guy, but I never seen an alternative as you suggest. I suppose there is recommend way to handle this problem. Looking at modena.css it always uses ?em? to define font size (instead of pt or px). Wouldn?t that work for you ? Felipe On Mar 5, 2014, at 9:51 AM, Jeff Martin wrote: > So what is the best approach to dealing with pt sizes in CSS? Do I multiply every pt size by 3/4 in CSS? Will this always result in Node Fonts that are 4/3 times the specified CSS value? > > I assume I can't just use px and expect Node Fonts to have the identical value, only in points, regardless of the display. > > Maybe Region should have a new attribute called FixCSSPoints that we could set after adding style sheets? > > jeff > > > On Mar 5, 2014, at 10:09 AM, Felipe Heidrich wrote: > >> Hi >> >> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >> >>> Thanks Tom! I assume the thread was this one: >>> >>> Font.font() says it is point size but it looks like it are pixels >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>> >>> I guess the final word is that CSS assumes 1pt==1/92in, >> >> Yes >> >>> and Nodes convert that to the real world on render? >>> >> >> On the printer yes, on the display it assumes 72 (pt=px). >> >> >>> And that this is basically a bug, but it can't be fixed due to legacy considerations? >>> >> >> Yes >> >> Felipe >> >>> >>> On Mar 4, 2014, at 6:10 PM, Tom Schindl wrote: >>> >>>> There was a thread some time ago on this List with explainations of this behavior! >>>> >>>> Tom >>>> >>>> Von meinem iPhone gesendet >>>> >>>>> Am 05.03.2014 um 01:03 schrieb Jeff Martin : >>>>> >>>>> I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. >>>>> >>>>> Any suggestions on how I should be thinking about this (other than that this is a bug :-)? >>>>> >>>>> jeff >>> >> > From felipe.heidrich at oracle.com Wed Mar 5 14:03:21 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Wed, 5 Mar 2014 14:03:21 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: References: Message-ID: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> The problem is that point size used by Node and point size used by CSS are not the same. One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. I don?t see how to change one or the other without breaking a ton of people. Maybe adding a global font DPI so that Node can be made to match CSS ? Suggestions ? Felipe On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira wrote: > Hi Tom, Jeff, Felipe... > > Having bugs stay in to maintain backwards compatibility sounds very weird > to me IMHO. > > If we go down that road aren't we creating a library that will some day > have too many glitches and as such less appeal to programmers looking for > UI libraries? > > Thanks, > > >> Hi >> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >>> Thanks Tom! I assume the thread was this one: >>> >>> Font.font() says it is point size but it looks like it are pixels >>> >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>> >>> I guess the final word is that CSS assumes 1pt==1/92in, >> Yes >>> and Nodes convert that to the real world on render? >>> >> On the printer yes, on the display it assumes 72 (pt=px). >> >>> And that this is basically a bug, but it can't be fixed due to legacy >> considerations? >>> >> Yes >> Felipe > > > -- > Pedro Duque Vieira From jeff at reportmill.com Wed Mar 5 14:15:53 2014 From: jeff at reportmill.com (Jeff Martin) Date: Wed, 5 Mar 2014 16:15:53 -0600 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> References: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> Message-ID: <571F7FC9-342C-4EE1-BFAE-9AF6B4E2E02B@reportmill.com> The thing is, point size is a fixed size - 1pt==1/72 in, regardless of the DPI. It is simply incorrect and confusing, arbitrarily deciding that a point is 1/96in. How about implementing the fix based on a global static variable somewhere? And perhaps printing a warning to the console when the first CSS is applied if that global hasn't been set saying, "CSS point-size fix not activated - this will be set by default in a future release". jeff On Mar 5, 2014, at 4:03 PM, Felipe Heidrich wrote: > > The problem is that point size used by Node and point size used by CSS are not the same. > One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. > > I don?t see how to change one or the other without breaking a ton of people. > > Maybe adding a global font DPI so that Node can be made to match CSS ? > > Suggestions ? > > Felipe > > On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira wrote: > >> Hi Tom, Jeff, Felipe... >> >> Having bugs stay in to maintain backwards compatibility sounds very weird >> to me IMHO. >> >> If we go down that road aren't we creating a library that will some day >> have too many glitches and as such less appeal to programmers looking for >> UI libraries? >> >> Thanks, >> >> >>> Hi >>> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >>>> Thanks Tom! I assume the thread was this one: >>>> >>>> Font.font() says it is point size but it looks like it are pixels >>>> >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>>> >>>> I guess the final word is that CSS assumes 1pt==1/92in, >>> Yes >>>> and Nodes convert that to the real world on render? >>>> >>> On the printer yes, on the display it assumes 72 (pt=px). >>> >>>> And that this is basically a bug, but it can't be fixed due to legacy >>> considerations? >>>> >>> Yes >>> Felipe >> >> >> -- >> Pedro Duque Vieira > From jeff at reportmill.com Wed Mar 5 14:18:55 2014 From: jeff at reportmill.com (Jeff Martin) Date: Wed, 5 Mar 2014 16:18:55 -0600 Subject: Drag and Drop Doesn't work in JFXPanel on MacOSX Message-ID: <9CB68E25-9F21-4304-B06A-B466B9DF7F94@reportmill.com> Has anyone else noticed that Drag and Drop doesn't work with JFXPanel on MacOSX (unless I'm doing something stupid)? I filed a bug: https://javafx-jira.kenai.com/browse/RT-36127 There is a very simple test case in the comment. jeff From tom.schindl at bestsolution.at Wed Mar 5 14:19:02 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 5 Mar 2014 23:19:02 +0100 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> References: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> Message-ID: <7E64CB9A-08DA-4305-872B-547AD253FBB3@bestsolution.at> From my tests the font size generated by CSS is what one gets with the same point size and font using native apps and Qt - my complaint was the font size when using the Java API. Tom Von meinem iPhone gesendet > Am 05.03.2014 um 23:03 schrieb Felipe Heidrich : > > > The problem is that point size used by Node and point size used by CSS are not the same. > One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. > > I don?t see how to change one or the other without breaking a ton of people. > > Maybe adding a global font DPI so that Node can be made to match CSS ? > > Suggestions ? > > Felipe > >> On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira wrote: >> >> Hi Tom, Jeff, Felipe... >> >> Having bugs stay in to maintain backwards compatibility sounds very weird >> to me IMHO. >> >> If we go down that road aren't we creating a library that will some day >> have too many glitches and as such less appeal to programmers looking for >> UI libraries? >> >> Thanks, >> >> >>> Hi >>>> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >>>> Thanks Tom! I assume the thread was this one: >>>> >>>> Font.font() says it is point size but it looks like it are pixels >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>>> >>>> I guess the final word is that CSS assumes 1pt==1/92in, >>> Yes >>>> and Nodes convert that to the real world on render? >>> On the printer yes, on the display it assumes 72 (pt=px). >>> >>>> And that this is basically a bug, but it can't be fixed due to legacy >>> considerations? >>> Yes >>> Felipe >> >> >> -- >> Pedro Duque Vieira > From David.Hill at Oracle.com Wed Mar 5 14:29:59 2014 From: David.Hill at Oracle.com (David Hill) Date: Wed, 05 Mar 2014 17:29:59 -0500 Subject: Review for font fallback change RT-35978 Message-ID: <5317A567.2090808@Oracle.com> jira: https://javafx-jira.kenai.com/browse/RT-35978 webrev: http://cr.openjdk.java.net/~ddhill/RT-35978 The change is for Embedded Arm font fallback, simplifying the determination of where the jre/lib/fonts will be found. I switched to using the java.home property as it provides the desired information with greater simplicity and accuracy than the previous mechanism. I also would appreciate an associated Wiki rework for this topic: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup -- David Hill Java Embedded Development "If you want to catch something, running after it isn't always the best way." -- Lois McMaster Bujold, "Borders of Infinity", 1989 From kevin.rushforth at oracle.com Wed Mar 5 14:31:23 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 05 Mar 2014 14:31:23 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <571F7FC9-342C-4EE1-BFAE-9AF6B4E2E02B@reportmill.com> References: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> <571F7FC9-342C-4EE1-BFAE-9AF6B4E2E02B@reportmill.com> Message-ID: <5317A5BB.2070005@oracle.com> I don't think we can do what you suggest about the warning, since there are cases where CSS could be initialized prior to calling into the application (e.g., the default preloader, deploy dialogs), but I think it might make sense to add a property to control the scale. Can you file a JIRA request for adding such a property? I think we can argue separately whether it should be the default at some point, but I am not in favor of that. This would be too big of a breaking change. -- Kevin Jeff Martin wrote: > The thing is, point size is a fixed size - 1pt==1/72 in, regardless of the DPI. It is simply incorrect and confusing, arbitrarily deciding that a point is 1/96in. > > How about implementing the fix based on a global static variable somewhere? And perhaps printing a warning to the console when the first CSS is applied if that global hasn't been set saying, "CSS point-size fix not activated - this will be set by default in a future release". > > jeff > > > On Mar 5, 2014, at 4:03 PM, Felipe Heidrich wrote: > > >> The problem is that point size used by Node and point size used by CSS are not the same. >> One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. >> >> I don?t see how to change one or the other without breaking a ton of people. >> >> Maybe adding a global font DPI so that Node can be made to match CSS ? >> >> Suggestions ? >> >> Felipe >> >> On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira wrote: >> >> >>> Hi Tom, Jeff, Felipe... >>> >>> Having bugs stay in to maintain backwards compatibility sounds very weird >>> to me IMHO. >>> >>> If we go down that road aren't we creating a library that will some day >>> have too many glitches and as such less appeal to programmers looking for >>> UI libraries? >>> >>> Thanks, >>> >>> >>> >>>> Hi >>>> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >>>> >>>>> Thanks Tom! I assume the thread was this one: >>>>> >>>>> Font.font() says it is point size but it looks like it are pixels >>>>> >>>>> >>>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>>> >>>>> I guess the final word is that CSS assumes 1pt==1/92in, >>>>> >>>> Yes >>>> >>>>> and Nodes convert that to the real world on render? >>>>> >>>>> >>>> On the printer yes, on the display it assumes 72 (pt=px). >>>> >>>> >>>>> And that this is basically a bug, but it can't be fixed due to legacy >>>>> >>>> considerations? >>>> >>>> Yes >>>> Felipe >>>> >>> -- >>> Pedro Duque Vieira >>> > > From david.grieve at oracle.com Wed Mar 5 14:37:34 2014 From: david.grieve at oracle.com (David Grieve) Date: Wed, 05 Mar 2014 17:37:34 -0500 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> References: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> Message-ID: <5317A72E.6010905@oracle.com> To set the record straight, everything in JavaFX is pixels, including Font size. The W3C CSS spec (http://www.w3.org/TR/css3-values/#absolute-lengths) defines 1px to be 1/96th of 1in and 1pt to be 1/72 of 1in. Therefore, one px is 3/4ths of a pt (1px = 0.75pt) and this is the conversion factor that JavaFX uses to convert CSS points to pixels. That said, the W3C recommends against using pt, cm, mm, in and pc as value units for screen media. Instead, you should use em, px or %. See http://www.w3.org/Style/Examples/007/units.en.html for more details. On 3/5/14, 5:03 PM, Felipe Heidrich wrote: > The problem is that point size used by Node and point size used by CSS are not the same. > One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. > > I don?t see how to change one or the other without breaking a ton of people. > > Maybe adding a global font DPI so that Node can be made to match CSS ? > > Suggestions ? > > Felipe > > On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira wrote: > >> Hi Tom, Jeff, Felipe... >> >> Having bugs stay in to maintain backwards compatibility sounds very weird >> to me IMHO. >> >> If we go down that road aren't we creating a library that will some day >> have too many glitches and as such less appeal to programmers looking for >> UI libraries? >> >> Thanks, >> >> >>> Hi >>> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >>>> Thanks Tom! I assume the thread was this one: >>>> >>>> Font.font() says it is point size but it looks like it are pixels >>>> >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>>> I guess the final word is that CSS assumes 1pt==1/92in, >>> Yes >>>> and Nodes convert that to the real world on render? >>>> >>> On the printer yes, on the display it assumes 72 (pt=px). >>> >>>> And that this is basically a bug, but it can't be fixed due to legacy >>> considerations? >>> Yes >>> Felipe >> >> -- >> Pedro Duque Vieira From steve.x.northover at oracle.com Wed Mar 5 14:45:14 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 05 Mar 2014 17:45:14 -0500 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <7E64CB9A-08DA-4305-872B-547AD253FBB3@bestsolution.at> References: <26F629CA-3478-440B-A4F2-2A9D8AC5E185@oracle.com> <7E64CB9A-08DA-4305-872B-547AD253FBB3@bestsolution.at> Message-ID: <5317A8FA.6090006@oracle.com> Hi all, To change the Java API now would break the universe. All you can do is add new API. This can be in the form of new methods on Font, however things like Font.getSize() must always return pixels. A new method can be added getPoints() and new constructors that take points added, or perhaps a boolean parameter that says the the double parameter is in points, not pixels. A global mode would be horrible and error prone (unless I am missing something). Steve On 2014-03-05 5:19 PM, Tom Schindl wrote: > From my tests the font size generated by CSS is what one gets with the same point size and font using native apps and Qt - my complaint was the font size when using the Java API. > > Tom > > Von meinem iPhone gesendet > >> Am 05.03.2014 um 23:03 schrieb Felipe Heidrich : >> >> >> The problem is that point size used by Node and point size used by CSS are not the same. >> One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. >> >> I don?t see how to change one or the other without breaking a ton of people. >> >> Maybe adding a global font DPI so that Node can be made to match CSS ? >> >> Suggestions ? >> >> Felipe >> >>> On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira wrote: >>> >>> Hi Tom, Jeff, Felipe... >>> >>> Having bugs stay in to maintain backwards compatibility sounds very weird >>> to me IMHO. >>> >>> If we go down that road aren't we creating a library that will some day >>> have too many glitches and as such less appeal to programmers looking for >>> UI libraries? >>> >>> Thanks, >>> >>> >>>> Hi >>>>> On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote: >>>>> Thanks Tom! I assume the thread was this one: >>>>> >>>>> Font.font() says it is point size but it looks like it are pixels >>>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html >>>>> I guess the final word is that CSS assumes 1pt==1/92in, >>>> Yes >>>>> and Nodes convert that to the real world on render? >>>> On the printer yes, on the display it assumes 72 (pt=px). >>>> >>>>> And that this is basically a bug, but it can't be fixed due to legacy >>>> considerations? >>>> Yes >>>> Felipe >>> >>> -- >>> Pedro Duque Vieira From pedro.duquevieira at gmail.com Wed Mar 5 14:49:56 2014 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 5 Mar 2014 22:49:56 +0000 Subject: CSS Font size in points doesn't match Node.Font.Size Message-ID: Here is the definition of point: http://www.w3schools.com/cssref/css_units.asp As Jeff is saying it should be 1/72 inch. I think this should be the default. Isn't the introduction of modena potentially going to break more apps than changing the definition of point? Aren't breaking apps making use of a bug that they shouldn't be taking advantage of in the first place? That being said, and if changing the default point definition is not really possible, being able to change this through a global settings property so that node matches CSS, sound like a reasonable workaround. Thanks! -- Pedro Duque Vieira From david.grieve at oracle.com Wed Mar 5 14:59:00 2014 From: david.grieve at oracle.com (David Grieve) Date: Wed, 05 Mar 2014 17:59:00 -0500 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: References: Message-ID: <5317AC34.3060706@oracle.com> Everyone should just accept that there is no such thing as a 'point' in JavaFX. Work in pixels and you will achieve nirvana. On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote: > Here is the definition of point: > http://www.w3schools.com/cssref/css_units.asp > > As Jeff is saying it should be 1/72 inch. > > I think this should be the default. Isn't the introduction of modena > potentially going to break more apps than changing the definition of point? > Aren't breaking apps making use of a bug that they shouldn't be taking > advantage of in the first place? > > That being said, and if changing the default point definition is not really > possible, being able to change this through a global settings property so > that node matches CSS, sound like a reasonable workaround. > > Thanks! > > From tom.schindl at bestsolution.at Wed Mar 5 15:18:57 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Mar 2014 00:18:57 +0100 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <5317AC34.3060706@oracle.com> References: <5317AC34.3060706@oracle.com> Message-ID: <5317B0E1.3080203@bestsolution.at> The question the is why fairly all other toolkits use point in their APIs. Some examples: * Qt: http://qt-project.org/doc/qt-5/qfont.html#QFont-2 * Cocoa: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/clm/NSFont/fontWithName:size: * Pango: https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-set-size * AWT: http://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#Font%28java.lang.String,%20int,%20int%29 * SWT: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fgraphics%2FFont.html Why can't JavaFX not at least provide a font-API to create fonts with point? Tom On 05.03.14 23:59, David Grieve wrote: > Everyone should just accept that there is no such thing as a 'point' in > JavaFX. Work in pixels and you will achieve nirvana. > > On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote: >> Here is the definition of point: >> http://www.w3schools.com/cssref/css_units.asp >> >> As Jeff is saying it should be 1/72 inch. >> >> I think this should be the default. Isn't the introduction of modena >> potentially going to break more apps than changing the definition of >> point? >> Aren't breaking apps making use of a bug that they shouldn't be taking >> advantage of in the first place? >> >> That being said, and if changing the default point definition is not >> really >> possible, being able to change this through a global settings property so >> that node matches CSS, sound like a reasonable workaround. >> >> Thanks! >> >> > From hang.vo at oracle.com Wed Mar 5 15:33:40 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Mar 2014 23:33:40 +0000 Subject: hg: openjfx/8u-dev/rt: RT-34099: ColorPicker needs localization support Message-ID: <20140305233428.B4A8762530@hg.openjdk.java.net> Changeset: e605558a26a6 Author: leifs Date: 2014-03-05 15:28 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e605558a26a6 RT-34099: ColorPicker needs localization support ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPalette.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/resources/controls.properties From pedro.duquevieira at gmail.com Wed Mar 5 17:39:17 2014 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 6 Mar 2014 01:39:17 +0000 Subject: Poor font rendering.. Message-ID: 1. It doesn't appear to be related with that issue but than again, it might.. 3. Thank you very much! I'll try out those settings to see how it looks. I'm not very familinar with the internals of how windows renders fonts but IMHO I would think that such poor results should be possible to avoid even with default settings. c) When you say 80, you mean 80px right? Even at 42px the results are quite poor. d) That's not the case, but I'll double check, just in case. e) That's not the case. To answer your question: no, it looks bad both in windows 7 and windows 8 (8.1). Before submitting the bug I think it's better for me to double check if it's not my computer's fault that the results are so poor because as I said I don't know much about the font rendering internals of windows, but as my computer has a 1900x1200 display (slightly superior than full hd) I would expect much better results using the system font (Segoe UI). Like I said even at 42px, using the system font, the results are very poor (you can attest to that by looking at the screenshots in my blog - pixelduke). Thanks again, regards, > 1. > Maybe https://javafx-jira.kenai.com/browse/RT-35402 > 2. > Sure. The above bug is in my TODO list as a matter of fact, > 3. Things to try: > a) Text#setFontSmoothingType(LCD) ? > b) -Dprism.text=t2k (in the command line) > c) if the font size is bigger than 80 JavaFX renders text using paths, > try font size < 80 (so that glyph images are used) > d) make sure the text node does not lay in a transparent cached parent, or > any other type node that is internally rendered using intermediate > transparent texture. See https://javafx-jira.kenai.com/browse/RT-31100 for > details. > e) if the node is cached (with or without background set), make sure the > node is not scaled up. > Question to you, does it look good on Windows 7 and bad on Windows 8 ? > Please, use the jira to report results. > Thank you > Felipe -- Pedro Duque Vieira From hang.vo at oracle.com Wed Mar 5 23:18:36 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 07:18:36 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36100 [Layout] Ensemble8 ChoiceBox control starts out at smaller size Message-ID: <20140306071922.4AE836253F@hg.openjdk.java.net> Changeset: 964e022be8dc Author: Martin Sladecek Date: 2014-03-06 08:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/964e022be8dc RT-36100 [Layout] Ensemble8 ChoiceBox control starts out at smaller size Reviewed by: dgrieve ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java From hang.vo at oracle.com Thu Mar 6 00:18:25 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 08:18:25 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36105 [Charts] PieChart.Data NodeProperty Message-ID: <20140306081901.0369F62541@hg.openjdk.java.net> Changeset: 8cc4b8c100f7 Author: Martin Sladecek Date: 2014-03-06 09:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8cc4b8c100f7 RT-36105 [Charts] PieChart.Data NodeProperty Reviewed by: kcr, snorthov ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java ! modules/controls/src/test/java/javafx/scene/chart/PieChartTest.java From hang.vo at oracle.com Thu Mar 6 00:48:20 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 08:48:20 +0000 Subject: hg: openjfx/8u-dev/rt: [DOC] Improve fxml documentation about class instances. Message-ID: <20140306084841.0417C62547@hg.openjdk.java.net> Changeset: a92f0e3fb4d1 Author: Martin Sladecek Date: 2014-03-06 09:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a92f0e3fb4d1 [DOC] Improve fxml documentation about class instances. ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html From rfisher at tesis.de Thu Mar 6 01:21:09 2014 From: rfisher at tesis.de (Robert Fisher) Date: Thu, 6 Mar 2014 10:21:09 +0100 Subject: Poor font rendering.. Message-ID: Hi all, I think there is still room for improvement in terms of the 'contrast' or 'vibrancy' of fonts in JavaFX. Take a look at this example: http://i.imgur.com/6qSamTO.png I'm running Windows 7. What you are seeing is a screenshot of the default font, zoomed in 600%. The top text is JavaFX 8 (latest build as of 3 days ago). The bottom text is Outlook but could just as easily have been Firefox, Chrome, Word, or Eclipse SWT - they're all indistinguishable to me. The JavaFX text doesn't look as vibrant. In particular the smoothing algorithm seems to be making poor colour choices for the vertical strokes. At 100% the difference is subtle but important. I have the text fill set to Color.BLACK and the font smoothing type set to LCD. Is there something else I can configure to get more vibrant-looking fonts? Cheers! Rob -----Urspr?ngliche Nachricht----- Von: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] Im Auftrag von Stephen F Northover Gesendet: Mittwoch, 5. M?rz 2014 18:30 An: Pedro Duque Vieira; OpenJFX Mailing List Betreff: Re: Poor font rendering.. Hi Pedro, Font rendering in FX8 is using the native rasterizer so the glyphs should be identical to what the operating system is rendering. That said, we may have a bug. Please enter a JIRA with sample code and a screen shot of the bad rendering. That will give us something concrete to work with. Thanks, Steve On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: > Hi, > > As evidenced by the screenshots in http://pixelduke.wordpress.com/ > blog posts about JMetro, javafx as noticeably poor font rendering > visuals. The most recent screenshots were taken on a windows 8.1 > machine and the older ones on windows 7, using Segoe UI (windows 7 & 8 system font). > > 1- As this been reported? > > 2- Is the javafx team working on it? > > 3- Is there something the developer can do to increase font rendering > quality? > > Thanks! > Best regards, > > From kirill.kirichenko at oracle.com Thu Mar 6 01:49:38 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Thu, 06 Mar 2014 13:49:38 +0400 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <53178CA7.9050504@oracle.com> References: <5316FB51.3020508@oracle.com> <53178BF4.1050205@oracle.com> <53178CA7.9050504@oracle.com> Message-ID: <531844B2.8090700@oracle.com> I couldn't find media part in Jira. On 06.03.2014 00:44, Stephen F Northover wrote: > ... of course I mean the media component, not base. I just change the > template to say "your component" ... > > Steve > > On 2014-03-05 3:41 PM, Stephen F Northover wrote: >> Hi Kirill, >> >> Please review the lambdification of the base component. You are >> welcome to apply the patch, but there are numerous changes and they >> are all automatic. If you have outstanding changes, please commit >> them and I will lambdify once more, >> >> Jira: https://javafx-jira.kenai.com/browse/RT-35197 >> Webrev: See patch is in the JIRA >> >> Steve >> > From mikegps1 at gmail.com Thu Mar 6 01:53:41 2014 From: mikegps1 at gmail.com (Mike) Date: Thu, 6 Mar 2014 01:53:41 -0800 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <531844B2.8090700@oracle.com> References: <5316FB51.3020508@oracle.com> <53178BF4.1050205@oracle.com> <53178CA7.9050504@oracle.com> <531844B2.8090700@oracle.com> Message-ID: Follow this thread and open javafx Sent from my iPhone > On Mar 6, 2014, at 1:49 AM, Kirill Kirichenko wrote: > > I couldn't find media part in Jira. > >> On 06.03.2014 00:44, Stephen F Northover wrote: >> ... of course I mean the media component, not base. I just change the >> template to say "your component" ... >> >> Steve >> >>> On 2014-03-05 3:41 PM, Stephen F Northover wrote: >>> Hi Kirill, >>> >>> Please review the lambdification of the base component. You are >>> welcome to apply the patch, but there are numerous changes and they >>> are all automatic. If you have outstanding changes, please commit >>> them and I will lambdify once more, >>> >>> Jira: https://javafx-jira.kenai.com/browse/RT-35197 >>> Webrev: See patch is in the JIRA >>> >>> Steve >> From anthony.petrov at oracle.com Thu Mar 6 02:12:27 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 06 Mar 2014 14:12:27 +0400 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <531844B2.8090700@oracle.com> References: <5316FB51.3020508@oracle.com> <53178BF4.1050205@oracle.com> <53178CA7.9050504@oracle.com> <531844B2.8090700@oracle.com> Message-ID: <53184A0B.7060706@oracle.com> I believe the base-lambda.patch in JIRA is what you're looking for. -- best regards, Anthony On 3/6/2014 1:49 PM, Kirill Kirichenko wrote: > I couldn't find media part in Jira. > > On 06.03.2014 00:44, Stephen F Northover wrote: >> ... of course I mean the media component, not base. I just change the >> template to say "your component" ... >> >> Steve >> >> On 2014-03-05 3:41 PM, Stephen F Northover wrote: >>> Hi Kirill, >>> >>> Please review the lambdification of the base component. You are >>> welcome to apply the patch, but there are numerous changes and they >>> are all automatic. If you have outstanding changes, please commit >>> them and I will lambdify once more, >>> >>> Jira: https://javafx-jira.kenai.com/browse/RT-35197 >>> Webrev: See patch is in the JIRA >>> >>> Steve >>> >> From anthony.petrov at oracle.com Thu Mar 6 03:04:22 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 06 Mar 2014 15:04:22 +0400 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <53184A0B.7060706@oracle.com> References: <5316FB51.3020508@oracle.com> <53178BF4.1050205@oracle.com> <53178CA7.9050504@oracle.com> <531844B2.8090700@oracle.com> <53184A0B.7060706@oracle.com> Message-ID: <53185636.9070805@oracle.com> No, it's not. Sorry. I guess Steve hasn't attached it to the JIRA. -- best regards, Anthony On 3/6/2014 2:12 PM, Anthony Petrov wrote: > I believe the base-lambda.patch in JIRA is what you're looking for. > > -- > best regards, > Anthony > > On 3/6/2014 1:49 PM, Kirill Kirichenko wrote: >> I couldn't find media part in Jira. >> >> On 06.03.2014 00:44, Stephen F Northover wrote: >>> ... of course I mean the media component, not base. I just change the >>> template to say "your component" ... >>> >>> Steve >>> >>> On 2014-03-05 3:41 PM, Stephen F Northover wrote: >>>> Hi Kirill, >>>> >>>> Please review the lambdification of the base component. You are >>>> welcome to apply the patch, but there are numerous changes and they >>>> are all automatic. If you have outstanding changes, please commit >>>> them and I will lambdify once more, >>>> >>>> Jira: https://javafx-jira.kenai.com/browse/RT-35197 >>>> Webrev: See patch is in the JIRA >>>> >>>> Steve >>>> >>> From swpalmer at gmail.com Thu Mar 6 07:01:30 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 6 Mar 2014 10:01:30 -0500 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: This looks to me like a sub-pixel horizontal alignment issue. Perhaps it is just a difference in kerning or something along those lines? Scott On Thu, Mar 6, 2014 at 4:21 AM, Robert Fisher wrote: > Hi all, > > I think there is still room for improvement in terms of the 'contrast' or > 'vibrancy' of fonts in JavaFX. Take a look at this example: > > http://i.imgur.com/6qSamTO.png > > I'm running Windows 7. What you are seeing is a screenshot of the default > font, zoomed in 600%. The top text is JavaFX 8 (latest build as of 3 days > ago). The bottom text is Outlook but could just as easily have been > Firefox, Chrome, Word, or Eclipse SWT - they're all indistinguishable to me. > > The JavaFX text doesn't look as vibrant. In particular the smoothing > algorithm seems to be making poor colour choices for the vertical strokes. > At 100% the difference is subtle but important. > > I have the text fill set to Color.BLACK and the font smoothing type set to > LCD. Is there something else I can configure to get more vibrant-looking > fonts? > > Cheers! > Rob > > > -----Urspr?ngliche Nachricht----- > Von: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] Im Auftrag von Stephen F Northover > Gesendet: Mittwoch, 5. M?rz 2014 18:30 > An: Pedro Duque Vieira; OpenJFX Mailing List > Betreff: Re: Poor font rendering.. > > Hi Pedro, > > Font rendering in FX8 is using the native rasterizer so the glyphs should > be identical to what the operating system is rendering. That said, we may > have a bug. Please enter a JIRA with sample code and a screen shot of the > bad rendering. That will give us something concrete to work with. > > Thanks, > Steve > > On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: > > Hi, > > > > As evidenced by the screenshots in http://pixelduke.wordpress.com/ > > blog posts about JMetro, javafx as noticeably poor font rendering > > visuals. The most recent screenshots were taken on a windows 8.1 > > machine and the older ones on windows 7, using Segoe UI (windows 7 & 8 > system font). > > > > 1- As this been reported? > > > > 2- Is the javafx team working on it? > > > > 3- Is there something the developer can do to increase font rendering > > quality? > > > > Thanks! > > Best regards, > > > > > > > From david.grieve at oracle.com Thu Mar 6 08:20:58 2014 From: david.grieve at oracle.com (David Grieve) Date: Thu, 06 Mar 2014 11:20:58 -0500 Subject: [8u] Review request: RT-37033, CSS warnings (related to MenuItem) Message-ID: <5318A06A.5070702@oracle.com> Hi Martin, Please review Webrev: http://cr.openjdk.java.net/~dgrieve/RT-33073/webrev.00/ JIRA: https://javafx-jira.kenai.com/browse/RT-33073 Details are in JIRA. Please note that the webrev has diffs for cssref.html that are not related to this change but are there because of a changeset I haven't pushed yet. Thanks, -David From hang.vo at oracle.com Thu Mar 6 08:18:23 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 16:18:23 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35778: Packager should use closed source version of deployment toolkit Message-ID: <20140306162103.3BC7D6257D@hg.openjdk.java.net> Changeset: b95448553180 Author: Danno Ferrin (shemnon) Date: 2014-03-06 09:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b95448553180 RT-35778: Packager should use closed source version of deployment toolkit Summary: turn off includeDT since the soruce no longer lives in the rt depot Reviewed-By: kcr ! apps/experiments/ConferenceScheduleApp/nbproject/project.properties From felipe.heidrich at oracle.com Thu Mar 6 08:25:26 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Thu, 6 Mar 2014 08:25:26 -0800 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: Thank you Pedro, Please report all the information to the bug system (file a new report if needed). Assign it to me. Regards Felipe On Mar 5, 2014, at 5:39 PM, Pedro Duque Vieira wrote: > 1. It doesn't appear to be related with that issue but than again, it might.. > > 3. Thank you very much! I'll try out those settings to see how it looks. I'm not very familinar with the internals of how windows renders fonts but IMHO I would think that such poor results should be possible to avoid even with default settings. > c) When you say 80, you mean 80px right? Even at 42px the results are quite poor. > d) That's not the case, but I'll double check, just in case. > e) That's not the case. > > To answer your question: no, it looks bad both in windows 7 and windows 8 (8.1). > > Before submitting the bug I think it's better for me to double check if it's not my computer's fault that the results are so poor because as I said I don't know much about the font rendering internals of windows, but as my computer has a 1900x1200 display (slightly superior than full hd) I would expect much better results using the system font (Segoe UI). Like I said even at 42px, using the system font, the results are very poor (you can attest to that by looking at the screenshots in my blog - pixelduke). > > Thanks again, regards, > > 1. > Maybe https://javafx-jira.kenai.com/browse/RT-35402 > 2. > Sure. The above bug is in my TODO list as a matter of fact, > 3. Things to try: > a) Text#setFontSmoothingType(LCD) ? > b) -Dprism.text=t2k (in the command line) > c) if the font size is bigger than 80 JavaFX renders text using paths, try font size < 80 (so that glyph images are used) > d) make sure the text node does not lay in a transparent cached parent, or any other type node that is internally rendered using intermediate transparent texture. See https://javafx-jira.kenai.com/browse/RT-31100 for details. > e) if the node is cached (with or without background set), make sure the node is not scaled up. > Question to you, does it look good on Windows 7 and bad on Windows 8 ? > Please, use the jira to report results. > Thank you > Felipe > > -- > Pedro Duque Vieira From steve.x.northover at oracle.com Thu Mar 6 08:45:19 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Thu, 06 Mar 2014 11:45:19 -0500 Subject: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples In-Reply-To: <53185636.9070805@oracle.com> References: <5316FB51.3020508@oracle.com> <53178BF4.1050205@oracle.com> <53178CA7.9050504@oracle.com> <531844B2.8090700@oracle.com> <53184A0B.7060706@oracle.com> <53185636.9070805@oracle.com> Message-ID: <5318A61F.6020704@oracle.com> Sorry everyone. The patch is there now. Steve On 2014-03-06 6:04 AM, Anthony Petrov wrote: > No, it's not. Sorry. > > I guess Steve hasn't attached it to the JIRA. > > -- > best regards, > Anthony > > On 3/6/2014 2:12 PM, Anthony Petrov wrote: >> I believe the base-lambda.patch in JIRA is what you're looking for. >> >> -- >> best regards, >> Anthony >> >> On 3/6/2014 1:49 PM, Kirill Kirichenko wrote: >>> I couldn't find media part in Jira. >>> >>> On 06.03.2014 00:44, Stephen F Northover wrote: >>>> ... of course I mean the media component, not base. I just change the >>>> template to say "your component" ... >>>> >>>> Steve >>>> >>>> On 2014-03-05 3:41 PM, Stephen F Northover wrote: >>>>> Hi Kirill, >>>>> >>>>> Please review the lambdification of the base component. You are >>>>> welcome to apply the patch, but there are numerous changes and they >>>>> are all automatic. If you have outstanding changes, please commit >>>>> them and I will lambdify once more, >>>>> >>>>> Jira: https://javafx-jira.kenai.com/browse/RT-35197 >>>>> Webrev: See patch is in the JIRA >>>>> >>>>> Steve >>>>> >>>> From steve.x.northover at oracle.com Thu Mar 6 08:53:42 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Thu, 06 Mar 2014 11:53:42 -0500 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <5317B0E1.3080203@bestsolution.at> References: <5317AC34.3060706@oracle.com> <5317B0E1.3080203@bestsolution.at> Message-ID: <5318A816.4050708@oracle.com> It can and should. See my previous post. If there is no JIRA for this, then please create one. Thanks, Steve On 2014-03-05 6:18 PM, Tom Schindl wrote: > The question the is why fairly all other toolkits use point in their APIs. > > Some examples: > * Qt: http://qt-project.org/doc/qt-5/qfont.html#QFont-2 > * Cocoa: > https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/clm/NSFont/fontWithName:size: > * Pango: > https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-set-size > * AWT: > http://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#Font%28java.lang.String,%20int,%20int%29 > * SWT: > http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fgraphics%2FFont.html > > Why can't JavaFX not at least provide a font-API to create fonts with point? > > Tom > > > On 05.03.14 23:59, David Grieve wrote: >> Everyone should just accept that there is no such thing as a 'point' in >> JavaFX. Work in pixels and you will achieve nirvana. >> >> On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote: >>> Here is the definition of point: >>> http://www.w3schools.com/cssref/css_units.asp >>> >>> As Jeff is saying it should be 1/72 inch. >>> >>> I think this should be the default. Isn't the introduction of modena >>> potentially going to break more apps than changing the definition of >>> point? >>> Aren't breaking apps making use of a bug that they shouldn't be taking >>> advantage of in the first place? >>> >>> That being said, and if changing the default point definition is not >>> really >>> possible, being able to change this through a global settings property so >>> that node matches CSS, sound like a reasonable workaround. >>> >>> Thanks! >>> >>> From philip.race at oracle.com Thu Mar 6 10:19:48 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Mar 2014 10:19:48 -0800 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: <5318BC44.5030205@oracle.com> Perhaps the gamma adjustment is different ? FX should pick this up from the SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. I don't know what Outlook (*) uses if its a WPF app then maybe its picking up an over-ridden setting for this from the registry : http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level You should be able to check that out fairly easily,and you can use this JDK app to see what the SystemParameterInfo setting is. import java.awt.*; import java.util.*; public class GetGamma { public static void main(String args[]) { Toolkit tk = Toolkit.getDefaultToolkit(); Map map = (Map)tk.getDesktopProperty("awt.font.desktophints"); if (map != null) { for (Object k : map.keySet()) { System.out.println(k + " : " + map.get(k)); } } } } C:\>c:\jdk1.8\bin\java GetGamma Text-specific antialiasing enable key : LCD HRGB antialiasing text mode Text-specific LCD contrast key : 120 (*) I'm sure Outlook used to be a GDI app, but who knows what version you are using and what rendering technology it uses. I've tried to make the point many times before that someone can always point to a difference from 'native' rendering simply because the platforms like OS X and Windows have multiple rasterisers and multiple font technologies all of which are different from each other. So whilst any notably 'poor' rendering needs to be looked into it maybe sometimes an artifact of one rendering path compared to another .. -phil. On 3/6/2014 1:21 AM, Robert Fisher wrote: > Hi all, > > I think there is still room for improvement in terms of the 'contrast' or 'vibrancy' of fonts in JavaFX. Take a look at this example: > > http://i.imgur.com/6qSamTO.png > > I'm running Windows 7. What you are seeing is a screenshot of the default font, zoomed in 600%. The top text is JavaFX 8 (latest build as of 3 days ago). The bottom text is Outlook but could just as easily have been Firefox, Chrome, Word, or Eclipse SWT - they're all indistinguishable to me. > > The JavaFX text doesn't look as vibrant. In particular the smoothing algorithm seems to be making poor colour choices for the vertical strokes. At 100% the difference is subtle but important. > > I have the text fill set to Color.BLACK and the font smoothing type set to LCD. Is there something else I can configure to get more vibrant-looking fonts? > > Cheers! > Rob > > > -----Urspr?ngliche Nachricht----- > Von: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] Im Auftrag von Stephen F Northover > Gesendet: Mittwoch, 5. M?rz 2014 18:30 > An: Pedro Duque Vieira; OpenJFX Mailing List > Betreff: Re: Poor font rendering.. > > Hi Pedro, > > Font rendering in FX8 is using the native rasterizer so the glyphs should be identical to what the operating system is rendering. That said, we may have a bug. Please enter a JIRA with sample code and a screen shot of the bad rendering. That will give us something concrete to work with. > > Thanks, > Steve > > On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> Hi, >> >> As evidenced by the screenshots in http://pixelduke.wordpress.com/ >> blog posts about JMetro, javafx as noticeably poor font rendering >> visuals. The most recent screenshots were taken on a windows 8.1 >> machine and the older ones on windows 7, using Segoe UI (windows 7 & 8 system font). >> >> 1- As this been reported? >> >> 2- Is the javafx team working on it? >> >> 3- Is there something the developer can do to increase font rendering >> quality? >> >> Thanks! >> Best regards, >> >> > From swpalmer at gmail.com Thu Mar 6 10:25:22 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 6 Mar 2014 13:25:22 -0500 Subject: Poor font rendering.. In-Reply-To: <5318BC44.5030205@oracle.com> References: <5318BC44.5030205@oracle.com> Message-ID: If you notice, in the images provided, the length of the rendered text in pixels is significantly different between the two examples. That supports the theory that it is simply, sub-optimal positioning of the glyphs that is resulting in the more pronounced LCD anti-aliasing. Scott On Thu, Mar 6, 2014 at 1:19 PM, Phil Race wrote: > Perhaps the gamma adjustment is different ? > FX should pick this up from the > SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. > > I don't know what Outlook (*) uses if its a WPF app then maybe its picking > up an over-ridden setting for this from the registry : > http://msdn.microsoft.com/en-us/library/aa970267%28v=vs. > 110%29.aspx#gamma_level > You should be able to check that out fairly easily,and you can use this > JDK app to see what the SystemParameterInfo setting is. > > import java.awt.*; > import java.util.*; > public class GetGamma { > public static void main(String args[]) { > Toolkit tk = Toolkit.getDefaultToolkit(); > Map map = (Map)tk.getDesktopProperty("awt.font.desktophints"); > if (map != null) { > for (Object k : map.keySet()) { > System.out.println(k + " : " + map.get(k)); > } > } > } > } > > C:\>c:\jdk1.8\bin\java GetGamma > Text-specific antialiasing enable key : LCD HRGB antialiasing text mode > Text-specific LCD contrast key : 120 > > (*) I'm sure Outlook used to be a GDI app, but who knows what version you > are using > and what rendering technology it uses. > I've tried to make the point many times before that someone can always > point to > a difference from 'native' rendering simply because the platforms like OS > X and Windows > have multiple rasterisers and multiple font technologies all of which are > different > from each other. So whilst any notably 'poor' rendering needs to be > looked into > it maybe sometimes an artifact of one rendering path compared to another .. > > -phil. > > > On 3/6/2014 1:21 AM, Robert Fisher wrote: > >> Hi all, >> >> I think there is still room for improvement in terms of the 'contrast' or >> 'vibrancy' of fonts in JavaFX. Take a look at this example: >> >> http://i.imgur.com/6qSamTO.png >> >> I'm running Windows 7. What you are seeing is a screenshot of the default >> font, zoomed in 600%. The top text is JavaFX 8 (latest build as of 3 days >> ago). The bottom text is Outlook but could just as easily have been >> Firefox, Chrome, Word, or Eclipse SWT - they're all indistinguishable to me. >> >> The JavaFX text doesn't look as vibrant. In particular the smoothing >> algorithm seems to be making poor colour choices for the vertical strokes. >> At 100% the difference is subtle but important. >> >> I have the text fill set to Color.BLACK and the font smoothing type set >> to LCD. Is there something else I can configure to get more vibrant-looking >> fonts? >> >> Cheers! >> Rob >> >> >> -----Urspr?ngliche Nachricht----- >> Von: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces@ >> openjdk.java.net] Im Auftrag von Stephen F Northover >> Gesendet: Mittwoch, 5. M?rz 2014 18:30 >> An: Pedro Duque Vieira; OpenJFX Mailing List >> Betreff: Re: Poor font rendering.. >> >> Hi Pedro, >> >> Font rendering in FX8 is using the native rasterizer so the glyphs should >> be identical to what the operating system is rendering. That said, we may >> have a bug. Please enter a JIRA with sample code and a screen shot of the >> bad rendering. That will give us something concrete to work with. >> >> Thanks, >> Steve >> >> On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> >>> Hi, >>> >>> As evidenced by the screenshots in http://pixelduke.wordpress.com/ >>> blog posts about JMetro, javafx as noticeably poor font rendering >>> visuals. The most recent screenshots were taken on a windows 8.1 >>> machine and the older ones on windows 7, using Segoe UI (windows 7 & 8 >>> system font). >>> >>> 1- As this been reported? >>> >>> 2- Is the javafx team working on it? >>> >>> 3- Is there something the developer can do to increase font rendering >>> quality? >>> >>> Thanks! >>> Best regards, >>> >>> >>> >> > From philip.race at oracle.com Thu Mar 6 10:35:19 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Mar 2014 10:35:19 -0800 Subject: Poor font rendering.. In-Reply-To: References: <5318BC44.5030205@oracle.com> Message-ID: <5318BFE7.1040007@oracle.com> Does the evidence really support that ? You only need to look at the first letter "L". The stem is in exactly the same place isn't it? And yet the colours are different. The overall length is different which I attribute to rounding differences or metrics differences used in accumulating the position but that is a guess. -phil. On 3/6/2014 10:25 AM, Scott Palmer wrote: > If you notice, in the images provided, the length of the rendered text > in pixels is significantly different between the two examples. That > supports the theory that it is simply, sub-optimal positioning of the > glyphs that is resulting in the more pronounced LCD anti-aliasing. > > Scott > > > On Thu, Mar 6, 2014 at 1:19 PM, Phil Race > wrote: > > Perhaps the gamma adjustment is different ? > FX should pick this up from the > SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. > > I don't know what Outlook (*) uses if its a WPF app then maybe its > picking > up an over-ridden setting for this from the registry : > http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level > You should be able to check that out fairly easily,and you can use > this > JDK app to see what the SystemParameterInfo setting is. > > import java.awt.*; > import java.util.*; > public class GetGamma { > public static void main(String args[]) { > Toolkit tk = Toolkit.getDefaultToolkit(); > Map map = (Map)tk.getDesktopProperty("awt.font.desktophints"); > if (map != null) { > for (Object k : map.keySet()) { > System.out.println(k + " : " + map.get(k)); > } > } > } > } > > C:\>c:\jdk1.8\bin\java GetGamma > Text-specific antialiasing enable key : LCD HRGB antialiasing text > mode > Text-specific LCD contrast key : 120 > > (*) I'm sure Outlook used to be a GDI app, but who knows what > version you are using > and what rendering technology it uses. > I've tried to make the point many times before that someone can > always point to > a difference from 'native' rendering simply because the platforms > like OS X and Windows > have multiple rasterisers and multiple font technologies all of > which are different > from each other. So whilst any notably 'poor' rendering needs to > be looked into > it maybe sometimes an artifact of one rendering path compared to > another .. > > -phil. > > > On 3/6/2014 1:21 AM, Robert Fisher wrote: > > Hi all, > > I think there is still room for improvement in terms of the > 'contrast' or 'vibrancy' of fonts in JavaFX. Take a look at > this example: > > http://i.imgur.com/6qSamTO.png > > I'm running Windows 7. What you are seeing is a screenshot of > the default font, zoomed in 600%. The top text is JavaFX 8 > (latest build as of 3 days ago). The bottom text is Outlook > but could just as easily have been Firefox, Chrome, Word, or > Eclipse SWT - they're all indistinguishable to me. > > The JavaFX text doesn't look as vibrant. In particular the > smoothing algorithm seems to be making poor colour choices for > the vertical strokes. At 100% the difference is subtle but > important. > > I have the text fill set to Color.BLACK and the font smoothing > type set to LCD. Is there something else I can configure to > get more vibrant-looking fonts? > > Cheers! > Rob > > > -----Urspr?ngliche Nachricht----- > Von: openjfx-dev-bounces at openjdk.java.net > > [mailto:openjfx-dev-bounces at openjdk.java.net > ] Im Auftrag von > Stephen F Northover > Gesendet: Mittwoch, 5. M?rz 2014 18:30 > An: Pedro Duque Vieira; OpenJFX Mailing List > Betreff: Re: Poor font rendering.. > > Hi Pedro, > > Font rendering in FX8 is using the native rasterizer so the > glyphs should be identical to what the operating system is > rendering. That said, we may have a bug. Please enter a JIRA > with sample code and a screen shot of the bad rendering. That > will give us something concrete to work with. > > Thanks, > Steve > > On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: > > Hi, > > As evidenced by the screenshots in > http://pixelduke.wordpress.com/ > blog posts about JMetro, javafx as noticeably poor font > rendering > visuals. The most recent screenshots were taken on a > windows 8.1 > machine and the older ones on windows 7, using Segoe UI > (windows 7 & 8 system font). > > 1- As this been reported? > > 2- Is the javafx team working on it? > > 3- Is there something the developer can do to increase > font rendering > quality? > > Thanks! > Best regards, > > > > > From swpalmer at gmail.com Thu Mar 6 10:40:13 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 6 Mar 2014 13:40:13 -0500 Subject: Poor font rendering.. In-Reply-To: <5318BFE7.1040007@oracle.com> References: <5318BC44.5030205@oracle.com> <5318BFE7.1040007@oracle.com> Message-ID: I think the stem of the L is colored differently because of *sub-pixel* differences in its position. I.e. it appears to be at the same integer position, but it isn't at the same real position. It looks to me like that alone could account for the differences. Scott On Thu, Mar 6, 2014 at 1:35 PM, Phil Race wrote: > Does the evidence really support that ? > You only need to look at the first letter "L". The stem is in > exactly the same place isn't it? And yet the colours are different. > > The overall length is different which I attribute to rounding differences > or metrics differences used in accumulating the position but that is a > guess. > > -phil. > > > On 3/6/2014 10:25 AM, Scott Palmer wrote: > >> If you notice, in the images provided, the length of the rendered text in >> pixels is significantly different between the two examples. That supports >> the theory that it is simply, sub-optimal positioning of the glyphs that is >> resulting in the more pronounced LCD anti-aliasing. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:19 PM, Phil Race > philip.race at oracle.com>> wrote: >> >> Perhaps the gamma adjustment is different ? >> FX should pick this up from the >> SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. >> >> I don't know what Outlook (*) uses if its a WPF app then maybe its >> picking >> up an over-ridden setting for this from the registry : >> http://msdn.microsoft.com/en-us/library/aa970267%28v=vs. >> 110%29.aspx#gamma_level >> You should be able to check that out fairly easily,and you can use >> this >> JDK app to see what the SystemParameterInfo setting is. >> >> import java.awt.*; >> import java.util.*; >> public class GetGamma { >> public static void main(String args[]) { >> Toolkit tk = Toolkit.getDefaultToolkit(); >> Map map = (Map)tk.getDesktopProperty("awt.font.desktophints"); >> if (map != null) { >> for (Object k : map.keySet()) { >> System.out.println(k + " : " + map.get(k)); >> } >> } >> } >> } >> >> C:\>c:\jdk1.8\bin\java GetGamma >> Text-specific antialiasing enable key : LCD HRGB antialiasing text >> mode >> Text-specific LCD contrast key : 120 >> >> (*) I'm sure Outlook used to be a GDI app, but who knows what >> version you are using >> and what rendering technology it uses. >> I've tried to make the point many times before that someone can >> always point to >> a difference from 'native' rendering simply because the platforms >> like OS X and Windows >> have multiple rasterisers and multiple font technologies all of >> which are different >> from each other. So whilst any notably 'poor' rendering needs to >> be looked into >> it maybe sometimes an artifact of one rendering path compared to >> another .. >> >> -phil. >> >> >> On 3/6/2014 1:21 AM, Robert Fisher wrote: >> >> Hi all, >> >> I think there is still room for improvement in terms of the >> 'contrast' or 'vibrancy' of fonts in JavaFX. Take a look at >> this example: >> >> http://i.imgur.com/6qSamTO.png >> >> I'm running Windows 7. What you are seeing is a screenshot of >> the default font, zoomed in 600%. The top text is JavaFX 8 >> (latest build as of 3 days ago). The bottom text is Outlook >> but could just as easily have been Firefox, Chrome, Word, or >> Eclipse SWT - they're all indistinguishable to me. >> >> The JavaFX text doesn't look as vibrant. In particular the >> smoothing algorithm seems to be making poor colour choices for >> the vertical strokes. At 100% the difference is subtle but >> important. >> >> I have the text fill set to Color.BLACK and the font smoothing >> type set to LCD. Is there something else I can configure to >> get more vibrant-looking fonts? >> >> Cheers! >> Rob >> >> >> -----Urspr?ngliche Nachricht----- >> Von: openjfx-dev-bounces at openjdk.java.net >> >> [mailto:openjfx-dev-bounces at openjdk.java.net >> >> ] Im Auftrag von >> Stephen F Northover >> Gesendet: Mittwoch, 5. M?rz 2014 18:30 >> An: Pedro Duque Vieira; OpenJFX Mailing List >> Betreff: Re: Poor font rendering.. >> >> Hi Pedro, >> >> Font rendering in FX8 is using the native rasterizer so the >> glyphs should be identical to what the operating system is >> rendering. That said, we may have a bug. Please enter a JIRA >> with sample code and a screen shot of the bad rendering. That >> will give us something concrete to work with. >> >> Thanks, >> Steve >> >> On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> >> Hi, >> >> As evidenced by the screenshots in >> http://pixelduke.wordpress.com/ >> blog posts about JMetro, javafx as noticeably poor font >> rendering >> visuals. The most recent screenshots were taken on a >> windows 8.1 >> machine and the older ones on windows 7, using Segoe UI >> (windows 7 & 8 system font). >> >> 1- As this been reported? >> >> 2- Is the javafx team working on it? >> >> 3- Is there something the developer can do to increase >> font rendering >> quality? >> >> Thanks! >> Best regards, >> >> >> >> >> >> > From felipe.heidrich at oracle.com Thu Mar 6 10:47:32 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Thu, 6 Mar 2014 10:47:32 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <5317B0E1.3080203@bestsolution.at> References: <5317AC34.3060706@oracle.com> <5317B0E1.3080203@bestsolution.at> Message-ID: On Mar 5, 2014, at 3:18 PM, Tom Schindl wrote: > Why can't JavaFX not at least provide a font-API to create fonts with point? The current JavaFX API is point (see the doc). The thing is, on the desktop it uses DPI=72, so px=pt. In the printer the actual device DPI is used (so that 72pt=1in on the paper). Note, Mac is exactly the same, see the doc for CTFontRef for example https://developer.apple.com/library/mac/documentation/Carbon/Reference/CTFontRef/Reference/reference.html#//apple_ref/doc/uid/TP40005110 It talks about point size the very same way JavaFX does. That is so true that the very value passed to Font.font(double) is passed to CTFontCreateWithName() in CTFontStrike.java as is. The same is true for Windows, using DirectWrite and Linux, using FreeType. Felipe From philip.race at oracle.com Thu Mar 6 10:51:15 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Mar 2014 10:51:15 -0800 Subject: Poor font rendering.. In-Reply-To: References: <5318BC44.5030205@oracle.com> <5318BFE7.1040007@oracle.com> Message-ID: <5318C3A3.4080902@oracle.com> There really isn't any evidence of that. If it were true you'd see the blending into the pixels either side, but the pixels either side of the stem are 100% white in both cases. And examining the subpixels inside the extremities of the stem backs me up ... -phil. On 3/6/2014 10:40 AM, Scott Palmer wrote: > I think the stem of the L is colored differently because of > *sub-pixel* differences in its position. I.e. it appears to be at the > same integer position, but it isn't at the same real position. It > looks to me like that alone could account for the differences. > > Scott > > > On Thu, Mar 6, 2014 at 1:35 PM, Phil Race > wrote: > > Does the evidence really support that ? > You only need to look at the first letter "L". The stem is in > exactly the same place isn't it? And yet the colours are different. > > The overall length is different which I attribute to rounding > differences > or metrics differences used in accumulating the position but that > is a guess. > > -phil. > > > On 3/6/2014 10:25 AM, Scott Palmer wrote: > > If you notice, in the images provided, the length of the > rendered text in pixels is significantly different between the > two examples. That supports the theory that it is simply, > sub-optimal positioning of the glyphs that is resulting in the > more pronounced LCD anti-aliasing. > > Scott > > > On Thu, Mar 6, 2014 at 1:19 PM, Phil Race > > >> wrote: > > Perhaps the gamma adjustment is different ? > FX should pick this up from the > SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. > > I don't know what Outlook (*) uses if its a WPF app then > maybe its > picking > up an over-ridden setting for this from the registry : > http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level > You should be able to check that out fairly easily,and you > can use > this > JDK app to see what the SystemParameterInfo setting is. > > import java.awt.*; > import java.util.*; > public class GetGamma { > public static void main(String args[]) { > Toolkit tk = Toolkit.getDefaultToolkit(); > Map map = > (Map)tk.getDesktopProperty("awt.font.desktophints"); > if (map != null) { > for (Object k : map.keySet()) { > System.out.println(k + " : " + map.get(k)); > } > } > } > } > > C:\>c:\jdk1.8\bin\java GetGamma > Text-specific antialiasing enable key : LCD HRGB > antialiasing text > mode > Text-specific LCD contrast key : 120 > > (*) I'm sure Outlook used to be a GDI app, but who knows what > version you are using > and what rendering technology it uses. > I've tried to make the point many times before that > someone can > always point to > a difference from 'native' rendering simply because the > platforms > like OS X and Windows > have multiple rasterisers and multiple font technologies > all of > which are different > from each other. So whilst any notably 'poor' rendering > needs to > be looked into > it maybe sometimes an artifact of one rendering path > compared to > another .. > > -phil. > > > On 3/6/2014 1:21 AM, Robert Fisher wrote: > > Hi all, > > I think there is still room for improvement in terms > of the > 'contrast' or 'vibrancy' of fonts in JavaFX. Take a > look at > this example: > > http://i.imgur.com/6qSamTO.png > > I'm running Windows 7. What you are seeing is a > screenshot of > the default font, zoomed in 600%. The top text is JavaFX 8 > (latest build as of 3 days ago). The bottom text is > Outlook > but could just as easily have been Firefox, Chrome, > Word, or > Eclipse SWT - they're all indistinguishable to me. > > The JavaFX text doesn't look as vibrant. In particular the > smoothing algorithm seems to be making poor colour > choices for > the vertical strokes. At 100% the difference is subtle but > important. > > I have the text fill set to Color.BLACK and the font > smoothing > type set to LCD. Is there something else I can > configure to > get more vibrant-looking fonts? > > Cheers! > Rob > > > -----Urspr?ngliche Nachricht----- > Von: openjfx-dev-bounces at openjdk.java.net > > > > [mailto:openjfx-dev-bounces at openjdk.java.net > > > >] Im Auftrag von > Stephen F Northover > Gesendet: Mittwoch, 5. M?rz 2014 18:30 > An: Pedro Duque Vieira; OpenJFX Mailing List > Betreff: Re: Poor font rendering.. > > Hi Pedro, > > Font rendering in FX8 is using the native rasterizer > so the > glyphs should be identical to what the operating system is > rendering. That said, we may have a bug. Please enter > a JIRA > with sample code and a screen shot of the bad > rendering. That > will give us something concrete to work with. > > Thanks, > Steve > > On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: > > Hi, > > As evidenced by the screenshots in > http://pixelduke.wordpress.com/ > blog posts about JMetro, javafx as noticeably poor > font > rendering > visuals. The most recent screenshots were taken on a > windows 8.1 > machine and the older ones on windows 7, using > Segoe UI > (windows 7 & 8 system font). > > 1- As this been reported? > > 2- Is the javafx team working on it? > > 3- Is there something the developer can do to increase > font rendering > quality? > > Thanks! > Best regards, > > > > > > > From philip.race at oracle.com Thu Mar 6 10:53:57 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Mar 2014 10:53:57 -0800 Subject: Poor font rendering.. In-Reply-To: <5318C3A3.4080902@oracle.com> References: <5318BC44.5030205@oracle.com> <5318BFE7.1040007@oracle.com> <5318C3A3.4080902@oracle.com> Message-ID: <5318C445.30601@oracle.com> PS .. my second guess would be different rasterisers -phil. On 3/6/2014 10:51 AM, Phil Race wrote: > There really isn't any evidence of that. If it were true you'd see the > blending > into the pixels either side, but the pixels either side of the stem > are 100% > white in both cases. And examining the subpixels inside the > extremities of > the stem backs me up ... > > -phil. > > On 3/6/2014 10:40 AM, Scott Palmer wrote: >> I think the stem of the L is colored differently because of >> *sub-pixel* differences in its position. I.e. it appears to be at the >> same integer position, but it isn't at the same real position. It >> looks to me like that alone could account for the differences. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:35 PM, Phil Race > > wrote: >> >> Does the evidence really support that ? >> You only need to look at the first letter "L". The stem is in >> exactly the same place isn't it? And yet the colours are different. >> >> The overall length is different which I attribute to rounding >> differences >> or metrics differences used in accumulating the position but that >> is a guess. >> >> -phil. >> >> >> On 3/6/2014 10:25 AM, Scott Palmer wrote: >> >> If you notice, in the images provided, the length of the >> rendered text in pixels is significantly different between the >> two examples. That supports the theory that it is simply, >> sub-optimal positioning of the glyphs that is resulting in the >> more pronounced LCD anti-aliasing. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:19 PM, Phil Race >> >> > >> wrote: >> >> Perhaps the gamma adjustment is different ? >> FX should pick this up from the >> SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. >> >> I don't know what Outlook (*) uses if its a WPF app then >> maybe its >> picking >> up an over-ridden setting for this from the registry : >> http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level >> You should be able to check that out fairly easily,and you >> can use >> this >> JDK app to see what the SystemParameterInfo setting is. >> >> import java.awt.*; >> import java.util.*; >> public class GetGamma { >> public static void main(String args[]) { >> Toolkit tk = Toolkit.getDefaultToolkit(); >> Map map = >> (Map)tk.getDesktopProperty("awt.font.desktophints"); >> if (map != null) { >> for (Object k : map.keySet()) { >> System.out.println(k + " : " + map.get(k)); >> } >> } >> } >> } >> >> C:\>c:\jdk1.8\bin\java GetGamma >> Text-specific antialiasing enable key : LCD HRGB >> antialiasing text >> mode >> Text-specific LCD contrast key : 120 >> >> (*) I'm sure Outlook used to be a GDI app, but who knows >> what >> version you are using >> and what rendering technology it uses. >> I've tried to make the point many times before that >> someone can >> always point to >> a difference from 'native' rendering simply because the >> platforms >> like OS X and Windows >> have multiple rasterisers and multiple font technologies >> all of >> which are different >> from each other. So whilst any notably 'poor' rendering >> needs to >> be looked into >> it maybe sometimes an artifact of one rendering path >> compared to >> another .. >> >> -phil. >> >> >> On 3/6/2014 1:21 AM, Robert Fisher wrote: >> >> Hi all, >> >> I think there is still room for improvement in terms >> of the >> 'contrast' or 'vibrancy' of fonts in JavaFX. Take a >> look at >> this example: >> >> http://i.imgur.com/6qSamTO.png >> >> I'm running Windows 7. What you are seeing is a >> screenshot of >> the default font, zoomed in 600%. The top text is >> JavaFX 8 >> (latest build as of 3 days ago). The bottom text is >> Outlook >> but could just as easily have been Firefox, Chrome, >> Word, or >> Eclipse SWT - they're all indistinguishable to me. >> >> The JavaFX text doesn't look as vibrant. In >> particular the >> smoothing algorithm seems to be making poor colour >> choices for >> the vertical strokes. At 100% the difference is >> subtle but >> important. >> >> I have the text fill set to Color.BLACK and the font >> smoothing >> type set to LCD. Is there something else I can >> configure to >> get more vibrant-looking fonts? >> >> Cheers! >> Rob >> >> >> -----Urspr?ngliche Nachricht----- >> Von: openjfx-dev-bounces at openjdk.java.net >> >> > > >> [mailto:openjfx-dev-bounces at openjdk.java.net >> >> >> > >] Im Auftrag von >> Stephen F Northover >> Gesendet: Mittwoch, 5. M?rz 2014 18:30 >> An: Pedro Duque Vieira; OpenJFX Mailing List >> Betreff: Re: Poor font rendering.. >> >> Hi Pedro, >> >> Font rendering in FX8 is using the native rasterizer >> so the >> glyphs should be identical to what the operating >> system is >> rendering. That said, we may have a bug. Please enter >> a JIRA >> with sample code and a screen shot of the bad >> rendering. That >> will give us something concrete to work with. >> >> Thanks, >> Steve >> >> On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> >> Hi, >> >> As evidenced by the screenshots in >> http://pixelduke.wordpress.com/ >> blog posts about JMetro, javafx as noticeably poor >> font >> rendering >> visuals. The most recent screenshots were taken on a >> windows 8.1 >> machine and the older ones on windows 7, using >> Segoe UI >> (windows 7 & 8 system font). >> >> 1- As this been reported? >> >> 2- Is the javafx team working on it? >> >> 3- Is there something the developer can do to >> increase >> font rendering >> quality? >> >> Thanks! >> Best regards, >> >> >> >> >> >> >> > From hang.vo at oracle.com Thu Mar 6 11:03:31 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 19:03:31 +0000 Subject: hg: openjfx/8u-dev/rt: TESTS ONLY: Work around Eclipse JDK8 compiler problem Message-ID: <20140306190408.C6F4562588@hg.openjdk.java.net> Changeset: dfd9bd2f536d Author: snorthov Date: 2014-03-06 13:54 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dfd9bd2f536d TESTS ONLY: Work around Eclipse JDK8 compiler problem ! modules/base/src/test/java/com/sun/javafx/collections/ListListenerHelperTest.java ! modules/base/src/test/java/com/sun/javafx/collections/MapListenerHelperTest.java ! modules/base/src/test/java/com/sun/javafx/collections/SetListenerHelperTest.java From felipe.heidrich at oracle.com Thu Mar 6 11:16:00 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Thu, 6 Mar 2014 11:16:00 -0800 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: <703F9B98-CB41-4783-BB17-57129A904CC8@oracle.com> Hi Robert On Mar 6, 2014, at 1:21 AM, Robert Fisher wrote: > Is there something else I can configure to get more vibrant-looking fonts? Take a look at: https://javafx-jira.kenai.com/browse/RT-14187 Try a) -Dprism.subpixeltext=false b) -Dprism.subpixeltext=true c) -Dprism.subpixeltext=native d) -Dprism.subpixeltext=vertical e) -Dprism.text=t2k Let me know if anything makes it better to you. Regards Felipe From david.grieve at oracle.com Thu Mar 6 11:37:10 2014 From: david.grieve at oracle.com (David Grieve) Date: Thu, 06 Mar 2014 14:37:10 -0500 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: References: <5317AC34.3060706@oracle.com> <5317B0E1.3080203@bestsolution.at> Message-ID: <5318CE66.40208@oracle.com> Hey Felipe, I recall a couple of years ago when Phil drilled it into me that Font size was pixels. So when you said that Font size is point, I was skeptical. But, indeed, you are correct and I am mistaken. I see now that setting font size from point units in our CSS is broken. Our CSS implementation will convert -fx-font-size: 12pt; to 9px since CSS says that 72/96th of a point equals a pixel. But that should convert to 12px. Fortunately, modena and caspian are all pixel based units. It is important to note that if the assertion that DPI=72 ever changes, then CSS will be broken since I've (incorrectly) assumed all along that Font size is pixels. On 3/6/14, 1:47 PM, Felipe Heidrich wrote: > On Mar 5, 2014, at 3:18 PM, Tom Schindl wrote: > >> Why can't JavaFX not at least provide a font-API to create fonts with point? > > The current JavaFX API is point (see the doc). > The thing is, on the desktop it uses DPI=72, so px=pt. > In the printer the actual device DPI is used (so that 72pt=1in on the paper). > > Note, Mac is exactly the same, see the doc for CTFontRef for example > https://developer.apple.com/library/mac/documentation/Carbon/Reference/CTFontRef/Reference/reference.html#//apple_ref/doc/uid/TP40005110 > It talks about point size the very same way JavaFX does. > > That is so true that the very value passed to Font.font(double) is passed to CTFontCreateWithName() in CTFontStrike.java as is. > The same is true for Windows, using DirectWrite and Linux, using FreeType. > > > Felipe > From philip.race at oracle.com Thu Mar 6 13:10:51 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Mar 2014 13:10:51 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <5318CE66.40208@oracle.com> References: <5317AC34.3060706@oracle.com> <5317B0E1.3080203@bestsolution.at> <5318CE66.40208@oracle.com> Message-ID: <5318E45B.3050609@oracle.com> > Our CSS implementation will convert -fx-font-size: 12pt; to 9px > since CSS says that 72/96th of a point equals a pixel I think your sum is backward. If 0.75pts==1 pixel then a 12 pt font will be 16 pixels. Perhaps another way of looking at this is that the CSS "1 pixel=1/96 inch" approximation shouldn't be taken as applying to FX since it has its own approximation that 1 pixel=1/72 inch. In the two year ago discussion I think the central point was that on-screen FX is wholly ignorant of the actual screen DPI and it always interprets as "user space" pixels which are equated to points. There is definitely no starting point (ahem) of trying to do any mapping to the real world sizes. Printing applies a transform from user-space to device space because the approximation of 72dpi would not be at all satisfactory there. And since we do that and we have good information on the real DPI of the device, we can get it "exactly right". On screen nothing of the kind will happen unless you figure something out and directly apply it to your entire Scene. -phil. On 3/6/2014 11:37 AM, David Grieve wrote: > Hey Felipe, > > I recall a couple of years ago when Phil drilled it into me that Font > size was pixels. So when you said that Font size is point, I was > skeptical. But, indeed, you are correct and I am mistaken. > > I see now that setting font size from point units in our CSS is > broken. Our CSS implementation will convert -fx-font-size: 12pt; to > 9px since CSS says that 72/96th of a point equals a pixel. But that > should convert to 12px. Fortunately, modena and caspian are all pixel > based units. > > It is important to note that if the assertion that DPI=72 ever > changes, then CSS will be broken since I've (incorrectly) assumed all > along that Font size is pixels. > > On 3/6/14, 1:47 PM, Felipe Heidrich wrote: >> On Mar 5, 2014, at 3:18 PM, Tom Schindl >> wrote: >> >>> Why can't JavaFX not at least provide a font-API to create fonts >>> with point? >> >> The current JavaFX API is point (see the doc). >> The thing is, on the desktop it uses DPI=72, so px=pt. >> In the printer the actual device DPI is used (so that 72pt=1in on the >> paper). >> >> Note, Mac is exactly the same, see the doc for CTFontRef for example >> https://developer.apple.com/library/mac/documentation/Carbon/Reference/CTFontRef/Reference/reference.html#//apple_ref/doc/uid/TP40005110 >> >> It talks about point size the very same way JavaFX does. >> >> That is so true that the very value passed to Font.font(double) is >> passed to CTFontCreateWithName() in CTFontStrike.java as is. >> The same is true for Windows, using DirectWrite and Linux, using >> FreeType. >> >> >> Felipe >> > From hang.vo at oracle.com Thu Mar 6 13:33:18 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 21:33:18 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35197: Use Lambda in FX runtime and samples [media] Message-ID: <20140306213402.A10EE625AF@hg.openjdk.java.net> Changeset: 29346901e6f1 Author: snorthov Date: 2014-03-06 16:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/29346901e6f1 RT-35197: Use Lambda in FX runtime and samples [media] Summary: This component was lambdified (unlambdified file names recorded in the JIRA) ! modules/media/src/main/java/com/sun/javafx/media/PrismMediaFrameHandler.java ! modules/media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java ! modules/media/src/main/java/com/sun/media/jfxmediaimpl/MediaDisposer.java ! modules/media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaAudioClipPlayer.java ! modules/media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java ! modules/media/src/main/java/com/sun/media/jfxmediaimpl/platform/PlatformManager.java ! modules/media/src/main/java/javafx/scene/media/Media.java ! modules/media/src/main/java/javafx/scene/media/MediaPlayer.java ! modules/media/src/main/java/javafx/scene/media/MediaView.java From felipe.heidrich at oracle.com Thu Mar 6 13:46:47 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Thu, 6 Mar 2014 13:46:47 -0800 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <5318CE66.40208@oracle.com> References: <5317AC34.3060706@oracle.com> <5317B0E1.3080203@bestsolution.at> <5318CE66.40208@oracle.com> Message-ID: Hi David On Mar 6, 2014, at 11:37 AM, David Grieve wrote: > I see now that setting font size from point units in our CSS is broken. It depends how you judge. If you compare the result of our CSS to any browser then our handling of point size in your CSS is correct. fx-font-size=12pt [In JFX] == font-size=12pt [In any UA] if you change that you too will break user. IMO the one thing we can do is to add a switch (either to Node or CSS) so allow DPI to be set, so that 12pt in Node and CSS match. Felipe From swpalmer at gmail.com Thu Mar 6 13:57:16 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 6 Mar 2014 16:57:16 -0500 Subject: Poor font rendering.. In-Reply-To: <5318C3A3.4080902@oracle.com> References: <5318BC44.5030205@oracle.com> <5318BFE7.1040007@oracle.com> <5318C3A3.4080902@oracle.com> Message-ID: That's not true. There is a difference in the "white" space around the letters. The "white" pixel before the stem of the L is not 100% white in either case and the difference is in line with what I would expect if there was a sub-pixel shift.. Scott On Thu, Mar 6, 2014 at 1:51 PM, Phil Race wrote: > There really isn't any evidence of that. If it were true you'd see the > blending > into the pixels either side, but the pixels either side of the stem are > 100% > white in both cases. And examining the subpixels inside the extremities of > the stem backs me up ... > > -phil. > > > On 3/6/2014 10:40 AM, Scott Palmer wrote: > >> I think the stem of the L is colored differently because of *sub-pixel* >> differences in its position. I.e. it appears to be at the same integer >> position, but it isn't at the same real position. It looks to me like that >> alone could account for the differences. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:35 PM, Phil Race > philip.race at oracle.com>> wrote: >> >> Does the evidence really support that ? >> You only need to look at the first letter "L". The stem is in >> exactly the same place isn't it? And yet the colours are different. >> >> The overall length is different which I attribute to rounding >> differences >> or metrics differences used in accumulating the position but that >> is a guess. >> >> -phil. >> >> >> On 3/6/2014 10:25 AM, Scott Palmer wrote: >> >> If you notice, in the images provided, the length of the >> rendered text in pixels is significantly different between the >> two examples. That supports the theory that it is simply, >> sub-optimal positioning of the glyphs that is resulting in the >> more pronounced LCD anti-aliasing. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:19 PM, Phil Race >> >> > >> >> wrote: >> >> Perhaps the gamma adjustment is different ? >> FX should pick this up from the >> SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST setting. >> >> I don't know what Outlook (*) uses if its a WPF app then >> maybe its >> picking >> up an over-ridden setting for this from the registry : >> http://msdn.microsoft.com/en-us/library/aa970267%28v=vs. >> 110%29.aspx#gamma_level >> You should be able to check that out fairly easily,and you >> can use >> this >> JDK app to see what the SystemParameterInfo setting is. >> >> import java.awt.*; >> import java.util.*; >> public class GetGamma { >> public static void main(String args[]) { >> Toolkit tk = Toolkit.getDefaultToolkit(); >> Map map = >> (Map)tk.getDesktopProperty("awt.font.desktophints"); >> if (map != null) { >> for (Object k : map.keySet()) { >> System.out.println(k + " : " + map.get(k)); >> } >> } >> } >> } >> >> C:\>c:\jdk1.8\bin\java GetGamma >> Text-specific antialiasing enable key : LCD HRGB >> antialiasing text >> mode >> Text-specific LCD contrast key : 120 >> >> (*) I'm sure Outlook used to be a GDI app, but who knows what >> version you are using >> and what rendering technology it uses. >> I've tried to make the point many times before that >> someone can >> always point to >> a difference from 'native' rendering simply because the >> platforms >> like OS X and Windows >> have multiple rasterisers and multiple font technologies >> all of >> which are different >> from each other. So whilst any notably 'poor' rendering >> needs to >> be looked into >> it maybe sometimes an artifact of one rendering path >> compared to >> another .. >> >> -phil. >> >> >> On 3/6/2014 1:21 AM, Robert Fisher wrote: >> >> Hi all, >> >> I think there is still room for improvement in terms >> of the >> 'contrast' or 'vibrancy' of fonts in JavaFX. Take a >> look at >> this example: >> >> http://i.imgur.com/6qSamTO.png >> >> I'm running Windows 7. What you are seeing is a >> screenshot of >> the default font, zoomed in 600%. The top text is JavaFX 8 >> (latest build as of 3 days ago). The bottom text is >> Outlook >> but could just as easily have been Firefox, Chrome, >> Word, or >> Eclipse SWT - they're all indistinguishable to me. >> >> The JavaFX text doesn't look as vibrant. In particular the >> smoothing algorithm seems to be making poor colour >> choices for >> the vertical strokes. At 100% the difference is subtle but >> important. >> >> I have the text fill set to Color.BLACK and the font >> smoothing >> type set to LCD. Is there something else I can >> configure to >> get more vibrant-looking fonts? >> >> Cheers! >> Rob >> >> >> -----Urspr?ngliche Nachricht----- >> Von: openjfx-dev-bounces at openjdk.java.net >> >> > > >> [mailto:openjfx-dev-bounces at openjdk.java.net >> >> >> >> > >] Im Auftrag von >> Stephen F Northover >> Gesendet: Mittwoch, 5. M?rz 2014 18:30 >> An: Pedro Duque Vieira; OpenJFX Mailing List >> Betreff: Re: Poor font rendering.. >> >> Hi Pedro, >> >> Font rendering in FX8 is using the native rasterizer >> so the >> glyphs should be identical to what the operating system is >> rendering. That said, we may have a bug. Please enter >> a JIRA >> with sample code and a screen shot of the bad >> rendering. That >> will give us something concrete to work with. >> >> Thanks, >> Steve >> >> On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> >> Hi, >> >> As evidenced by the screenshots in >> http://pixelduke.wordpress.com/ >> blog posts about JMetro, javafx as noticeably poor >> font >> rendering >> visuals. The most recent screenshots were taken on a >> windows 8.1 >> machine and the older ones on windows 7, using >> Segoe UI >> (windows 7 & 8 system font). >> >> 1- As this been reported? >> >> 2- Is the javafx team working on it? >> >> 3- Is there something the developer can do to increase >> font rendering >> quality? >> >> Thanks! >> Best regards, >> >> >> >> >> >> >> >> > From pedro.duquevieira at gmail.com Thu Mar 6 14:05:58 2014 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 6 Mar 2014 22:05:58 +0000 Subject: Poor font rendering.. Message-ID: I have created an issue on jira: https://javafx-jira.kenai.com/browse/RT-36146 Felipe, I couldn't assign the issue to you but I think someone already did. Guys, could you please add in your comments/suggestions to the issue? I guess that would be nice for the person who is going to fix it or the developers that might stumble into this. Thanks! -- Pedro Duque Vieira From philip.race at oracle.com Thu Mar 6 14:53:46 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Mar 2014 14:53:46 -0800 Subject: Poor font rendering.. In-Reply-To: References: <5318BC44.5030205@oracle.com> <5318BFE7.1040007@oracle.com> <5318C3A3.4080902@oracle.com> Message-ID: <5318FC7A.5030206@oracle.com> I am not sure what you are looking at but I see 255,255,255 pixels on all sides of the stems. The stems are touching 3 pixels. I'm talking about the ones to the sides of those 3 pixel wide stems. In any case I've used Windows 7 wordpad and Segoe UI 9pt (aka 12pixel) and can see identical rendering to your Outlook case. Wordpad (and so I infer Outlook) is using GDI which 1) is very likely a different rasteriser (FX is using the one from DirectWrite) 2) doesn't do sub-pixel positioning because its only got int APIs. So this seems to come down to DirectWrite vs GDI and personal preferences ... -phil. On 3/6/2014 1:57 PM, Scott Palmer wrote: > That's not true. There is a difference in the "white" space around > the letters. The "white" pixel before the stem of the L is not 100% > white in either case and the difference is in line with what I would > expect if there was a sub-pixel shift.. > > Scott > > > On Thu, Mar 6, 2014 at 1:51 PM, Phil Race > wrote: > > There really isn't any evidence of that. If it were true you'd see > the blending > into the pixels either side, but the pixels either side of the > stem are 100% > white in both cases. And examining the subpixels inside the > extremities of > the stem backs me up ... > > -phil. > > > On 3/6/2014 10:40 AM, Scott Palmer wrote: > > I think the stem of the L is colored differently because of > *sub-pixel* differences in its position. I.e. it appears to > be at the same integer position, but it isn't at the same real > position. It looks to me like that alone could account for > the differences. > > Scott > > > On Thu, Mar 6, 2014 at 1:35 PM, Phil Race > > >> wrote: > > Does the evidence really support that ? > You only need to look at the first letter "L". The stem is in > exactly the same place isn't it? And yet the colours are > different. > > The overall length is different which I attribute to rounding > differences > or metrics differences used in accumulating the position > but that > is a guess. > > -phil. > > > On 3/6/2014 10:25 AM, Scott Palmer wrote: > > If you notice, in the images provided, the length of the > rendered text in pixels is significantly different > between the > two examples. That supports the theory that it is simply, > sub-optimal positioning of the glyphs that is > resulting in the > more pronounced LCD anti-aliasing. > > Scott > > > On Thu, Mar 6, 2014 at 1:19 PM, Phil Race > > > > > >>> wrote: > > Perhaps the gamma adjustment is different ? > FX should pick this up from the > SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST > setting. > > I don't know what Outlook (*) uses if its a WPF > app then > maybe its > picking > up an over-ridden setting for this from the registry : > http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level > You should be able to check that out fairly > easily,and you > can use > this > JDK app to see what the SystemParameterInfo > setting is. > > import java.awt.*; > import java.util.*; > public class GetGamma { > public static void main(String args[]) { > Toolkit tk = Toolkit.getDefaultToolkit(); > Map map = > (Map)tk.getDesktopProperty("awt.font.desktophints"); > if (map != null) { > for (Object k : map.keySet()) { > System.out.println(k + " : " + > map.get(k)); > } > } > } > } > > C:\>c:\jdk1.8\bin\java GetGamma > Text-specific antialiasing enable key : LCD HRGB > antialiasing text > mode > Text-specific LCD contrast key : 120 > > (*) I'm sure Outlook used to be a GDI app, but who > knows what > version you are using > and what rendering technology it uses. > I've tried to make the point many times before that > someone can > always point to > a difference from 'native' rendering simply > because the > platforms > like OS X and Windows > have multiple rasterisers and multiple font > technologies > all of > which are different > from each other. So whilst any notably 'poor' > rendering > needs to > be looked into > it maybe sometimes an artifact of one rendering path > compared to > another .. > > -phil. > > > On 3/6/2014 1:21 AM, Robert Fisher wrote: > > Hi all, > > I think there is still room for improvement in > terms > of the > 'contrast' or 'vibrancy' of fonts in JavaFX. > Take a > look at > this example: > > http://i.imgur.com/6qSamTO.png > > I'm running Windows 7. What you are seeing is a > screenshot of > the default font, zoomed in 600%. The top text > is JavaFX 8 > (latest build as of 3 days ago). The bottom > text is > Outlook > but could just as easily have been Firefox, > Chrome, > Word, or > Eclipse SWT - they're all indistinguishable to me. > > The JavaFX text doesn't look as vibrant. In > particular the > smoothing algorithm seems to be making poor colour > choices for > the vertical strokes. At 100% the difference > is subtle but > important. > > I have the text fill set to Color.BLACK and > the font > smoothing > type set to LCD. Is there something else I can > configure to > get more vibrant-looking fonts? > > Cheers! > Rob > > > -----Urspr?ngliche Nachricht----- > Von: openjfx-dev-bounces at openjdk.java.net > > > > > >> > [mailto:openjfx-dev-bounces at openjdk.java.net > > > > > > > >>] Im Auftrag von > Stephen F Northover > Gesendet: Mittwoch, 5. M?rz 2014 18:30 > An: Pedro Duque Vieira; OpenJFX Mailing List > Betreff: Re: Poor font rendering.. > > Hi Pedro, > > Font rendering in FX8 is using the native > rasterizer > so the > glyphs should be identical to what the > operating system is > rendering. That said, we may have a bug. > Please enter > a JIRA > with sample code and a screen shot of the bad > rendering. That > will give us something concrete to work with. > > Thanks, > Steve > > On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: > > Hi, > > As evidenced by the screenshots in > http://pixelduke.wordpress.com/ > blog posts about JMetro, javafx as > noticeably poor > font > rendering > visuals. The most recent screenshots were > taken on a > windows 8.1 > machine and the older ones on windows 7, using > Segoe UI > (windows 7 & 8 system font). > > 1- As this been reported? > > 2- Is the javafx team working on it? > > 3- Is there something the developer can do > to increase > font rendering > quality? > > Thanks! > Best regards, > > > > > > > > > From hang.vo at oracle.com Thu Mar 6 15:03:58 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Mar 2014 23:03:58 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35978 changing unltimate fallback for fonts when fontconfig is not present (embedded devices) Message-ID: <20140306230438.877FE625BD@hg.openjdk.java.net> Changeset: efb0a3d40c1f Author: ddhill Date: 2014-03-06 17:50 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/efb0a3d40c1f RT-35978 changing unltimate fallback for fonts when fontconfig is not present (embedded devices) Reviewed-by: kselle, fheidric ! modules/graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java From james.graham at oracle.com Thu Mar 6 16:54:22 2014 From: james.graham at oracle.com (Jim Graham) Date: Thu, 06 Mar 2014 16:54:22 -0800 Subject: Poor font rendering.. In-Reply-To: <5318FC7A.5030206@oracle.com> References: <5318BC44.5030205@oracle.com> <5318BFE7.1040007@oracle.com> <5318C3A3.4080902@oracle.com> <5318FC7A.5030206@oracle.com> Message-ID: <531918BE.5080301@oracle.com> If you look at the first "o", the version on top has a leading edge that is only 2 pixels wide and the one below is a dark middle column flanked by 2 lightly colored columns. It's as if the placement on the lower text is trying harder to center its columns of sub-pixel samples to ensure that there is at least one column that gets hit by the darkest majority of the LCD sub-pixel weighted samples, but the one on top just distributes them as they arrive. Spreading 6 samples, with the middle samples being the darkest, evenly over 2 pixels has much less contrast then distributing them with the darkest 3 samples in the middle on one pixel and the remainder lower-coverage samples distributed on the pixels to the left and right of the stem. Felipe's recommendations for turning off sub-pixel shifting of the text may impact this if, for instance, the rasterizer returned LCD samples that were intended to start on an integer boundary so that all stems had their darkest parts on a single pixel, but then our placement algorithm decided to place the entire glyph on a 1/3 pixel alignment instead... ...jim On 3/6/14 2:53 PM, Phil Race wrote: > I am not sure what you are looking at but I see 255,255,255 pixels on > all sides of > the stems. The stems are touching 3 pixels. I'm talking about the ones > to the sides of > those 3 pixel wide stems. > > In any case I've used Windows 7 wordpad and Segoe UI 9pt (aka 12pixel) and > can see identical rendering to your Outlook case. > > Wordpad (and so I infer Outlook) is using GDI which > 1) is very likely a different rasteriser (FX is using the one from > DirectWrite) > 2) doesn't do sub-pixel positioning because its only got int APIs. > > So this seems to come down to DirectWrite vs GDI and personal > preferences ... > > -phil. > > On 3/6/2014 1:57 PM, Scott Palmer wrote: >> That's not true. There is a difference in the "white" space around >> the letters. The "white" pixel before the stem of the L is not 100% >> white in either case and the difference is in line with what I would >> expect if there was a sub-pixel shift.. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:51 PM, Phil Race > > wrote: >> >> There really isn't any evidence of that. If it were true you'd see >> the blending >> into the pixels either side, but the pixels either side of the >> stem are 100% >> white in both cases. And examining the subpixels inside the >> extremities of >> the stem backs me up ... >> >> -phil. >> >> >> On 3/6/2014 10:40 AM, Scott Palmer wrote: >> >> I think the stem of the L is colored differently because of >> *sub-pixel* differences in its position. I.e. it appears to >> be at the same integer position, but it isn't at the same real >> position. It looks to me like that alone could account for >> the differences. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:35 PM, Phil Race >> >> > >> wrote: >> >> Does the evidence really support that ? >> You only need to look at the first letter "L". The stem is in >> exactly the same place isn't it? And yet the colours are >> different. >> >> The overall length is different which I attribute to rounding >> differences >> or metrics differences used in accumulating the position >> but that >> is a guess. >> >> -phil. >> >> >> On 3/6/2014 10:25 AM, Scott Palmer wrote: >> >> If you notice, in the images provided, the length of the >> rendered text in pixels is significantly different >> between the >> two examples. That supports the theory that it is >> simply, >> sub-optimal positioning of the glyphs that is >> resulting in the >> more pronounced LCD anti-aliasing. >> >> Scott >> >> >> On Thu, Mar 6, 2014 at 1:19 PM, Phil Race >> > > > >> > >> >> > >>> wrote: >> >> Perhaps the gamma adjustment is different ? >> FX should pick this up from the >> SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST >> setting. >> >> I don't know what Outlook (*) uses if its a WPF >> app then >> maybe its >> picking >> up an over-ridden setting for this from the >> registry : >> >> http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level >> >> You should be able to check that out fairly >> easily,and you >> can use >> this >> JDK app to see what the SystemParameterInfo >> setting is. >> >> import java.awt.*; >> import java.util.*; >> public class GetGamma { >> public static void main(String args[]) { >> Toolkit tk = Toolkit.getDefaultToolkit(); >> Map map = >> (Map)tk.getDesktopProperty("awt.font.desktophints"); >> if (map != null) { >> for (Object k : map.keySet()) { >> System.out.println(k + " : " + >> map.get(k)); >> } >> } >> } >> } >> >> C:\>c:\jdk1.8\bin\java GetGamma >> Text-specific antialiasing enable key : LCD HRGB >> antialiasing text >> mode >> Text-specific LCD contrast key : 120 >> >> (*) I'm sure Outlook used to be a GDI app, but who >> knows what >> version you are using >> and what rendering technology it uses. >> I've tried to make the point many times before that >> someone can >> always point to >> a difference from 'native' rendering simply >> because the >> platforms >> like OS X and Windows >> have multiple rasterisers and multiple font >> technologies >> all of >> which are different >> from each other. So whilst any notably 'poor' >> rendering >> needs to >> be looked into >> it maybe sometimes an artifact of one rendering path >> compared to >> another .. >> >> -phil. >> >> >> On 3/6/2014 1:21 AM, Robert Fisher wrote: >> >> Hi all, >> >> I think there is still room for improvement in >> terms >> of the >> 'contrast' or 'vibrancy' of fonts in JavaFX. >> Take a >> look at >> this example: >> >> http://i.imgur.com/6qSamTO.png >> >> I'm running Windows 7. What you are seeing is a >> screenshot of >> the default font, zoomed in 600%. The top text >> is JavaFX 8 >> (latest build as of 3 days ago). The bottom >> text is >> Outlook >> but could just as easily have been Firefox, >> Chrome, >> Word, or >> Eclipse SWT - they're all indistinguishable to >> me. >> >> The JavaFX text doesn't look as vibrant. In >> particular the >> smoothing algorithm seems to be making poor >> colour >> choices for >> the vertical strokes. At 100% the difference >> is subtle but >> important. >> >> I have the text fill set to Color.BLACK and >> the font >> smoothing >> type set to LCD. Is there something else I can >> configure to >> get more vibrant-looking fonts? >> >> Cheers! >> Rob >> >> >> -----Urspr?ngliche Nachricht----- >> Von: openjfx-dev-bounces at openjdk.java.net >> >> > > >> > >> > >> >> [mailto:openjfx-dev-bounces at openjdk.java.net >> >> >> > > >> >> > >> > >>] Im Auftrag von >> Stephen F Northover >> Gesendet: Mittwoch, 5. M?rz 2014 18:30 >> An: Pedro Duque Vieira; OpenJFX Mailing List >> Betreff: Re: Poor font rendering.. >> >> Hi Pedro, >> >> Font rendering in FX8 is using the native >> rasterizer >> so the >> glyphs should be identical to what the >> operating system is >> rendering. That said, we may have a bug. >> Please enter >> a JIRA >> with sample code and a screen shot of the bad >> rendering. That >> will give us something concrete to work with. >> >> Thanks, >> Steve >> >> On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote: >> >> Hi, >> >> As evidenced by the screenshots in >> http://pixelduke.wordpress.com/ >> blog posts about JMetro, javafx as >> noticeably poor >> font >> rendering >> visuals. The most recent screenshots were >> taken on a >> windows 8.1 >> machine and the older ones on windows 7, >> using >> Segoe UI >> (windows 7 & 8 system font). >> >> 1- As this been reported? >> >> 2- Is the javafx team working on it? >> >> 3- Is there something the developer can do >> to increase >> font rendering >> quality? >> >> Thanks! >> Best regards, >> >> >> >> >> >> >> >> >> > From david.grieve at oracle.com Thu Mar 6 16:56:55 2014 From: david.grieve at oracle.com (David Grieve) Date: Thu, 06 Mar 2014 19:56:55 -0500 Subject: CSS Font size in points doesn't match Node.Font.Size In-Reply-To: <5318E45B.3050609@oracle.com> References: <5317AC34.3060706@oracle.com> <5317B0E1.3080203@bestsolution.at> <5318CE66.40208@oracle.com> <5318E45B.3050609@oracle.com> Message-ID: <53191957.7060706@oracle.com> On 3/6/14, 4:10 PM, Phil Race wrote: > I think your sum is backward. If 0.75pts==1 pixel then a 12 pt font > will be 16 pixels. Exactly why my wife doesn't let me near the checkbook. From rfisher at tesis.de Fri Mar 7 01:41:34 2014 From: rfisher at tesis.de (Robert Fisher) Date: Fri, 7 Mar 2014 10:41:34 +0100 Subject: Poor font rendering.. Message-ID: Hi Felipe, Hi Phil, Thanks for the tips. Phil, your program yielded the following output: Text-specific antialiasing enable key : LCD HRGB antialiasing text mode Text-specific LCD contrast key : 120 I tried all of the 5 settings that Felix mentioned. Here are my results for the default font (Segoe UI 9pt, black): http://i.imgur.com/45FewcL.png The difference in quality between the JavaFX images and the rest is too great to be chalked up to personal preferences. Whether it's the fault of JavaFX, or the native rendering mechanism being used, or my own configuration is another question. Cheers, Rob From vadim.pakhnushev at oracle.com Fri Mar 7 03:49:04 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 07 Mar 2014 15:49:04 +0400 Subject: [8u20] Review request for RT-20434: Image loading in j2d incorrectly handles gray scale Message-ID: <5319B230.1020206@oracle.com> Jim, Kevin, Please review the fix: https://javafx-jira.kenai.com/browse/RT-20434 http://cr.openjdk.java.net/~vadim/RT-20434/webrev.00/ Thanks, Vadim From hang.vo at oracle.com Fri Mar 7 05:03:53 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Mar 2014 13:03:53 +0000 Subject: hg: openjfx/8u-dev/rt: RT-8628: JPEGImageLoader_decompressIndirect has incorrect text in exception message. Message-ID: <20140307130601.4D5D6625D9@hg.openjdk.java.net> Changeset: b2217904cc6a Author: vadim Date: 2014-03-07 16:45 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b2217904cc6a RT-8628: JPEGImageLoader_decompressIndirect has incorrect text in exception message. Summary: fix exception message ! modules/graphics/src/main/native-iio/jpegloader.c From hang.vo at oracle.com Fri Mar 7 05:18:52 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Mar 2014 13:18:52 +0000 Subject: hg: openjfx/8u-dev/rt: 4 new changesets Message-ID: <20140307132029.E1342625DA@hg.openjdk.java.net> Changeset: 050af50b4a0e Author: Anthony Petrov Date: 2014-03-07 17:09 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/050af50b4a0e RT-36132: [Windows] Shift+Scroll Wheel should do horizontal scrolling on Windows Summary: Emulate horizontal scrolling if Shift is pressed ! modules/graphics/src/main/native-glass/win/ViewContainer.cpp Changeset: 04b694f43543 Author: Kirill Kirichenko Date: 2014-03-07 17:11 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/04b694f43543 RT-36058: segfault when streaming mp3 ! modules/media/src/main/native/gstreamer/plugins/progressbuffer/progressbuffer.c ! modules/media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile Changeset: d3e5f81ba638 Author: David Grieve Date: 2014-03-03 08:56 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d3e5f81ba638 [DOCS-ONLY] RT-36081: fix broken link to javafx.css package-summary.html ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 6b2634b9f3bc Author: David Grieve Date: 2014-03-06 11:06 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6b2634b9f3bc RT-33073: MenuItem is wrapped in a container. Need to return MenuItem as the container's styleable parent ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! modules/controls/src/main/java/javafx/scene/control/ContextMenu.java ! modules/controls/src/main/java/javafx/scene/control/MenuItem.java ! modules/controls/src/main/java/javafx/scene/control/PopupControl.java From David.Hill at Oracle.com Fri Mar 7 09:01:56 2014 From: David.Hill at Oracle.com (David Hill) Date: Fri, 07 Mar 2014 12:01:56 -0500 Subject: Moved samples 3DViewer and Modena from experiments to samples Message-ID: <5319FB84.9050901@Oracle.com> A heads up. I just moved samples 3DViewer and Modena from experiments to samples. If you are going to work on these samples, you may want to sync up soon to avoid later fun. Dave -- David Hill Java Embedded Development "We trained hard, but it seemed that every time we were beginning to form up into teams, we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization." -- Unknown (misattributed to Petronius Arbiter, 210AD). From hang.vo at oracle.com Fri Mar 7 09:03:56 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Mar 2014 17:03:56 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36000 Move 3DViewer and Modena from experiments to samples Message-ID: <20140307170647.93642625E5@hg.openjdk.java.net> Changeset: c859882323e3 Author: ddhill Date: 2014-03-07 11:13 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c859882323e3 RT-36000 Move 3DViewer and Modena from experiments to samples Reviewed-by: kcr - apps/experiments/3DViewer/.idea/.name - apps/experiments/3DViewer/.idea/compiler.xml - apps/experiments/3DViewer/.idea/copyright/profiles_settings.xml - apps/experiments/3DViewer/.idea/encodings.xml - apps/experiments/3DViewer/.idea/misc.xml - apps/experiments/3DViewer/.idea/modules.xml - apps/experiments/3DViewer/.idea/runConfigurations/3DViewer.xml - apps/experiments/3DViewer/.idea/scopes/scope_settings.xml - apps/experiments/3DViewer/.idea/vcs.xml - apps/experiments/3DViewer/3DViewer.iml - apps/experiments/3DViewer/build.gradle - apps/experiments/3DViewer/build.xml - apps/experiments/3DViewer/manifest.mf - apps/experiments/3DViewer/nbproject/build-impl.xml - apps/experiments/3DViewer/nbproject/genfiles.properties - apps/experiments/3DViewer/nbproject/project.properties - apps/experiments/3DViewer/nbproject/project.xml - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/fxml/FXMLExporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/javasource/JavaSourceExporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalConverter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer3D.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/ImporterFinder.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/SmoothingGroups.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Validator.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/dae/DaeImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseParser.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseTokenizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxData.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxLoader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Frame.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Joint.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Loader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MAttribute.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MConnection.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MEnv.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNode.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNodeType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MObject.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MPath.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaAnimationCurveInterpolator.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaGroup.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Xform.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/parser/MParser.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MAttributeAliasType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MBoolType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCharacterMappingType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MComponentListType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCompoundType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MDataType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2Type.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3Type.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MInt3ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MMatrixType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MNurbsCurveType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPointerType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPolyFaceType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MStringType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MAttributeAlias.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MBool.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCharacterMapping.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MComponentList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCompound.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MData.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloatArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt3Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MIntArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MNurbsCurve.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPointer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPolyFace.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MString.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MAttributeAliasImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MBoolImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCharacterMappingImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MComponentListImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCompoundImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MDataImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2Impl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3Impl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MInt3ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MNurbsCurveImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPointerImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPolyFaceImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MStringImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/FloatArrayList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/IntegerArrayList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/MtlReader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjOrPolyObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/PolyObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/AutoScalingGroup.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/FourWayNavControl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Frame.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Jfx3dViewerApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/MainController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/NavigationController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/OldTestViewer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SessionManager.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SettingsController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SubSceneResizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineDisplay.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Xform.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SkinningMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SubdivisionMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/OriginalPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SubdividedPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPolygonMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicSubdivisionBuilder.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/utils3d/DragSupport.java - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/blue.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon2.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/main.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/navigation.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/settings.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/viewer.css - apps/experiments/3DViewer/src/test/java/com/javafx/experiments/exporters/javasource/JavaSourceExporterTestApp.java - apps/experiments/3DViewer/src/test/java/com/javafx/experiments/importers/max/Test.java - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/blob.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/cube.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane-grouped.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/cube.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.png - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane-camera.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/cube.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/plane.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box-raw.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-cube.obj - apps/experiments/Modena/build.gradle - apps/experiments/Modena/build.xml - apps/experiments/Modena/manifest.mf - apps/experiments/Modena/nbproject/build-impl.xml - apps/experiments/Modena/nbproject/genfiles.properties - apps/experiments/Modena/nbproject/project.properties - apps/experiments/Modena/nbproject/project.xml - apps/experiments/Modena/src/main/java/modena/Modena.java - apps/experiments/Modena/src/main/java/modena/SameHeightTestController.java - apps/experiments/Modena/src/main/java/modena/SamplePage.java - apps/experiments/Modena/src/main/java/modena/SamplePageChartHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageHelpers.java - apps/experiments/Modena/src/main/java/modena/SamplePageNavigation.java - apps/experiments/Modena/src/main/java/modena/SamplePageTableHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageTreeHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageTreeTableHelper.java - apps/experiments/Modena/src/main/java/modena/SimpleWindowPage.java - apps/experiments/Modena/src/main/resources/modena/CombinationTest.fxml - apps/experiments/Modena/src/main/resources/modena/SameHeightTest.fxml - apps/experiments/Modena/src/main/resources/modena/ScottSelvia.fxml - apps/experiments/Modena/src/main/resources/modena/TestApp.css - apps/experiments/Modena/src/main/resources/modena/mac-window-frame.png - apps/experiments/Modena/src/main/resources/modena/recorder-icon-48.png - apps/experiments/Modena/src/main/resources/modena/reload_12x14.png - apps/experiments/Modena/src/main/resources/modena/simple-window.fxml - apps/experiments/Modena/src/main/resources/modena/ubuntu-window-frame.png - apps/experiments/Modena/src/main/resources/modena/ui-mosaic.fxml - apps/experiments/Modena/src/main/resources/modena/windows7-window-frame.png - apps/experiments/Modena/src/main/resources/modena/windows8-window-frame.png ! apps/experiments/build.xml + apps/samples/3DViewer/.idea/.name + apps/samples/3DViewer/.idea/compiler.xml + apps/samples/3DViewer/.idea/copyright/profiles_settings.xml + apps/samples/3DViewer/.idea/encodings.xml + apps/samples/3DViewer/.idea/misc.xml + apps/samples/3DViewer/.idea/modules.xml + apps/samples/3DViewer/.idea/runConfigurations/3DViewer.xml + apps/samples/3DViewer/.idea/scopes/scope_settings.xml + apps/samples/3DViewer/.idea/vcs.xml + apps/samples/3DViewer/3DViewer.iml + apps/samples/3DViewer/build.gradle + apps/samples/3DViewer/build.xml + apps/samples/3DViewer/manifest.mf + apps/samples/3DViewer/nbproject/build-impl.xml + apps/samples/3DViewer/nbproject/genfiles.properties + apps/samples/3DViewer/nbproject/project.properties + apps/samples/3DViewer/nbproject/project.xml + apps/samples/3DViewer/src/main/java/com/javafx/experiments/exporters/fxml/FXMLExporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/exporters/javasource/JavaSourceExporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalApp.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalConverter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/Importer.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/Importer3D.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/ImporterFinder.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/SmoothingGroups.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/Validator.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/dae/DaeImporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseParser.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseTokenizer.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxData.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxLoader.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Frame.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Joint.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Loader.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MAttribute.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MConnection.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MEnv.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNode.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNodeType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MObject.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MPath.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaAnimationCurveInterpolator.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaGroup.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaImporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Xform.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/parser/MParser.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MArrayType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MAttributeAliasType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MBoolType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCharacterMappingType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MComponentListType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCompoundType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MDataType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2ArrayType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2Type.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3ArrayType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3Type.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatArrayType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MInt3ArrayType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntArrayType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MMatrixType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MNurbsCurveType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPointerType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPolyFaceType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MStringType.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MArray.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MAttributeAlias.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MBool.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCharacterMapping.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MComponentList.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCompound.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MData.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2Array.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3Array.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloatArray.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt3Array.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MIntArray.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MNurbsCurve.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPointer.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPolyFace.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MString.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MArrayImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MAttributeAliasImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MBoolImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCharacterMappingImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MComponentListImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCompoundImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MDataImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2ArrayImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2Impl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3ArrayImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3Impl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatArrayImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MInt3ArrayImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntArrayImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MNurbsCurveImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPointerImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPolyFaceImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MStringImpl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/obj/FloatArrayList.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/obj/IntegerArrayList.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/obj/MtlReader.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjImporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjOrPolyObjImporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/importers/obj/PolyObjImporter.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/AutoScalingGroup.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/FourWayNavControl.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Frame.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Jfx3dViewerApp.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/MainController.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/NavigationController.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/OldTestViewer.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SessionManager.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SettingsController.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SubSceneResizer.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineDisplay.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Xform.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMesh.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/SkinningMesh.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/SubdivisionMesh.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/OriginalPointArray.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SubdividedPointArray.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPointArray.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPolygonMesh.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicSubdivisionBuilder.java + apps/samples/3DViewer/src/main/java/com/javafx/experiments/utils3d/DragSupport.java + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/blue.jpg + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon.jpg + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon2.jpg + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.mtl + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.obj + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.mtl + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.obj + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.mtl + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.obj + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/main.fxml + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/navigation.fxml + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/settings.fxml + apps/samples/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/viewer.css + apps/samples/3DViewer/src/test/java/com/javafx/experiments/exporters/javasource/JavaSourceExporterTestApp.java + apps/samples/3DViewer/src/test/java/com/javafx/experiments/importers/max/Test.java + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/blob.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/cube.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane-grouped.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/cube.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.png + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane-camera.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane.dae + apps/samples/3DViewer/src/test/resources/com/javafx/importers/obj/cube.obj + apps/samples/3DViewer/src/test/resources/com/javafx/importers/obj/plane.obj + apps/samples/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box-raw.obj + apps/samples/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box.obj + apps/samples/3DViewer/src/test/resources/com/javafx/importers/obj/sub-cube.obj + apps/samples/Modena/build.gradle + apps/samples/Modena/build.xml + apps/samples/Modena/manifest.mf + apps/samples/Modena/nbproject/build-impl.xml + apps/samples/Modena/nbproject/genfiles.properties + apps/samples/Modena/nbproject/project.properties + apps/samples/Modena/nbproject/project.xml + apps/samples/Modena/src/main/java/modena/Modena.java + apps/samples/Modena/src/main/java/modena/SameHeightTestController.java + apps/samples/Modena/src/main/java/modena/SamplePage.java + apps/samples/Modena/src/main/java/modena/SamplePageChartHelper.java + apps/samples/Modena/src/main/java/modena/SamplePageHelpers.java + apps/samples/Modena/src/main/java/modena/SamplePageNavigation.java + apps/samples/Modena/src/main/java/modena/SamplePageTableHelper.java + apps/samples/Modena/src/main/java/modena/SamplePageTreeHelper.java + apps/samples/Modena/src/main/java/modena/SamplePageTreeTableHelper.java + apps/samples/Modena/src/main/java/modena/SimpleWindowPage.java + apps/samples/Modena/src/main/resources/modena/CombinationTest.fxml + apps/samples/Modena/src/main/resources/modena/SameHeightTest.fxml + apps/samples/Modena/src/main/resources/modena/ScottSelvia.fxml + apps/samples/Modena/src/main/resources/modena/TestApp.css + apps/samples/Modena/src/main/resources/modena/mac-window-frame.png + apps/samples/Modena/src/main/resources/modena/recorder-icon-48.png + apps/samples/Modena/src/main/resources/modena/reload_12x14.png + apps/samples/Modena/src/main/resources/modena/simple-window.fxml + apps/samples/Modena/src/main/resources/modena/ubuntu-window-frame.png + apps/samples/Modena/src/main/resources/modena/ui-mosaic.fxml + apps/samples/Modena/src/main/resources/modena/windows7-window-frame.png + apps/samples/Modena/src/main/resources/modena/windows8-window-frame.png ! apps/samples/build.xml From lehmann at media-interactive.de Fri Mar 7 09:27:51 2014 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 7 Mar 2014 18:27:51 +0100 Subject: No split-cursor inside JFXPanel Message-ID: <531A0197.3090608@media-interactive.de> Hi, inside a JFXPanel we don't see the split-cursors (e.g. east/west). This is a known issue: [#RT-26235] SplitPane in JFXPanel: Mouse cursor not changed https://javafx-jira.kenai.com/browse/RT-26235 This affects regular splitpanes as well as custom nodes which just use those cursors. The fix version for this is 9. This is going to be a highly visible issue in our application when we convert more parts to JFXPanels this year. Can this fix be done for one of the upcoming 8uXX releases instead? Thanks, Werner From hang.vo at oracle.com Fri Mar 7 10:03:45 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Mar 2014 18:03:45 +0000 Subject: hg: openjfx/8u-dev/rt: 3 new changesets Message-ID: <20140307180435.CC29B625E8@hg.openjdk.java.net> Changeset: 8388fcf240cd Author: snorthov Date: 2014-03-07 12:56 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8388fcf240cd INTELLIJ ONLY: fix project files for 3DViewer and Modena ! .idea/3DViewer.iml ! .idea/Modena.iml Changeset: 53915091d14c Author: snorthov Date: 2014-03-07 12:57 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/53915091d14c ECLIPSE ONLY: fix project files for 3DViewer and Modena ! apps/experiments/.classpath ! apps/samples/.classpath Changeset: 5a127bee1479 Author: snorthov Date: 2014-03-07 12:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5a127bee1479 INTELLIJ ONLY: remove unused project file (all files are in .idea) - apps/samples/3DViewer/3DViewer.iml From hang.vo at oracle.com Fri Mar 7 10:33:29 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Mar 2014 18:33:29 +0000 Subject: hg: openjfx/8u-dev/rt: Complete work for RT-35243. Cursor now works, rendering works. Message-ID: <20140307183346.D295D625E9@hg.openjdk.java.net> Changeset: 600a63b0323c Author: Lisa.Selle at oracle.com Date: 2014-03-07 13:31 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/600a63b0323c Complete work for RT-35243. Cursor now works, rendering works. Reviewed by dblaukopf ! buildSrc/armv6hf.gradle ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/AcceleratedScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanAcceleratedScreen.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanCursor.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanPlatform.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/dispman/DispmanScreen.java ! modules/graphics/src/main/native-glass/monocle/EGL.c + modules/graphics/src/main/native-glass/monocle/dispman/DispmanAcceleratedScreen.c + modules/graphics/src/main/native-glass/monocle/dispman/DispmanCursor.c + modules/graphics/src/main/native-glass/monocle/dispman/DispmanScreen.c + modules/graphics/src/main/native-glass/monocle/dispman/wrapped_bcm.h From tomas.mikula at gmail.com Fri Mar 7 11:10:10 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Fri, 7 Mar 2014 20:10:10 +0100 Subject: ReactFX, UndoFX, RichTextFX in Sonatype repository Message-ID: Hi all, I just want to quickly inform that all my JavaFX-related projects, ReactFX [1], UndoFX [2] and RichTextFX [3] (previously known as CodeAreaFX), now have snapshots deployed to the Sonatype OSS repository. [1] http://www.reactfx.org [2] https://github.com/TomasMikula/UndoFX [3] https://github.com/TomasMikula/RichTextFX Tomas From tomas.mikula at gmail.com Fri Mar 7 11:26:04 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Fri, 7 Mar 2014 20:26:04 +0100 Subject: [announce] FXMisc: umbrella project for various JavaFX-related projects. Message-ID: I started FXMisc (www.fxmisc.org) to help developers get their project artifacts to Sonatype/Maven repositories under 'org.fxmisc.yourproject' groupId. If you * don't think that your project deserves a dedicated domain name (yet); * find 'org.fxmisc.yourproject' more appealing than 'com.github.yourname.yourproject'; * don't want or cannot contribute your project to another JavaFX-related project, then FXMisc might be for you. Any JavaFX-related project is welcome to join (Scala, Groovy, ... projects are welcome as well). I have put two of my projects under FXMisc so far. Best regards, Tomas From hang.vo at oracle.com Fri Mar 7 11:48:11 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Mar 2014 19:48:11 +0000 Subject: hg: openjfx/8u-dev/rt: [TOYS-ONLY] Add HelloDatePicker to toys Message-ID: <20140307194828.00FDD625EE@hg.openjdk.java.net> Changeset: 12161db2a30a Author: David Grieve Date: 2014-03-07 14:00 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/12161db2a30a [TOYS-ONLY] Add HelloDatePicker to toys + apps/toys/Hello/src/main/java/hello/HelloDatePicker.java From k7 at uw.edu Fri Mar 7 12:49:09 2014 From: k7 at uw.edu (Kay McCormick) Date: Fri, 7 Mar 2014 12:49:09 -0800 Subject: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132 Message-ID: Here is what I see as the relevant portions of the build log. This is beyond my ability to fix easily at this point. I would attach the entire compile log but I compiled with --debug and its 4mb. Let me know if I should provide more information, file a bug, or direct my problem to another forum. Kay 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN/amd64/link.exe'' 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in directwrite.obj 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in directwrite.obj 12:35:16.336 [QUIET] [system.out] Creating library C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib and object C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp 12:35:16.362 [QUIET] [system.out] C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll : fatal error LNK1319: 2 mismatches detected 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: FAILED) 12:35:16.368 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer at 1593948d, org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] 12:35:16.369 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:linkWinFont' 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:linkWinFont FAILED 12:35:16.369 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs. 12:35:16.369 [DEBUG] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 secs 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 mins 29.213 secs From kevin.rushforth at oracle.com Fri Mar 7 13:04:46 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 07 Mar 2014 13:04:46 -0800 Subject: Build Errors on Windows 8.1 / VS2012 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132] In-Reply-To: References: Message-ID: <531A346E.8020300@oracle.com> Hi Kay, It looks like you are using VS2012 not 2010. We build JavaFX with VS 2010, and have some issues with 2012. However, we will need to resolve them at some point. Maybe someone else on the list has had luck building with VS 2012? -- Kevin Kay McCormick wrote: > Here is what I see as the relevant portions of the build log. This is > beyond my ability to fix easily at this point. I would attach the entire > compile log but I compiled with --debug and its 4mb. Let me know if I > should provide more information, file a bug, or direct my problem to > another forum. > > Kay > > 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] > Successfully started process 'command 'C:/Program Files (x86)/Microsoft > Visual Studio 12.0/VC/BIN/amd64/link.exe'' > 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error LNK2038: > mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't > match value 'MD_DynamicRelease' in directwrite.obj > 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error > LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' > doesn't match value 'MD_DynamicRelease' in directwrite.obj > 12:35:16.336 [QUIET] [system.out] Creating library > C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib > and object > C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp > 12:35:16.362 [QUIET] [system.out] > C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll > : fatal error LNK1319: 2 mismatches detected > 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] > Changing state to: FAILED > 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] Process > 'command 'C:/Program Files (x86)/Microsoft Visual Studio > 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: FAILED) > 12:35:16.368 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] > Finished configuring with level: DEBUG, configurers: > [org.gradle.logging.internal.OutputEventRenderer at 1593948d, > org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, > org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] > 12:35:16.369 [DEBUG] > [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] > Finished executing task ':graphics:linkWinFont' > 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] > :graphics:linkWinFont FAILED > 12:35:16.369 [INFO] > [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] > :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs. > 12:35:16.369 [DEBUG] > [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker > [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 secs > 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] > 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED > 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] > 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 mins > 29.213 secs > From kevin.rushforth at oracle.com Fri Mar 7 13:13:31 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 07 Mar 2014 13:13:31 -0800 Subject: Build Errors on Windows 8.1 / VS2013 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132] In-Reply-To: <531A346E.8020300@oracle.com> References: <531A346E.8020300@oracle.com> Message-ID: <531A367B.5030303@oracle.com> Actually, I misread that. You are trying to build with Visual Studio 2013. 2010 == Microsoft Visual Studio 10.0 2012 == Microsoft Visual Studio 11.0 2013 == Microsoft Visual Studio 12.0 You might want to get VS 2010 to build JavaFX. -- Kevin Kevin Rushforth wrote: > Hi Kay, > > It looks like you are using VS2012 not 2010. We build JavaFX with VS > 2010, and have some issues with 2012. However, we will need to resolve > them at some point. > > Maybe someone else on the list has had luck building with VS 2012? > > -- Kevin > > > Kay McCormick wrote: >> Here is what I see as the relevant portions of the build log. This is >> beyond my ability to fix easily at this point. I would attach the entire >> compile log but I compiled with --debug and its 4mb. Let me know if I >> should provide more information, file a bug, or direct my problem to >> another forum. >> >> Kay >> >> 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] >> Successfully started process 'command 'C:/Program Files (x86)/Microsoft >> Visual Studio 12.0/VC/BIN/amd64/link.exe'' >> 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error >> LNK2038: >> mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't >> match value 'MD_DynamicRelease' in directwrite.obj >> 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error >> LNK2038: mismatch detected for 'RuntimeLibrary': value >> 'MT_StaticRelease' >> doesn't match value 'MD_DynamicRelease' in directwrite.obj >> 12:35:16.336 [QUIET] [system.out] Creating library >> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib >> >> and object >> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp >> >> 12:35:16.362 [QUIET] [system.out] >> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll >> >> : fatal error LNK1319: 2 mismatches detected >> 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] >> Changing state to: FAILED >> 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] >> Process >> 'command 'C:/Program Files (x86)/Microsoft Visual Studio >> 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: >> FAILED) >> 12:35:16.368 [DEBUG] >> [org.gradle.logging.internal.DefaultLoggingConfigurer] >> Finished configuring with level: DEBUG, configurers: >> [org.gradle.logging.internal.OutputEventRenderer at 1593948d, >> org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, >> org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] >> 12:35:16.369 [DEBUG] >> [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] >> Finished executing task ':graphics:linkWinFont' >> 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] >> :graphics:linkWinFont FAILED >> 12:35:16.369 [INFO] >> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] >> :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs. >> 12:35:16.369 [DEBUG] >> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker >> [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 >> secs >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 >> mins >> 29.213 secs >> From k7 at uw.edu Fri Mar 7 13:35:21 2014 From: k7 at uw.edu (Kay McCormick) Date: Fri, 7 Mar 2014 13:35:21 -0800 Subject: Build Errors on Windows 8.1 / VS2012 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132] In-Reply-To: <531A346E.8020300@oracle.com> References: <531A346E.8020300@oracle.com> Message-ID: Great catch - I have both IDEs installed. Prior to installing VS2010, I had changed rt/buildSrc/genVSproperties.bat to reference VS120COMNTOOLS instead of VS100COMNTOOLS and forgot to back out that change. I did have to make some changes to win.gradle to adjust the windows sdk tool paths: Further, VS2010 express failed to compile, so I installed Pro. --- a/buildSrc/win.gradle Thu Mar 06 17:50:58 2014 -0500 +++ b/buildSrc/win.gradle Fri Mar 07 21:32:49 2014 +0000 @@ -131,10 +131,18 @@ : "$WINDOWS_VS_VSINSTALLDIR/VC/BIN") def compiler = IS_COMPILE_PARFAIT ? "cl.exe" : cygpath("$msvcBinDir/cl.exe") def linker = IS_COMPILE_PARFAIT ? "link.exe" : cygpath("$msvcBinDir/link.exe") -ext.RC = cygpath("$WINDOWS_SDK_DIR/Bin/RC.Exe") -def rcCompiler = cygpath("$WINDOWS_SDK_DIR/Bin/RC.Exe") +ext.RC = (IS_64 + ? cygpath("$WINDOWS_SDK_DIR/Bin/x64/RC.Exe") + : cygpath("$WINDOWS_SDK_DIR/Bin/x86/RC.Exe")) +def rcCompiler = (IS_64 + ? cygpath("$WINDOWS_SDK_DIR/Bin/x64/RC.Exe") + : cygpath("$WINDOWS_SDK_DIR/Bin/x86/RC.Exe")) + ext.FXC = cygpath("$WINDOWS_DXSDK_DIR/utilities/bin/x86/fxc.exe") -ext.MC = cygpath("$WINDOWS_SDK_DIR/Bin/mt.exe") +ext.MC = (IS_64 + ? cygpath("$WINDOWS_SDK_DIR/Bin/x64/mt.exe") + : cygpath("$WINDOWS_SDK_DIR/Bin/x86/mt.exe")) + // This next line is based on a line in the ant build scripts, but doesn't seem to point to the right place //ext.MSVCR = cygpath("${WINDOWS_VS_MSVCDIR}/redist/${IS_64 ? 'x64' : 'x86'}/Microsoft.VC${WINDOWS_VS_VER}.CRT/msvcr${WINDOWS_VS_VER}.dll") On Fri, Mar 7, 2014 at 1:04 PM, Kevin Rushforth wrote: > Hi Kay, > > It looks like you are using VS2012 not 2010. We build JavaFX with VS 2010, > and have some issues with 2012. However, we will need to resolve them at > some point. > > Maybe someone else on the list has had luck building with VS 2012? > > -- Kevin > > > Kay McCormick wrote: > >> Here is what I see as the relevant portions of the build log. This is >> beyond my ability to fix easily at this point. I would attach the entire >> compile log but I compiled with --debug and its 4mb. Let me know if I >> should provide more information, file a bug, or direct my problem to >> another forum. >> >> Kay >> >> 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] >> Successfully started process 'command 'C:/Program Files (x86)/Microsoft >> Visual Studio 12.0/VC/BIN/amd64/link.exe'' >> 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error LNK2038: >> mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't >> match value 'MD_DynamicRelease' in directwrite.obj >> 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error >> LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' >> doesn't match value 'MD_DynamicRelease' in directwrite.obj >> 12:35:16.336 [QUIET] [system.out] Creating library >> C:\Users\kay\Documents\current\openjfx\rt\modules\ >> graphics\build\libs\font\win\javafx_font.lib >> and object >> C:\Users\kay\Documents\current\openjfx\rt\modules\ >> graphics\build\libs\font\win\javafx_font.exp >> 12:35:16.362 [QUIET] [system.out] >> C:\Users\kay\Documents\current\openjfx\rt\modules\ >> graphics\build\libs\font\win\javafx_font.dll >> : fatal error LNK1319: 2 mismatches detected >> 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] >> Changing state to: FAILED >> 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] >> Process >> 'command 'C:/Program Files (x86)/Microsoft Visual Studio >> 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: FAILED) >> 12:35:16.368 [DEBUG] [org.gradle.logging.internal. >> DefaultLoggingConfigurer] >> Finished configuring with level: DEBUG, configurers: >> [org.gradle.logging.internal.OutputEventRenderer at 1593948d, >> org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, >> org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] >> 12:35:16.369 [DEBUG] >> [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] >> Finished executing task ':graphics:linkWinFont' >> 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] >> :graphics:linkWinFont FAILED >> 12:35:16.369 [INFO] >> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] >> :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs. >> 12:35:16.369 [DEBUG] >> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker >> [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 secs >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 mins >> 29.213 secs >> >> > From k7 at uw.edu Sat Mar 8 06:15:27 2014 From: k7 at uw.edu (Kay McCormick) Date: Fri, 7 Mar 2014 22:15:27 -0800 Subject: Building and using a debug build of openjfx as the default JavaFX for development Message-ID: Hi everyone, I've successfully built openjfx. My overall goal is to be able to step through the openjfx code. I have the Oracle JDK installed - do I need to use OpenJDK instead? How would I go about making sure the build produced has debug information and using it for javafx application development. I'm trying to make my way through this process but I don't have all the pieces put together yet, and I'd appreciate any tips that can be offered. Thanks! Kay From jeff at reportmill.com Fri Mar 7 22:23:29 2014 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 7 Mar 2014 16:23:29 -0600 Subject: SnapCode JavaFX Fun Message-ID: <65D4F71F-6FD4-42AD-8B49-F284DAD3190B@reportmill.com> More friday night light posting - I updated SnapCode this week with some fun features: - Mouse/Keyboard sensing (isMousePressed, isKeyPressed) - Actor pen drawing (penDown, penUp, setPenColor) - Added Code Completion popup panel to visual code editor Check out the interactive animations in this posting: http://www.reportmill.com/snap/gallery/MouseKeyboard/ jeff From John_Smith at symantec.com Sun Mar 9 21:41:36 2014 From: John_Smith at symantec.com (John Smith) Date: Sun, 9 Mar 2014 14:41:36 -0700 Subject: Building and using a debug build of openjfx as the default JavaFX for development In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221691A276A8@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> The easiest thing to do to debug JavaFX is to use a prebuilt JDK 8+ and attach the sources from the JDK to your IDE. Then you can set break-points in the JavaFX source and debug it (i.e. you don't need to checkout and build openjfx at all). This works fine if all you want to do is step through the JavaFX source in the context of debugging your application (I think from your question this is actually what you want). For instructions on how to do this with Intellij Idea, see http://stackoverflow.com/questions/13407017/javafx-source-code-not-showing-in-intellij-idea. I think something like e(fx)clipse will do this step for you automatically (not sure about NetBeans). There is really little difference between the openjfx code and the source shipped with JDK 8. When you download JDK 8 (from https://jdk8.java.net/download.html) you are receiving a pre-built tagged snapshot of software built almost entirely from the openjdk/openjfx codebase. Of course, if you are actually developing and modifying the openjfx source, then the above won't work because your modified openjfx source would get out of sync with the binary JDK8 code. In this case, you would need to check-out the openjfx source, make any modifications you want, build it and then when you run your application, ensure that you run it against your custom openjfx build and have the modified source attached to your application's IDE project (similar to the instructions in the stackoverflow question I linked). JavaFX has both native and Java components. Debugging through the native components as well as the Java components is a more complex task. Perhaps there is more information on debugging openjfx on the openjfx wiki: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX But the wiki is currently offline, so I can't check it at the moment. John -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kay McCormick Sent: Friday, March 07, 2014 10:15 PM To: openjfx-dev at openjdk.java.net Subject: Building and using a debug build of openjfx as the default JavaFX for development Hi everyone, I've successfully built openjfx. My overall goal is to be able to step through the openjfx code. I have the Oracle JDK installed - do I need to use OpenJDK instead? How would I go about making sure the build produced has debug information and using it for javafx application development. I'm trying to make my way through this process but I don't have all the pieces put together yet, and I'd appreciate any tips that can be offered. Thanks! Kay From felipe.heidrich at oracle.com Mon Mar 10 15:19:29 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Mon, 10 Mar 2014 08:19:29 -0700 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: Thank you Rob, It would be interesting to test against a DirectWrite app. I?m not sure if you have VS, but if you do it should be simple to modify the Simple Text tab in the DirectWrite Hello World Sample to use the same font and text: http://msdn.microsoft.com/en-us/library/windows/desktop/dd368048(v=vs.85).aspx I have attached your screenshot to https://javafx-jira.kenai.com/browse/RT-36146 for now so it doesn?t get lost. Regards Felipe On Mar 7, 2014, at 1:41 AM, Robert Fisher wrote: > Hi Felipe, Hi Phil, > > Thanks for the tips. Phil, your program yielded the following output: > > Text-specific antialiasing enable key : LCD HRGB antialiasing text mode > Text-specific LCD contrast key : 120 > > I tried all of the 5 settings that Felix mentioned. Here are my results for the default font (Segoe UI 9pt, black): > > http://i.imgur.com/45FewcL.png > > The difference in quality between the JavaFX images and the rest is too great to be chalked up to personal preferences. Whether it's the fault of JavaFX, or the native rendering mechanism being used, or my own configuration is another question. > > Cheers, > Rob > > From steve.x.northover at oracle.com Mon Mar 10 16:46:02 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 10 Mar 2014 12:46:02 -0400 Subject: Building and using a debug build of openjfx as the default JavaFX for development In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221691A276A8@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <411E73D23DEC4C46BA48F2B6D8BF3D221691A276A8@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <531DEC4A.3040502@oracle.com> Thanks John. See also: https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE There are several tricky issues around building, running and debugging OpenJFX from within an IDE. The most important thing is to run the code in the IDE rather than jfxrt.jar and the shared libraries that come with Java 8. All of this is described in the link. Steve On 2014-03-09 5:41 PM, John Smith wrote: > The easiest thing to do to debug JavaFX is to use a prebuilt JDK 8+ and attach the sources from the JDK to your IDE. > Then you can set break-points in the JavaFX source and debug it (i.e. you don't need to checkout and build openjfx at all). > This works fine if all you want to do is step through the JavaFX source in the context of debugging your application (I think from your question this is actually what you want). > For instructions on how to do this with Intellij Idea, see http://stackoverflow.com/questions/13407017/javafx-source-code-not-showing-in-intellij-idea. I think something like e(fx)clipse will do this step for you automatically (not sure about NetBeans). > There is really little difference between the openjfx code and the source shipped with JDK 8. > When you download JDK 8 (from https://jdk8.java.net/download.html) you are receiving a pre-built tagged snapshot of software built almost entirely from the openjdk/openjfx codebase. > > Of course, if you are actually developing and modifying the openjfx source, then the above won't work because your modified openjfx source would get out of sync with the binary JDK8 code. In this case, you would need to check-out the openjfx source, make any modifications you want, build it and then when you run your application, ensure that you run it against your custom openjfx build and have the modified source attached to your application's IDE project (similar to the instructions in the stackoverflow question I linked). JavaFX has both native and Java components. Debugging through the native components as well as the Java components is a more complex task. > > Perhaps there is more information on debugging openjfx on the openjfx wiki: > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX > But the wiki is currently offline, so I can't check it at the moment. > > John > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kay McCormick > Sent: Friday, March 07, 2014 10:15 PM > To: openjfx-dev at openjdk.java.net > Subject: Building and using a debug build of openjfx as the default JavaFX for development > > Hi everyone, > > I've successfully built openjfx. My overall goal is to be able to step through the openjfx code. I have the Oracle JDK installed - do I need to use OpenJDK instead? How would I go about making sure the build produced has debug information and using it for javafx application development. I'm trying to make my way through this process but I don't have all the pieces put together yet, and I'd appreciate any tips that can be offered. > > Thanks! > > Kay From rfisher at tesis.de Mon Mar 10 17:06:44 2014 From: rfisher at tesis.de (Robert Fisher) Date: Mon, 10 Mar 2014 18:06:44 +0100 Subject: AW: Poor font rendering.. In-Reply-To: References: Message-ID: Hi Felipe, I've added the results from the DirectWrite 'Hello World' sample to the image: http://i.imgur.com/CGyckge.png Is this supposed to be the benchmark for how black text should look? In my opinion the text in Chrome / Firefox / Eclipse is a lot clearer and sharper when viewed at 100%. Cheers, Rob From felipe.heidrich at oracle.com Mon Mar 10 17:45:57 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Mon, 10 Mar 2014 10:45:57 -0700 Subject: Poor font rendering.. In-Reply-To: References: Message-ID: <0D405A91-6E22-4BB2-8C53-E66BBF6B41D3@oracle.com> Thank you Rob, DirectWrite is the engine JavaFX uses to produces glyph masks (white on black), therefore JavaFX text should resemble that of DirectWrite (it is not exactly the same, as JavaFX does its own color blending and gamma correction). We decided to use DirectWrite for JavaFX because it is the most modern native technology on Windows that we can use. In particular, we were interested on sub pixel positioned text. GDI, for example, all glyph positioning are expressed as integer, and glyphs are (usually) aggressively hinted. Interesting FIreFox had all the same trouble when they switched from GDI to DirectWrite. Please read https://blog.mozilla.org/nattokirai/2011/08/11/directwrite-text-rendering-in-firefox-6/ JavaFX always uses DirectWrite natural mode rendering. We too can provided switches for GDI Classic rendering mode, cleartype level, enhanced contrast, gamma, etc. It is all defined here http://msdn.microsoft.com/en-us/library/windows/desktop/dd371285(v=vs.85).aspx Maybe that would help ? Notes: SWT uses GDI to render text (I know, I implemented it). JavaFX with -Djavafx.text=t2k uses GDI to render LCD text, SWT and JavaFX with -Djavafx.text=t2k are not same, but similar, likely again because JavaFX does its own color blending and gamma correction. Felipe On Mar 10, 2014, at 10:06 AM, Robert Fisher wrote: > Hi Felipe, > > I've added the results from the DirectWrite 'Hello World' sample to the image: > > http://i.imgur.com/CGyckge.png > > Is this supposed to be the benchmark for how black text should look? In my opinion the text in Chrome / Firefox / Eclipse is a lot clearer and sharper when viewed at 100%. > > Cheers, > Rob > > From hang.vo at oracle.com Tue Mar 11 02:20:24 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 02:20:24 +0000 Subject: hg: openjfx/8u-dev/rt: 11 new changesets Message-ID: <201403110221.s2B2LbWU027112@aojmv0008> Changeset: 81208afdb29a Author: hudson Date: 2014-03-05 08:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/81208afdb29a Added tag 8u20-b04 for changeset 4742b5a6eb9b ! .hgtags Changeset: 39856b5ce3f7 Author: kcr Date: 2014-03-07 13:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/39856b5ce3f7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8u/master/jfx/rt Changeset: 77d9f9491a0e Author: kcr Date: 2014-03-07 16:10 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/77d9f9491a0e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8u/master/jfx/rt - apps/experiments/3DViewer/.idea/.name - apps/experiments/3DViewer/.idea/compiler.xml - apps/experiments/3DViewer/.idea/copyright/profiles_settings.xml - apps/experiments/3DViewer/.idea/encodings.xml - apps/experiments/3DViewer/.idea/misc.xml - apps/experiments/3DViewer/.idea/modules.xml - apps/experiments/3DViewer/.idea/runConfigurations/3DViewer.xml - apps/experiments/3DViewer/.idea/scopes/scope_settings.xml - apps/experiments/3DViewer/.idea/vcs.xml - apps/experiments/3DViewer/3DViewer.iml - apps/experiments/3DViewer/build.gradle - apps/experiments/3DViewer/build.xml - apps/experiments/3DViewer/manifest.mf - apps/experiments/3DViewer/nbproject/build-impl.xml - apps/experiments/3DViewer/nbproject/genfiles.properties - apps/experiments/3DViewer/nbproject/project.properties - apps/experiments/3DViewer/nbproject/project.xml - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/fxml/FXMLExporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/javasource/JavaSourceExporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalConverter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer3D.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/ImporterFinder.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/SmoothingGroups.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Validator.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/dae/DaeImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseParser.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseTokenizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxData.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxLoader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Frame.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Joint.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Loader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MAttribute.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MConnection.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MEnv.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNode.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNodeType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MObject.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MPath.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaAnimationCurveInterpolator.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaGroup.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Xform.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/parser/MParser.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MAttributeAliasType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MBoolType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCharacterMappingType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MComponentListType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCompoundType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MDataType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2Type.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3Type.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MInt3ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MMatrixType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MNurbsCurveType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPointerType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPolyFaceType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MStringType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MAttributeAlias.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MBool.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCharacterMapping.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MComponentList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCompound.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MData.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloatArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt3Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MIntArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MNurbsCurve.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPointer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPolyFace.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MString.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MAttributeAliasImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MBoolImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCharacterMappingImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MComponentListImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCompoundImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MDataImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2Impl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3Impl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MInt3ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MNurbsCurveImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPointerImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPolyFaceImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MStringImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/FloatArrayList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/IntegerArrayList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/MtlReader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjOrPolyObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/PolyObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/AutoScalingGroup.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/FourWayNavControl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Frame.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Jfx3dViewerApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/MainController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/NavigationController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/OldTestViewer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SessionManager.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SettingsController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SubSceneResizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineDisplay.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Xform.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SkinningMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SubdivisionMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/OriginalPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SubdividedPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPolygonMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicSubdivisionBuilder.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/utils3d/DragSupport.java - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/blue.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon2.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/main.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/navigation.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/settings.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/viewer.css - apps/experiments/3DViewer/src/test/java/com/javafx/experiments/exporters/javasource/JavaSourceExporterTestApp.java - apps/experiments/3DViewer/src/test/java/com/javafx/experiments/importers/max/Test.java - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/blob.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/cube.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane-grouped.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/cube.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.png - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane-camera.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/cube.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/plane.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box-raw.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-cube.obj - apps/experiments/Modena/build.gradle - apps/experiments/Modena/build.xml - apps/experiments/Modena/manifest.mf - apps/experiments/Modena/nbproject/build-impl.xml - apps/experiments/Modena/nbproject/genfiles.properties - apps/experiments/Modena/nbproject/project.properties - apps/experiments/Modena/nbproject/project.xml - apps/experiments/Modena/src/main/java/modena/Modena.java - apps/experiments/Modena/src/main/java/modena/SameHeightTestController.java - apps/experiments/Modena/src/main/java/modena/SamplePage.java - apps/experiments/Modena/src/main/java/modena/SamplePageChartHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageHelpers.java - apps/experiments/Modena/src/main/java/modena/SamplePageNavigation.java - apps/experiments/Modena/src/main/java/modena/SamplePageTableHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageTreeHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageTreeTableHelper.java - apps/experiments/Modena/src/main/java/modena/SimpleWindowPage.java - apps/experiments/Modena/src/main/resources/modena/CombinationTest.fxml - apps/experiments/Modena/src/main/resources/modena/SameHeightTest.fxml - apps/experiments/Modena/src/main/resources/modena/ScottSelvia.fxml - apps/experiments/Modena/src/main/resources/modena/TestApp.css - apps/experiments/Modena/src/main/resources/modena/mac-window-frame.png - apps/experiments/Modena/src/main/resources/modena/recorder-icon-48.png - apps/experiments/Modena/src/main/resources/modena/reload_12x14.png - apps/experiments/Modena/src/main/resources/modena/simple-window.fxml - apps/experiments/Modena/src/main/resources/modena/ubuntu-window-frame.png - apps/experiments/Modena/src/main/resources/modena/ui-mosaic.fxml - apps/experiments/Modena/src/main/resources/modena/windows7-window-frame.png - apps/experiments/Modena/src/main/resources/modena/windows8-window-frame.png Changeset: 4ef7286b9266 Author: hudson Date: 2014-02-28 07:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4ef7286b9266 Added tag 8.0-b130 for changeset b8d6295f4672 ! .hgtags Changeset: e2fd0ac9762b Author: hudson Date: 2014-03-01 09:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e2fd0ac9762b Added tag 8.0-b131 for changeset 4ef7286b9266 ! .hgtags Changeset: f89b7dc932af Author: hudson Date: 2014-03-04 10:36 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f89b7dc932af Added tag 8.0-b132 for changeset e2fd0ac9762b ! .hgtags Changeset: 49a29c9d82a9 Author: kcr Date: 2014-03-07 16:20 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/49a29c9d82a9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! .hgtags - apps/experiments/3DViewer/.classpath - apps/experiments/3DViewer/.idea/.name - apps/experiments/3DViewer/.idea/compiler.xml - apps/experiments/3DViewer/.idea/copyright/profiles_settings.xml - apps/experiments/3DViewer/.idea/encodings.xml - apps/experiments/3DViewer/.idea/misc.xml - apps/experiments/3DViewer/.idea/modules.xml - apps/experiments/3DViewer/.idea/runConfigurations/3DViewer.xml - apps/experiments/3DViewer/.idea/scopes/scope_settings.xml - apps/experiments/3DViewer/.idea/vcs.xml - apps/experiments/3DViewer/.project - apps/experiments/3DViewer/3DViewer.iml - apps/experiments/3DViewer/build.gradle - apps/experiments/3DViewer/build.xml - apps/experiments/3DViewer/manifest.mf - apps/experiments/3DViewer/nbproject/build-impl.xml - apps/experiments/3DViewer/nbproject/genfiles.properties - apps/experiments/3DViewer/nbproject/project.properties - apps/experiments/3DViewer/nbproject/project.xml - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/fxml/FXMLExporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/javasource/JavaSourceExporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalConverter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Importer3D.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/SmoothingGroups.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Validator.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/dae/DaeImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseParser.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxAseTokenizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxData.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/max/MaxLoader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Frame.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Joint.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Loader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MAttribute.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MConnection.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MEnv.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNode.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MNodeType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MObject.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MPath.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaAnimationCurveInterpolator.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaGroup.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Xform.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/parser/MParser.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MAttributeAliasType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MBoolType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCharacterMappingType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MComponentListType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MCompoundType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MDataType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat2Type.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloat3Type.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MFloatType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MInt3ArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntArrayType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MIntType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MMatrixType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MNurbsCurveType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPointerType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MPolyFaceType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/types/MStringType.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MAttributeAlias.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MBool.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCharacterMapping.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MComponentList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MCompound.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MData.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat2Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloat3Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MFloatArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MInt3Array.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MIntArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MNurbsCurve.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPointer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MPolyFace.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/MString.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MAttributeAliasImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MBoolImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCharacterMappingImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MComponentListImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MCompoundImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MDataImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat2Impl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloat3Impl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MFloatImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MInt3ArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntArrayImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MIntImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MNurbsCurveImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPointerImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MPolyFaceImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/values/impl/MStringImpl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/FloatArrayList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/IntegerArrayList.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/MtlReader.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/ObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/obj/PolyObjImporter.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/AutoScalingGroup.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/FourWayNavControl.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Frame.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Jfx3dViewerApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/MainController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/NavigationController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/OldTestViewer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SessionManager.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SettingsController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SubSceneResizer.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineDisplay.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/Xform.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SkinningMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/SubdivisionMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/OriginalPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SubdividedPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPointArray.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicPolygonMesh.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/symbolic/SymbolicSubdivisionBuilder.java - apps/experiments/3DViewer/src/main/java/com/javafx/experiments/utils3d/DragSupport.java - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/blue.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/carbon2.jpg - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large-yUp.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here-large.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.mtl - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/drop-here.obj - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/main.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/navigation.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/settings.fxml - apps/experiments/3DViewer/src/main/resources/com/javafx/experiments/jfx3dviewer/viewer.css - apps/experiments/3DViewer/src/test/java/com/javafx/experiments/exporters/javasource/JavaSourceExporterTestApp.java - apps/experiments/3DViewer/src/test/java/com/javafx/experiments/importers/max/Test.java - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/blob.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/cube.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane-grouped.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-cheetah3d/plane.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/cube.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/duke.png - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane-camera.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/dae/test-data-maya/plane.dae - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/cube.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/plane.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box-raw.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-box.obj - apps/experiments/3DViewer/src/test/resources/com/javafx/importers/obj/sub-cube.obj - apps/experiments/Modena/.classpath - apps/experiments/Modena/.project - apps/experiments/Modena/build.gradle - apps/experiments/Modena/build.xml - apps/experiments/Modena/manifest.mf - apps/experiments/Modena/nbproject/build-impl.xml - apps/experiments/Modena/nbproject/genfiles.properties - apps/experiments/Modena/nbproject/project.properties - apps/experiments/Modena/nbproject/project.xml - apps/experiments/Modena/src/main/java/modena/Modena.java - apps/experiments/Modena/src/main/java/modena/SameHeightTestController.java - apps/experiments/Modena/src/main/java/modena/SamplePage.java - apps/experiments/Modena/src/main/java/modena/SamplePageChartHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageHelpers.java - apps/experiments/Modena/src/main/java/modena/SamplePageNavigation.java - apps/experiments/Modena/src/main/java/modena/SamplePageTableHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageTreeHelper.java - apps/experiments/Modena/src/main/java/modena/SamplePageTreeTableHelper.java - apps/experiments/Modena/src/main/java/modena/SimpleWindowPage.java - apps/experiments/Modena/src/main/resources/modena/CombinationTest.fxml - apps/experiments/Modena/src/main/resources/modena/SameHeightTest.fxml - apps/experiments/Modena/src/main/resources/modena/ScottSelvia.fxml - apps/experiments/Modena/src/main/resources/modena/TestApp.css - apps/experiments/Modena/src/main/resources/modena/mac-window-frame.png - apps/experiments/Modena/src/main/resources/modena/recorder-icon-48.png - apps/experiments/Modena/src/main/resources/modena/reload_12x14.png - apps/experiments/Modena/src/main/resources/modena/simple-window.fxml - apps/experiments/Modena/src/main/resources/modena/ubuntu-window-frame.png - apps/experiments/Modena/src/main/resources/modena/ui-mosaic.fxml - apps/experiments/Modena/src/main/resources/modena/windows7-window-frame.png - apps/experiments/Modena/src/main/resources/modena/windows8-window-frame.png - apps/samples/Ensemble8/.classpath - apps/samples/Ensemble8/.project - modules/base/src/main/java/javafx/collections/ObservableList.java - modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/Bundler.java - modules/fxpackager/src/main/man/ja_JP.UTF-8/html/javafxpackager.html - modules/fxpackager/src/main/resources/resources/web-files/dtjava.js - modules/fxpackager/src/main/resources/resources/web-files/error.png - modules/fxpackager/src/main/resources/resources/web-files/get_java.png - modules/fxpackager/src/main/resources/resources/web-files/get_javafx.png - modules/fxpackager/src/main/resources/resources/web-files/javafx-chrome.png - modules/fxpackager/src/main/resources/resources/web-files/javafx-loading-100x100.gif - modules/fxpackager/src/main/resources/resources/web-files/javafx-loading-25x25.gif - modules/fxpackager/src/main/resources/resources/web-files/upgrade_java.png - modules/fxpackager/src/main/resources/resources/web-files/upgrade_javafx.png - modules/fxpackager/test/main/java/com/sun/javafx/tools/ant/FXJarTest.java - modules/fxpackager/test/main/java/com/sun/javafx/tools/packager/PackagerLibTest.java - modules/fxpackager/test/main/java/com/sun/javafx/tools/packager/bundlers/BundleParamsTest.java - modules/fxpackager/test/main/java/com/sun/javafx/tools/packager/bundlers/WinMsiBundlerTest.java - modules/graphics/src/main/java/com/sun/javafx/css/parser/SimpleRecognizer.java - modules/graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphInfo.java - modules/graphics/src/main/java/com/sun/scenario/effect/impl/state/LinearConvolvePeer.java - modules/graphics/src/main/java/com/sun/scenario/effect/impl/state/LinearConvolveShadowPeer.java Changeset: f00f65d8ca59 Author: flar Date: 2014-03-07 16:43 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f00f65d8ca59 NB-only: Fix source paths for NetBeans graphics project Reviewed by: Kevin, Steve ! netbeans/graphics/nbproject/project.properties ! netbeans/graphics/nbproject/project.xml Changeset: 194c499d0a12 Author: David Grieve Date: 2014-03-10 16:47 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/194c499d0a12 [TOYS-ONLY] fix copyright date in HelloDatePicker ! apps/toys/Hello/src/main/java/hello/HelloDatePicker.java Changeset: afbaf61f1cdb Author: leifs Date: 2014-03-10 15:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/afbaf61f1cdb RT-36071: [TextArea] TextArea not showing ScrollBar until it gets focus ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java Changeset: a64b40f8618b Author: snorthov Date: 2014-03-10 19:31 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a64b40f8618b NETBEANS ONLY: Fix project files to compile in the IDE ! netbeans/graphics/nbproject/build-impl.xml ! netbeans/graphics/nbproject/genfiles.properties ! netbeans/graphics/nbproject/project.properties ! netbeans/graphics/nbproject/project.xml From artem.ananiev at oracle.com Tue Mar 11 04:06:26 2014 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 11 Mar 2014 08:06:26 +0400 Subject: Build Errors on Windows 8.1 / VS2012 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132] In-Reply-To: <531A346E.8020300@oracle.com> References: <531A346E.8020300@oracle.com> Message-ID: <531E8BC2.5010707@oracle.com> On 3/8/2014 1:04 AM, Kevin Rushforth wrote: > Hi Kay, > > It looks like you are using VS2012 not 2010. We build JavaFX with VS > 2010, and have some issues with 2012. However, we will need to resolve > them at some point. > > Maybe someone else on the list has had luck building with VS 2012? I was able to build FX with VS 2012 some time ago. The changes were mostly cosmetic (caused by different Visual Studio and Platform SDK directory layouts), except static C++ runtime linkage. And, of course, FX should be aligned with JDK, which is shipped with VS 2010 runtime (will it be changed in JDK9?), otherwise FX will have to ship with its own runtime libraries. Thanks, Artem > -- Kevin > > > Kay McCormick wrote: >> Here is what I see as the relevant portions of the build log. This is >> beyond my ability to fix easily at this point. I would attach the entire >> compile log but I compiled with --debug and its 4mb. Let me know if I >> should provide more information, file a bug, or direct my problem to >> another forum. >> >> Kay >> >> 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] >> Successfully started process 'command 'C:/Program Files (x86)/Microsoft >> Visual Studio 12.0/VC/BIN/amd64/link.exe'' >> 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error >> LNK2038: >> mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't >> match value 'MD_DynamicRelease' in directwrite.obj >> 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error >> LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' >> doesn't match value 'MD_DynamicRelease' in directwrite.obj >> 12:35:16.336 [QUIET] [system.out] Creating library >> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib >> >> and object >> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp >> >> 12:35:16.362 [QUIET] [system.out] >> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll >> >> : fatal error LNK1319: 2 mismatches detected >> 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] >> Changing state to: FAILED >> 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] >> Process >> 'command 'C:/Program Files (x86)/Microsoft Visual Studio >> 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: >> FAILED) >> 12:35:16.368 [DEBUG] >> [org.gradle.logging.internal.DefaultLoggingConfigurer] >> Finished configuring with level: DEBUG, configurers: >> [org.gradle.logging.internal.OutputEventRenderer at 1593948d, >> org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, >> org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] >> 12:35:16.369 [DEBUG] >> [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] >> Finished executing task ':graphics:linkWinFont' >> 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] >> :graphics:linkWinFont FAILED >> 12:35:16.369 [INFO] >> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] >> :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs. >> 12:35:16.369 [DEBUG] >> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker >> [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 secs >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 >> mins >> 29.213 secs From rfisher at tesis.de Tue Mar 11 08:57:07 2014 From: rfisher at tesis.de (Robert Fisher) Date: Tue, 11 Mar 2014 09:57:07 +0100 Subject: Poor font rendering.. Message-ID: <5f466793-d3db-4160-85c4-e5b6632768d2@tesis.de> Hi Felipe, thanks for the detailed reply, that Firefox blog post is interesting. I guess sub-pixel positioning is the crucial point here. If a black, 1-pixel wide vertical stroke is positioned between two pixels, you'll get a dimmer, 2-pixel wide stroke instead. Suppose I want to see what GDI, SWT-like text looks like in JavaFX. I should set -Djavafx.text=t2k. But looking at the picture (http://i.imgur.com/CGyckge.png) it still seems there is some additional blurring in JavaFX. Some additional sub-pixel positioning logic, perhaps? But I concede that there has to be a compromise between positioning and 'vibrancy' for small text. Cheers, Rob -----Urspr?ngliche Nachricht----- Von: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] Im Auftrag von Felipe Heidrich Gesendet: Montag, 10. M?rz 2014 18:46 An: OpenJFX Mailing List Betreff: Re: Poor font rendering.. Thank you Rob, DirectWrite is the engine JavaFX uses to produces glyph masks (white on black), therefore JavaFX text should resemble that of DirectWrite (it is not exactly the same, as JavaFX does its own color blending and gamma correction). We decided to use DirectWrite for JavaFX because it is the most modern native technology on Windows that we can use. In particular, we were interested on sub pixel positioned text. GDI, for example, all glyph positioning are expressed as integer, and glyphs are (usually) aggressively hinted. Interesting FIreFox had all the same trouble when they switched from GDI to DirectWrite. Please read https://blog.mozilla.org/nattokirai/2011/08/11/directwrite-text-rendering-in-firefox-6/ JavaFX always uses DirectWrite natural mode rendering. We too can provided switches for GDI Classic rendering mode, cleartype level, enhanced contrast, gamma, etc. It is all defined here http://msdn.microsoft.com/en-us/library/windows/desktop/dd371285(v=vs.85).aspx Maybe that would help ? Notes: SWT uses GDI to render text (I know, I implemented it). JavaFX with -Djavafx.text=t2k uses GDI to render LCD text, SWT and JavaFX with -Djavafx.text=t2k are not same, but similar, likely again because JavaFX does its own color blending and gamma correction. Felipe From kevin.rushforth at oracle.com Tue Mar 11 12:03:57 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Mar 2014 05:03:57 -0700 Subject: Build Errors on Windows 8.1 / VS2012 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132] In-Reply-To: <531E8BC2.5010707@oracle.com> References: <531A346E.8020300@oracle.com> <531E8BC2.5010707@oracle.com> Message-ID: <531EFBAD.7040303@oracle.com> Thanks, Artem. Yes, the version of Visual Studio that we build JavaFX with must be tied to that of the JDK. VS 2010 SP1 for JDK 8 and 8u. Probably VS 2013 for JDK 9. Prior to that, we may want to fix any issues that prevent developers from building on VS 2012 or 2013. -- Kevin Artem Ananiev wrote: > > On 3/8/2014 1:04 AM, Kevin Rushforth wrote: >> Hi Kay, >> >> It looks like you are using VS2012 not 2010. We build JavaFX with VS >> 2010, and have some issues with 2012. However, we will need to resolve >> them at some point. >> >> Maybe someone else on the list has had luck building with VS 2012? > > I was able to build FX with VS 2012 some time ago. The changes were > mostly cosmetic (caused by different Visual Studio and Platform SDK > directory layouts), except static C++ runtime linkage. And, of course, > FX should be aligned with JDK, which is shipped with VS 2010 runtime > (will it be changed in JDK9?), otherwise FX will have to ship with its > own runtime libraries. > > Thanks, > > Artem > >> -- Kevin >> >> >> Kay McCormick wrote: >>> Here is what I see as the relevant portions of the build log. This is >>> beyond my ability to fix easily at this point. I would attach the >>> entire >>> compile log but I compiled with --debug and its 4mb. Let me know if I >>> should provide more information, file a bug, or direct my problem to >>> another forum. >>> >>> Kay >>> >>> 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] >>> Successfully started process 'command 'C:/Program Files (x86)/Microsoft >>> Visual Studio 12.0/VC/BIN/amd64/link.exe'' >>> 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error >>> LNK2038: >>> mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' >>> doesn't >>> match value 'MD_DynamicRelease' in directwrite.obj >>> 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error >>> LNK2038: mismatch detected for 'RuntimeLibrary': value >>> 'MT_StaticRelease' >>> doesn't match value 'MD_DynamicRelease' in directwrite.obj >>> 12:35:16.336 [QUIET] [system.out] Creating library >>> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib >>> >>> >>> and object >>> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp >>> >>> >>> 12:35:16.362 [QUIET] [system.out] >>> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll >>> >>> >>> : fatal error LNK1319: 2 mismatches detected >>> 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] >>> Changing state to: FAILED >>> 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] >>> Process >>> 'command 'C:/Program Files (x86)/Microsoft Visual Studio >>> 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: >>> FAILED) >>> 12:35:16.368 [DEBUG] >>> [org.gradle.logging.internal.DefaultLoggingConfigurer] >>> Finished configuring with level: DEBUG, configurers: >>> [org.gradle.logging.internal.OutputEventRenderer at 1593948d, >>> org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, >>> org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] >>> 12:35:16.369 [DEBUG] >>> [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] >>> Finished executing task ':graphics:linkWinFont' >>> 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] >>> :graphics:linkWinFont FAILED >>> 12:35:16.369 [INFO] >>> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] >>> :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 secs. >>> 12:35:16.369 [DEBUG] >>> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker >>> [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: 0.017 >>> secs >>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 >>> mins >>> 29.213 secs From steve.x.northover at oracle.com Tue Mar 11 14:53:11 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 11 Mar 2014 10:53:11 -0400 Subject: Build Errors on Windows 8.1 / VS2012 Pro / JDK 1.8.0-b132 [was: Build Errors on Windows 8.1 / VS2010 Pro / JDK 1.8.0-b132] In-Reply-To: <531EFBAD.7040303@oracle.com> References: <531A346E.8020300@oracle.com> <531E8BC2.5010707@oracle.com> <531EFBAD.7040303@oracle.com> Message-ID: <531F2357.1050106@oracle.com> I tried the other day and failed because some standard windows desktop include files were not visible. I suspect that somewhere we were targetting the WinRT desktop or that a #defined was needed to force files to be included. The missing .h files were some OLE stuff that allowed FX to integrate with desktop. Steve On 2014-03-11 8:03 AM, Kevin Rushforth wrote: > Thanks, Artem. > > Yes, the version of Visual Studio that we build JavaFX with must be > tied to that of the JDK. VS 2010 SP1 for JDK 8 and 8u. Probably VS > 2013 for JDK 9. > > Prior to that, we may want to fix any issues that prevent developers > from building on VS 2012 or 2013. > > -- Kevin > > > Artem Ananiev wrote: >> >> On 3/8/2014 1:04 AM, Kevin Rushforth wrote: >>> Hi Kay, >>> >>> It looks like you are using VS2012 not 2010. We build JavaFX with VS >>> 2010, and have some issues with 2012. However, we will need to resolve >>> them at some point. >>> >>> Maybe someone else on the list has had luck building with VS 2012? >> >> I was able to build FX with VS 2012 some time ago. The changes were >> mostly cosmetic (caused by different Visual Studio and Platform SDK >> directory layouts), except static C++ runtime linkage. And, of >> course, FX should be aligned with JDK, which is shipped with VS 2010 >> runtime (will it be changed in JDK9?), otherwise FX will have to ship >> with its own runtime libraries. >> >> Thanks, >> >> Artem >> >>> -- Kevin >>> >>> >>> Kay McCormick wrote: >>>> Here is what I see as the relevant portions of the build log. This is >>>> beyond my ability to fix easily at this point. I would attach the >>>> entire >>>> compile log but I compiled with --debug and its 4mb. Let me know if I >>>> should provide more information, file a bug, or direct my problem to >>>> another forum. >>>> >>>> Kay >>>> >>>> 12:35:16.275 [INFO] [org.gradle.process.internal.DefaultExecHandle] >>>> Successfully started process 'command 'C:/Program Files >>>> (x86)/Microsoft >>>> Visual Studio 12.0/VC/BIN/amd64/link.exe'' >>>> 12:35:16.329 [QUIET] [system.out] libcpmt.lib(xthrow.obj) : error >>>> LNK2038: >>>> mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' >>>> doesn't >>>> match value 'MD_DynamicRelease' in directwrite.obj >>>> 12:35:16.332 [QUIET] [system.out] libcpmt.lib(syserror.obj) : error >>>> LNK2038: mismatch detected for 'RuntimeLibrary': value >>>> 'MT_StaticRelease' >>>> doesn't match value 'MD_DynamicRelease' in directwrite.obj >>>> 12:35:16.336 [QUIET] [system.out] Creating library >>>> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.lib >>>> >>>> >>>> and object >>>> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.exp >>>> >>>> >>>> 12:35:16.362 [QUIET] [system.out] >>>> C:\Users\kay\Documents\current\openjfx\rt\modules\graphics\build\libs\font\win\javafx_font.dll >>>> >>>> >>>> : fatal error LNK1319: 2 mismatches detected >>>> 12:35:16.368 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] >>>> Changing state to: FAILED >>>> 12:35:16.368 [INFO] [org.gradle.process.internal.DefaultExecHandle] >>>> Process >>>> 'command 'C:/Program Files (x86)/Microsoft Visual Studio >>>> 12.0/VC/BIN/amd64/link.exe'' finished with exit value 1319 (state: >>>> FAILED) >>>> 12:35:16.368 [DEBUG] >>>> [org.gradle.logging.internal.DefaultLoggingConfigurer] >>>> Finished configuring with level: DEBUG, configurers: >>>> [org.gradle.logging.internal.OutputEventRenderer at 1593948d, >>>> org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 1b604f19, >>>> org.gradle.logging.internal.JavaUtilLoggingConfigurer at 7823a2f9] >>>> 12:35:16.369 [DEBUG] >>>> [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] >>>> >>>> Finished executing task ':graphics:linkWinFont' >>>> 12:35:16.369 [LIFECYCLE] [org.gradle.TaskExecutionLogger] >>>> :graphics:linkWinFont FAILED >>>> 12:35:16.369 [INFO] >>>> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] >>>> :graphics:linkWinFont (Thread[main,5,main]) completed. Took 0.104 >>>> secs. >>>> 12:35:16.369 [DEBUG] >>>> [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker >>>> [Thread[main,5,main]] finished, busy: 3 mins 14.44 secs, idle: >>>> 0.017 secs >>>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >>>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED >>>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] >>>> 12:35:16.390 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3 >>>> mins >>>> 29.213 secs From hang.vo at oracle.com Tue Mar 11 15:03:47 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 15:03:47 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36065 [ScrollPane] Focus traversal to the first or last item does not make the ScrollPane to scroll to that item Message-ID: <201403111503.s2BF3wRh013839@aojmv0008> Changeset: b7dbbad9c9bd Author: Martin Sladecek Date: 2014-03-11 15:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b7dbbad9c9bd RT-36065 [ScrollPane] Focus traversal to the first or last item does not make the ScrollPane to scroll to that item Reviewed by: dgrieve ! modules/builders/src/main/java/javafx/scene/ParentBuilder.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/Algorithm.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/Direction.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/Hueristic2D.java + modules/graphics/src/main/java/com/sun/javafx/scene/traversal/ParentTraversalEngine.java + modules/graphics/src/main/java/com/sun/javafx/scene/traversal/SceneTraversalEngine.java + modules/graphics/src/main/java/com/sun/javafx/scene/traversal/SubSceneTraversalEngine.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TabOrderHelper.java + modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TopMostTraversalEngine.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TraversalEngine.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/WeightedClosestCorner.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/SubScene.java ! modules/graphics/src/test/java/com/sun/javafx/scene/traversal/TraversalTest.java ! modules/graphics/src/test/java/com/sun/javafx/scene/traversal/TraverseInvisibleTest.java - modules/graphics/src/test/java/javafx/scene/RegistrationTest.java ! modules/web/src/main/java/com/sun/javafx/scene/web/behavior/HTMLEditorBehavior.java ! modules/web/src/main/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java From hang.vo at oracle.com Tue Mar 11 15:18:22 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 15:18:22 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403111518.s2BFIdA0016289@aojmv0008> Changeset: a4ee872a75bb Author: Martin Sladecek Date: 2014-03-11 16:14 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a4ee872a75bb RT-35831 XYChart Series: NullPointerException when changing Series which is not assigned to a chart Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/XYChart.java ! modules/controls/src/test/java/javafx/scene/chart/XYChartTest.java Changeset: 685651bc38c2 Author: Martin Sladecek Date: 2014-03-11 16:15 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/685651bc38c2 RT-36151 Custom XYChart Memory-Leak Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/AreaChart.java ! modules/controls/src/main/java/javafx/scene/chart/BarChart.java ! modules/controls/src/main/java/javafx/scene/chart/LineChart.java ! modules/controls/src/main/java/javafx/scene/chart/XYChart.java From hang.vo at oracle.com Tue Mar 11 16:03:48 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 16:03:48 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35619 : IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox Message-ID: <201403111603.s2BG3xvg023185@aojmv0008> Changeset: d550116b8d71 Author: Rafi Tayar Date: 2014-03-11 17:54 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d550116b8d71 RT-35619 : IMX6-SDP / Yocto hard float : crash while running hello.HelloComboBox Reviewed-by : kselle, dblaukopf ! modules/graphics/src/main/native-glass/lens/LensCommon.h ! modules/graphics/src/main/native-glass/lens/LensWindow.c ! modules/graphics/src/main/native-glass/lens/wm/LensWindowManager.c From anthony.petrov at oracle.com Tue Mar 11 17:28:03 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 11 Mar 2014 21:28:03 +0400 Subject: No split-cursor inside JFXPanel In-Reply-To: <531A0197.3090608@media-interactive.de> References: <531A0197.3090608@media-interactive.de> Message-ID: <531F47A3.6000700@oracle.com> Hi Werner, I've re-targeted this bug to 8u20. -- best regards, Anthony On 3/7/2014 9:27 PM, Werner Lehmann wrote: > Hi, > > inside a JFXPanel we don't see the split-cursors (e.g. east/west). This > is a known issue: > > [#RT-26235] SplitPane in JFXPanel: Mouse cursor not changed > https://javafx-jira.kenai.com/browse/RT-26235 > > This affects regular splitpanes as well as custom nodes which just use > those cursors. The fix version for this is 9. This is going to be a > highly visible issue in our application when we convert more parts to > JFXPanels this year. Can this fix be done for one of the upcoming 8uXX > releases instead? > > Thanks, > Werner From hang.vo at oracle.com Tue Mar 11 17:48:22 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 17:48:22 +0000 Subject: hg: openjfx/8u-dev/rt: [DOC ONLY] RT-32340: Update javadoc for MenuBar Message-ID: <201403111748.s2BHmXQe009547@aojmv0008> Changeset: c508ecd2723b Author: leifs Date: 2014-03-11 10:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c508ecd2723b [DOC ONLY] RT-32340: Update javadoc for MenuBar ! modules/controls/src/main/java/javafx/scene/control/MenuBar.java From hang.vo at oracle.com Tue Mar 11 18:18:24 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 18:18:24 +0000 Subject: hg: openjfx/8u-dev/rt: RT-26235: SplitPane in JFXPanel: Mouse cursor not changed Message-ID: <201403111818.s2BIIaXf015616@aojmv0008> Changeset: 0e800351fd4b Author: Anthony Petrov Date: 2014-03-11 22:16 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0e800351fd4b RT-26235: SplitPane in JFXPanel: Mouse cursor not changed Summary: Use N_ and W_RESIZE AWT cursors for V_ and H_RESIZE FX cursors in JFXPanel ! modules/swing/src/main/java/javafx/embed/swing/SwingCursors.java From hang.vo at oracle.com Tue Mar 11 18:48:27 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 18:48:27 +0000 Subject: hg: openjfx/8u-dev/rt: [TEST-ONLY] fix compilation error in builder tests after change to TraversalEngine Message-ID: <201403111848.s2BImcgN020056@aojmv0008> Changeset: e256204869fb Author: kcr Date: 2014-03-11 11:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e256204869fb [TEST-ONLY] fix compilation error in builder tests after change to TraversalEngine ! modules/builders/src/test/java/javafx/scene/Group_builder_Test.java From kevin.rushforth at oracle.com Tue Mar 11 22:21:31 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Mar 2014 15:21:31 -0700 Subject: [8u20] review request: https://javafx-jira.kenai.com/browse/RT-36163 Message-ID: <531F8C6B.4000409@oracle.com> David, Please review the (simple) build fix for: JIRA: https://javafx-jira.kenai.com/browse/RT-36163 Webrev: http://cr.openjdk.java.net/~kcr/RT-36163/ -- Kevin From David.Hill at Oracle.com Tue Mar 11 22:28:34 2014 From: David.Hill at Oracle.com (David Hill) Date: Tue, 11 Mar 2014 18:28:34 -0400 Subject: [8u20] review request: https://javafx-jira.kenai.com/browse/RT-36163 In-Reply-To: <531F8C6B.4000409@oracle.com> References: <531F8C6B.4000409@oracle.com> Message-ID: <531F8E12.4090106@Oracle.com> On 3/11/14, Mar 11, 6:21 PM, Kevin Rushforth wrote: > David, > > Please review the (simple) build fix for: > > JIRA: https://javafx-jira.kenai.com/browse/RT-36163 > Webrev: http://cr.openjdk.java.net/~kcr/RT-36163/ > > -- Kevin > +1 -- David Hill Java Embedded Development Education: that which reveals to the wise, and conceals from the stupid, the vast limits of their knowledge. -- Mark Twain From hang.vo at oracle.com Tue Mar 11 22:48:20 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Mar 2014 22:48:20 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9 Message-ID: <201403112248.s2BMmVsV025101@aojmv0008> Changeset: 4f508b0b661f Author: kcr Date: 2014-03-11 15:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4f508b0b661f RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9 Reviewed-by: ddhill ! build.gradle From hang.vo at oracle.com Wed Mar 12 07:04:06 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Mar 2014 07:04:06 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36169 javac performance regression due to addition of FXML annotation processor Message-ID: <201403120704.s2C74HvN009287@aojmv0008> Changeset: 36a6cb6dc429 Author: Martin Sladecek Date: 2014-03-12 07:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/36a6cb6dc429 RT-36169 javac performance regression due to addition of FXML annotation processor - modules/fxml/src/main/java/com/sun/javafx/fxml/annotation/FXMLAnnotationProcessor.java - modules/fxml/src/main/resources/META-INF/services/javax.annotation.processing.Processor From lehmann at media-interactive.de Wed Mar 12 09:24:37 2014 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 12 Mar 2014 10:24:37 +0100 Subject: No split-cursor inside JFXPanel In-Reply-To: <531F47A3.6000700@oracle.com> References: <531A0197.3090608@media-interactive.de> <531F47A3.6000700@oracle.com> Message-ID: <532027D5.1030600@media-interactive.de> Hi Anthony, I noticed the movement on the ticket ;-) Very good news, thx for looking into this! Werner On 11.03.2014 18:28, Anthony Petrov wrote: > Hi Werner, > > I've re-targeted this bug to 8u20. > > -- > best regards, > Anthony > > On 3/7/2014 9:27 PM, Werner Lehmann wrote: >> Hi, >> >> inside a JFXPanel we don't see the split-cursors (e.g. east/west). This >> is a known issue: >> >> [#RT-26235] SplitPane in JFXPanel: Mouse cursor not changed >> https://javafx-jira.kenai.com/browse/RT-26235 >> >> This affects regular splitpanes as well as custom nodes which just use >> those cursors. The fix version for this is 9. This is going to be a >> highly visible issue in our application when we convert more parts to >> JFXPanels this year. Can this fix be done for one of the upcoming 8uXX >> releases instead? >> >> Thanks, >> Werner From felipe.heidrich at oracle.com Wed Mar 12 17:03:35 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Wed, 12 Mar 2014 10:03:35 -0700 Subject: Poor font rendering.. In-Reply-To: <5f466793-d3db-4160-85c4-e5b6632768d2@tesis.de> References: <5f466793-d3db-4160-85c4-e5b6632768d2@tesis.de> Message-ID: <7E054931-84F4-49C8-80AD-188147662891@oracle.com> On Mar 11, 2014, at 1:57 AM, Robert Fisher wrote: > Suppose I want to see what GDI, SWT-like text looks like in JavaFX. I should set -Djavafx.text=t2k. But looking at the picture (http://i.imgur.com/CGyckge.png) it still seems there is some additional blurring in JavaFX. Some additional sub-pixel positioning logic, perhaps? Exactly, See GlyphCache#addDataToQuad(), in the isLCDCache case, dx1 = Math.round(dx1 * 3.0f) / 3.0f; Later in /graphics/src/main/jsl-prism/PaintTextureSecondPassLCD.jsl that dx1 (which was rounded to .0, 0.33, 0.66) is used to offset the pixel color RGB values to produce the sub pixel image. Rounding that dx1 to pixel (like GlyphCache does for grayscale text), then I would expected -Djavafx.text=t2k and SWT to look very similar. Cheers Felipe From kevin.rushforth at oracle.com Wed Mar 12 17:25:12 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 12 Mar 2014 10:25:12 -0700 Subject: [8u20] review request: RT-36189: [JFXPanel] SecurityException in PlatformUtil when running SwingInterop with security manager Message-ID: <53209878.2050804@oracle.com> Steve, Thomas, Please review the following fix: https://javafx-jira.kenai.com/browse/RT-36189 -- Kevin From hang.vo at oracle.com Wed Mar 12 18:03:45 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Mar 2014 18:03:45 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36189: [JFXPanel] SecurityException in PlatformUtil when running SwingInterop with security manager Message-ID: <201403121803.s2CI3vrS017577@aojmv0008> Changeset: 5ccfbb1bbdad Author: kcr Date: 2014-03-12 10:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5ccfbb1bbdad RT-36189: [JFXPanel] SecurityException in PlatformUtil when running SwingInterop with security manager Reviewed-by: snorthov, ngthomas ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java From philip.race at oracle.com Wed Mar 12 19:20:41 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Mar 2014 12:20:41 -0700 Subject: RFR: RT-36178: Printing: Scene is not printed when blending is used. Message-ID: <5320B389.6000606@oracle.com> Bug: https://javafx-jira.kenai.com/browse/RT-36178 Fix: http://cr.openjdk.java.net/~prr/rt-36178/ From hang.vo at oracle.com Wed Mar 12 21:03:40 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Mar 2014 21:03:40 +0000 Subject: hg: openjfx/8u-dev/rt: RT-34852: [2D traversal, RTL] Some behavior classes are confusing the semantics of left & right in RTL mode. Message-ID: <201403122103.s2CL3pux015841@aojmv0008> Changeset: 70b21195381b Author: leifs Date: 2014-03-12 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/70b21195381b RT-34852: [2D traversal, RTL] Some behavior classes are confusing the semantics of left & right in RTL mode. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java From james.graham at oracle.com Wed Mar 12 23:40:32 2014 From: james.graham at oracle.com (Jim Graham) Date: Wed, 12 Mar 2014 16:40:32 -0700 Subject: 8u20 review request: RT-36208: Exception using grayscale icon Message-ID: <5320F070.9040006@oracle.com> Simple cut/paste error fix: Jira: https://javafx-jira.kenai.com/browse/RT-36208 webrev: http://cr.openjdk.java.net/~flar/RT-36208/webrev.00/ ...jim From hang.vo at oracle.com Thu Mar 13 00:03:52 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Mar 2014 00:03:52 +0000 Subject: hg: openjfx/8u-dev/rt: Fix RT-36208: Exceptions with grayscale icon on Stage Message-ID: <201403130004.s2D043gC017755@aojmv0008> Changeset: f1194ad7a283 Author: flar Date: 2014-03-12 16:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f1194ad7a283 Fix RT-36208: Exceptions with grayscale icon on Stage Reviewed by: kcr ! modules/graphics/src/main/java/com/sun/javafx/image/impl/ByteGray.java From hang.vo at oracle.com Thu Mar 13 07:48:18 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Mar 2014 07:48:18 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403130748.s2D7mZaZ023082@aojmv0008> Changeset: bdfad1c1aebe Author: Martin Sladecek Date: 2014-03-13 08:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bdfad1c1aebe RT-36140 [TableView, Cursor] Mouse flickers when resizing a table column Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: 4b447b1a4130 Author: Martin Sladecek Date: 2014-03-13 08:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4b447b1a4130 RT-36159 [FlowPane, TitledPane] Preferred size of FlowPane with wrapped and unwrapped content seems to be the same if within TitledPane Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java From hang.vo at oracle.com Thu Mar 13 11:48:15 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Mar 2014 11:48:15 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35197: Use Lambda in FX runtime and samples [web] Message-ID: <201403131148.s2DBmQ3W027989@aojmv0008> Changeset: b873fbebaf0d Author: snorthov Date: 2014-03-13 07:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b873fbebaf0d RT-35197: Use Lambda in FX runtime and samples [web] Summary: This component was lambdified (unlambdified file names recorded in the JIRA) ! modules/web/src/main/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java ! modules/web/src/main/java/com/sun/javafx/webkit/EventLoopImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/UIClientImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/WebPageClientImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/drt/DumpRenderTree.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/PrismInvoker.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/RTImage.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCImageDecoderImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCRadialGradient.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCRenderQueueImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/ContextMenuImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/PopupMenuImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/RenderThemeImpl.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/ScrollBarThemeImpl.java ! modules/web/src/main/java/com/sun/webkit/MainThread.java ! modules/web/src/main/java/com/sun/webkit/Timer.java ! modules/web/src/main/java/com/sun/webkit/Utilities.java ! modules/web/src/main/java/com/sun/webkit/WatchdogTimer.java ! modules/web/src/main/java/com/sun/webkit/WebPage.java ! modules/web/src/main/java/com/sun/webkit/graphics/WCMediaPlayer.java ! modules/web/src/main/java/com/sun/webkit/graphics/WCRenderQueue.java ! modules/web/src/main/java/com/sun/webkit/network/NetworkContext.java ! modules/web/src/main/java/com/sun/webkit/network/SocketStreamHandle.java ! modules/web/src/main/java/com/sun/webkit/network/URLLoader.java ! modules/web/src/main/java/com/sun/webkit/perf/PerfLogger.java ! modules/web/src/main/java/javafx/scene/web/WebEngine.java ! modules/web/src/main/java/javafx/scene/web/WebHistory.java ! modules/web/src/main/java/javafx/scene/web/WebView.java ! modules/web/src/test/java/javafx/scene/web/BindingTest.java ! modules/web/src/test/java/javafx/scene/web/CSSTest.java ! modules/web/src/test/java/javafx/scene/web/CallbackTest.java ! modules/web/src/test/java/javafx/scene/web/DOMTest.java ! modules/web/src/test/java/javafx/scene/web/DebuggerTest.java ! modules/web/src/test/java/javafx/scene/web/HistoryTest.java ! modules/web/src/test/java/javafx/scene/web/IrresponsiveScriptTest.java ! modules/web/src/test/java/javafx/scene/web/JavaScriptBridgeTest.java ! modules/web/src/test/java/javafx/scene/web/LeakTest.java ! modules/web/src/test/java/javafx/scene/web/LoadNotificationsTest.java ! modules/web/src/test/java/javafx/scene/web/LoadTest.java ! modules/web/src/test/java/javafx/scene/web/MiscellaneousTest.java ! modules/web/src/test/java/javafx/scene/web/TestBase.java ! modules/web/src/test/java/javafx/scene/web/UserDataDirectoryTest.java ! modules/web/src/test/java/javafx/scene/web/WebPageTest.java ! modules/web/src/test/java/javafx/scene/web/WebViewTest.java From hang.vo at oracle.com Thu Mar 13 17:18:29 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Mar 2014 17:18:29 +0000 Subject: hg: openjfx/8u-dev/rt: RT-20642: Instead of trying to pouplate a Map as styles are found during state transition, just have a routine that will find the styles, as discussed with Jerome Message-ID: <201403131718.s2DHIf5s017268@aojmv0008> Changeset: c42d31058266 Author: David Grieve Date: 2014-03-13 12:56 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c42d31058266 RT-20642: Instead of trying to pouplate a Map as styles are found during state transition, just have a routine that will find the styles, as discussed with Jerome ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/css/NodeCssState.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/util/CssInternal.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/util/Deprecation.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/test/java/com/sun/javafx/css/Node_cssStyleMap_Test.java From hang.vo at oracle.com Thu Mar 13 18:48:17 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Mar 2014 18:48:17 +0000 Subject: hg: openjfx/8u-dev/rt: Backed out RT-20642 changeset c42d31058266 Message-ID: <201403131848.s2DImTan000280@aojmv0008> Changeset: 55c7382f2098 Author: David Grieve Date: 2014-03-13 14:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/55c7382f2098 Backed out RT-20642 changeset c42d31058266 ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/css/NodeCssState.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/util/CssInternal.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/util/Deprecation.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/test/java/com/sun/javafx/css/Node_cssStyleMap_Test.java From danno.ferrin at oracle.com Thu Mar 13 19:08:02 2014 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Thu, 13 Mar 2014 13:08:02 -0600 Subject: 8u20 review request: RT-35635: new bundlers for fxpackager Message-ID: Kevin, Chris, Dmitry Please review. These are the new bundlers for the 8u20 packager, the daemon/services stuff Dmitry has been working on, and other related changes. It?s a big one so more eyes to find the stinkers before it gets committed would be appreciated. Jira: https://javafx-jira.kenai.com/browse/RT-35635 and https://javafx-jira.kenai.com/browse/RT-35969 Webrev: http://cr.openjdk.java.net/~shemnon/RT-35635/webrev.00/ From hang.vo at oracle.com Fri Mar 14 02:03:14 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 14 Mar 2014 02:03:14 +0000 Subject: hg: openjfx/8u-dev/rt: 4 new changesets Message-ID: <201403140203.s2E23gX2005782@aojmv0008> Changeset: e6a0305158da Author: David Grieve Date: 2014-03-13 21:50 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e6a0305158da RT-20642: Instead of trying to pouplate a Map as styles are found during state transition, just have a routine that will find the styles, as discussed with Jerome ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/test/java/com/sun/javafx/css/Node_cssStyleMap_Test.java Changeset: 102deeb4dcaa Author: David Grieve Date: 2014-03-13 21:50 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/102deeb4dcaa RT-36117: set cell skin to null after skin is disposed. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: 8ca3ec4ca878 Author: David Grieve Date: 2014-03-13 21:50 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8ca3ec4ca878 RT-36111: move firing of ON_SHOWING event to doShow method to pair with firing of ON_SHOWN ! modules/controls/src/main/java/javafx/scene/control/ContextMenu.java Changeset: cd116a725b95 Author: David Grieve Date: 2014-03-13 21:50 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cd116a725b95 RT-36095: behavior code assumed ToggleButton was in a ToggleGroup, but it does not have to be. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ToggleButtonBehavior.java From dmitry.cherepanov at oracle.com Fri Mar 14 11:21:37 2014 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 14 Mar 2014 15:21:37 +0400 Subject: 8u20 review request: RT-35635: new bundlers for fxpackager In-Reply-To: References: Message-ID: <5322E641.60703@oracle.com> Looks good to me. Thanks Dmitry On 3/13/14 11:08 PM, Danno Ferrin wrote: > Kevin, Chris, Dmitry > Please review. These are the new bundlers for the 8u20 packager, the daemon/services stuff Dmitry has been working on, and other related changes. It?s a big one so more eyes to find the stinkers before it gets committed would be appreciated. > > Jira: https://javafx-jira.kenai.com/browse/RT-35635 and https://javafx-jira.kenai.com/browse/RT-35969 > Webrev: http://cr.openjdk.java.net/~shemnon/RT-35635/webrev.00/ From anthony.petrov at oracle.com Fri Mar 14 11:43:35 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 14 Mar 2014 15:43:35 +0400 Subject: 8u20 review request: RT-35635: new bundlers for fxpackager In-Reply-To: <5322E641.60703@oracle.com> References: <5322E641.60703@oracle.com> Message-ID: <5322EB67.80106@oracle.com> Dmitry, all, Please post your review notes to JIRA to keep all the information in one place. We use the mailing list to send out review requests so that other people could start watching the bug and/or join the review. The review itself should happen in JIRA comments. Thank you in advance. -- best regards, Anthony On 3/14/2014 3:21 PM, Dmitry Cherepanov wrote: > Looks good to me. > > Thanks > Dmitry > > On 3/13/14 11:08 PM, Danno Ferrin wrote: >> Kevin, Chris, Dmitry >> Please review. These are the new bundlers for the 8u20 packager, the >> daemon/services stuff Dmitry has been working on, and other related >> changes. It?s a big one so more eyes to find the stinkers before it >> gets committed would be appreciated. >> >> Jira: https://javafx-jira.kenai.com/browse/RT-35635 and >> https://javafx-jira.kenai.com/browse/RT-35969 >> Webrev: http://cr.openjdk.java.net/~shemnon/RT-35635/webrev.00/ > From hang.vo at oracle.com Fri Mar 14 12:18:14 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 14 Mar 2014 12:18:14 +0000 Subject: hg: openjfx/8u-dev/rt: [TEST-ONLY] ignore Node_cssStyleMap_Test until failure can be resolved Message-ID: <201403141218.s2ECIP9J005263@aojmv0008> Changeset: 58cfa37fa986 Author: David Grieve Date: 2014-03-14 08:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/58cfa37fa986 [TEST-ONLY] ignore Node_cssStyleMap_Test until failure can be resolved ! modules/graphics/src/test/java/com/sun/javafx/css/Node_cssStyleMap_Test.java From anthony.petrov at oracle.com Fri Mar 14 13:51:50 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 14 Mar 2014 17:51:50 +0400 Subject: [8u20] Review request for RT-34283: [Swing] Drag&Drop with interop on Mac OS X between two processes does not transfer data Message-ID: <53230976.1060301@oracle.com> Hi Steve, Petr, Please review a fix for https://javafx-jira.kenai.com/browse/RT-34283 -- best regards, Anthony From hang.vo at oracle.com Fri Mar 14 16:18:39 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 14 Mar 2014 16:18:39 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403141618.s2EGIuTl013425@aojmv0008> Changeset: 7b70873c59f9 Author: hudson Date: 2014-03-12 09:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7b70873c59f9 Added tag 8u20-b05 for changeset f00f65d8ca59 ! .hgtags Changeset: c3b28058d4d3 Author: kcr Date: 2014-03-14 09:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c3b28058d4d3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8u/master/jfx/rt - modules/fxml/src/main/java/com/sun/javafx/fxml/annotation/FXMLAnnotationProcessor.java - modules/fxml/src/main/resources/META-INF/services/javax.annotation.processing.Processor - modules/graphics/src/test/java/javafx/scene/RegistrationTest.java From phidias51 at gmail.com Fri Mar 14 17:59:09 2014 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 14 Mar 2014 10:59:09 -0700 Subject: 8u20 review request: RT-35635: new bundlers for fxpackager In-Reply-To: <5322EB67.80106@oracle.com> References: <5322E641.60703@oracle.com> <5322EB67.80106@oracle.com> Message-ID: Just out of curiousity, is there some reason that the new classes are in *com.oracle* and *com.sun* packages instead of just in a *javafx.tools*package? import com.oracle.bundlers.windows.WindowsBundlerParam; import com.sun.javafx.tools.packager.Log; import com.sun.javafx.tools.packager.bundlers.ConfigException; import com.sun.javafx.tools.packager.bundlers.IOUtils; import com.sun.javafx.tools.packager.bundlers.RelativeFileSet; If there's some chance that these implementations are going to be replaced, wouldn't it be better to at least declare their interfaces publicly in javafx.tools? Cheers, Mark On Fri, Mar 14, 2014 at 4:43 AM, Anthony Petrov wrote: > Dmitry, all, > > Please post your review notes to JIRA to keep all the information in one > place. We use the mailing list to send out review requests so that other > people could start watching the bug and/or join the review. The review > itself should happen in JIRA comments. Thank you in advance. > > -- > best regards, > Anthony > > > On 3/14/2014 3:21 PM, Dmitry Cherepanov wrote: > >> Looks good to me. >> >> Thanks >> Dmitry >> >> On 3/13/14 11:08 PM, Danno Ferrin wrote: >> >>> Kevin, Chris, Dmitry >>> Please review. These are the new bundlers for the 8u20 packager, the >>> daemon/services stuff Dmitry has been working on, and other related >>> changes. It's a big one so more eyes to find the stinkers before it >>> gets committed would be appreciated. >>> >>> Jira: https://javafx-jira.kenai.com/browse/RT-35635 and >>> https://javafx-jira.kenai.com/browse/RT-35969 >>> Webrev: http://cr.openjdk.java.net/~shemnon/RT-35635/webrev.00/ >>> >> >> From danno.ferrin at oracle.com Fri Mar 14 18:25:48 2014 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Fri, 14 Mar 2014 12:25:48 -0600 Subject: 8u20 review request: RT-35635: new bundlers for fxpackager In-Reply-To: References: <5322E641.60703@oracle.com> <5322EB67.80106@oracle.com> Message-ID: <45800302-7703-4D3F-A63A-CDEBA3A1F22D@oracle.com> This is an interim commit, the next one will be just a move to com.oracle.bundlers. I would consider those to be the definitive api going forward for the bundlers portion. The com.sun.javafx package implies that these are useful only for JavaFX, which is not the case since we are adding daemon/service deployments. For now I am doing the patches in place so that the diffs make sense. Move diffs? not so much. On Mar 14, 2014, at 11:59 AM, Mark Fortner wrote: > Just out of curiousity, is there some reason that the new classes are in com.oracle and com.sun packages instead of just in a javafx.tools package? > > import com.oracle.bundlers.windows.WindowsBundlerParam; > import com.sun.javafx.tools.packager.Log; > import com.sun.javafx.tools.packager.bundlers.ConfigException; > import com.sun.javafx.tools.packager.bundlers.IOUtils; > import com.sun.javafx.tools.packager.bundlers.RelativeFileSet; > If there's some chance that these implementations are going to be replaced, wouldn't it be better to at least declare their interfaces publicly in javafx.tools? > > Cheers, > > Mark > > > > On Fri, Mar 14, 2014 at 4:43 AM, Anthony Petrov wrote: > Dmitry, all, > > Please post your review notes to JIRA to keep all the information in one place. We use the mailing list to send out review requests so that other people could start watching the bug and/or join the review. The review itself should happen in JIRA comments. Thank you in advance. > > -- > best regards, > Anthony > > > On 3/14/2014 3:21 PM, Dmitry Cherepanov wrote: > Looks good to me. > > Thanks > Dmitry > > On 3/13/14 11:08 PM, Danno Ferrin wrote: > Kevin, Chris, Dmitry > Please review. These are the new bundlers for the 8u20 packager, the > daemon/services stuff Dmitry has been working on, and other related > changes. It?s a big one so more eyes to find the stinkers before it > gets committed would be appreciated. > > Jira: https://javafx-jira.kenai.com/browse/RT-35635 and > https://javafx-jira.kenai.com/browse/RT-35969 > Webrev: http://cr.openjdk.java.net/~shemnon/RT-35635/webrev.00/ > > From vadim.pakhnushev at oracle.com Fri Mar 14 21:00:06 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 15 Mar 2014 01:00:06 +0400 Subject: [8u20] Review request for RT-35681: Rendering difference between platforms when specular map is used Message-ID: <53236DD6.6010108@oracle.com> Hi Chien, Please review this simple fix: https://javafx-jira.kenai.com/browse/RT-35681 http://cr.openjdk.java.net/~vadim/RT-35681/webrev.00/ Thanks, Vadim From hrjet9 at gmail.com Sat Mar 15 06:01:16 2014 From: hrjet9 at gmail.com (Harshad RJ) Date: Sat, 15 Mar 2014 11:31:16 +0530 Subject: WebEngine PolicyClient Message-ID: Hi, I have been playing with the WebView / WebEngine and wanted more control over navigation actions of the user. I noticed that WebPage.java has a PolicyClient, but is set to null by WebEngine. Have two questions: * Even if I modify WebEngine and set the PolicyClient, it doesn't receive any callbacks. Is it disabled somewhere else? I looked at WebPage.java and found that the corresponding fwk* functions don't get called. * Is there any plan to expose this functionality through the public API? thanks, HRJ From hrjet9 at gmail.com Sat Mar 15 07:26:39 2014 From: hrjet9 at gmail.com (Harshad RJ) Date: Sat, 15 Mar 2014 12:56:39 +0530 Subject: WebEngine PolicyClient In-Reply-To: References: Message-ID: On Sat, Mar 15, 2014 at 11:31 AM, Harshad RJ wrote: > Even if I modify WebEngine and set the PolicyClient, it doesn't > receive any callbacks. Is it disabled somewhere else? I looked at > WebPage.java and found that the corresponding fwk* functions don't get > called. Sorry, I was not setting the PolicyClient correctly. Most of the PolicyClient callbacks are working: permitAcceptResourceAction, permitNavigateAction, permitRedirectAction, permitSubmitDataAction Not called: permitEnableScriptAction Not tested: permitClosePageAction, permitNewPageAction, permitResubmitDataAction. Any hints about why permitEnableScriptAction wouldn't get called? Thanks, HRJ From kevin.rushforth at oracle.com Sat Mar 15 14:44:10 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 15 Mar 2014 07:44:10 -0700 Subject: [8u] review request: RT-36141: Gtk: SecurityException using WebView when running app with security manager Message-ID: <5324673A.8050905@oracle.com> Anthony, Please review the following fix for a regression introduced in FX 8 that prevents untrusted applications from running WebView on Linux. JIRA: https://javafx-jira.kenai.com/browse/RT-36141 Webrev: http://cr.openjdk.java.net/~kcr/RT-36141/ Thanks. -- Kevin From kevin.rushforth at oracle.com Sat Mar 15 14:51:09 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 15 Mar 2014 07:51:09 -0700 Subject: [8u] review request: RT-36232: [Quantum] SecurityException on exit when running any FX program with security manager Message-ID: <532468DD.1080706@oracle.com> Felipe or Anthony, Please review the following fix for a regression introduced in 8u20 that causes untrusted applications to get an exception on exit. JIRA: https://javafx-jira.kenai.com/browse/RT-36232 Webrev: http://cr.openjdk.java.net/~kcr/RT-36232/ Thanks. -- Kevin From tom.schindl at bestsolution.at Sun Mar 16 12:55:57 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 16 Mar 2014 05:55:57 -0700 Subject: Opacity in Image.getPixelReader.getColor() Message-ID: <53259F5D.30108@bestsolution.at> Hi, Maybe I'm completely wrong but to me it looks like the opacity I get from Image.getPixelReader.getColor() is wrong. If not mistaken the relation between alpha and opacity is expressed with: opacity = (255 - alpha) / 255.0 which means: opacity 0 => alpha 255 opacity 1 => alpha 0 Running the following programm on a gif > public class OpacityBug extends Application { > > @Override > public void start(Stage primaryStage) throws Exception { > Image image = new Image(getClass().getResourceAsStream("methpri_obj.gif")); > int width = (int) image.getWidth(); > int height = (int) image.getHeight(); > > PixelReader reader = image.getPixelReader(); > for (int x = width - 1; x >= 0; x--) { > for (int y = height - 1; y >= 0; y--) { > int argb = reader.getArgb(x, y); > int alphaArgb = (argb >> 24) & 0xFF; > Color color = reader.getColor(x, y); > double opacity = color.getOpacity(); > System.err.println(x+","+y + " => alpha: " + alphaArgb + " op: " + opacity + " op-alpha: " + opacityToAlpha(opacity) + " color: " + color); > } > } > } > > > private static int opacityToAlpha(double opacity) { > return (int)Math.round((((opacity * 255.0) - 255) * -1)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } produces and output like: 15,15 => alpha: 0 op: 0.0 op-alpha: 255 color: 0x00000000 which to my understanding is wrong. The argb value is correct (if compared to the image because the pixel at 15,15 is fully transparent) but then the the opacity should be 1.0 but is the opposite. Looking at the code in Image I see: > @Override > public Color getColor(int x, int y) { > int argb = getArgb(x, y); > int a = argb >>> 24; > int r = (argb >> 16) & 0xff; > int g = (argb >> 8) & 0xff; > int b = (argb ) & 0xff; > return Color.rgb(r, g, b, a / 255.0); > } which means that: a) my formula from the above is wrong b) or there's the bug because it should be return Color.rgb(r, g, b, (255 - a) / 255.0); May I also suggest to add get a - Color.argb(int r,int g,int b,int alpha) maybe it is just me but I'm so much more used to alpha than opacity that I always have to look it up when i need it. Tom From sven.reimers at gmail.com Sun Mar 16 19:30:26 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 16 Mar 2014 20:30:26 +0100 Subject: SceneBuilder Integration in NetBeans Message-ID: Hi guys, hope someone can help me with the exception pasted below. Any idea how to go on from here? The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ Thanks -Sven java.lang.IllegalArgumentException: failed to parse:scene.builder.internal at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) at javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) at sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) at sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) at sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) at java.awt.dnd.DragSource.startDrag(DragSource.java:321) at java.awt.dnd.DragSource.startDrag(DragSource.java:426) at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) [catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From sven.reimers at gmail.com Sun Mar 16 20:13:54 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 16 Mar 2014 21:13:54 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: Message-ID: Ok... figured it out. It seems scene.builder.internal crashes the Swing parsing mechanism for mime types in the data transfer. Changing it to scene.builder/internal fixes this problem. Shall I open an issue in Jira for it? Having fixed this I get another problem :-( (see stacktrace below) Not sure how to fix this... investigating now. -Sven java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to java.io.InputStream at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) at sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) at java.awt.EventQueue$4.run(EventQueue.java:719) at java.awt.EventQueue$4.run(EventQueue.java:717) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers wrote: > Hi guys, > > hope someone can help me with the exception pasted below. > > Any idea how to go on from here? > > The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ > > Thanks > > -Sven > > java.lang.IllegalArgumentException: failed to parse:scene.builder.internal > at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) > at > javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) > at > sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) > at > sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) > at > sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) > at java.awt.dnd.DragSource.startDrag(DragSource.java:321) > at java.awt.dnd.DragSource.startDrag(DragSource.java:426) > at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) > at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) > at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) > at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > at java.awt.EventQueue.access$400(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:697) > at java.awt.EventQueue$3.run(EventQueue.java:691) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) > [catch] at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > * Blog: https://www.java.net//blog/sven > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Mon Mar 17 03:33:27 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 03:33:27 +0000 Subject: hg: openjfx/8u-dev/rt: 3 new changesets Message-ID: <201403170333.s2H3XoDd017968@aojmv0008> Changeset: d2b135379e8d Author: jgiles Date: 2014-03-17 11:37 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d2b135379e8d RT-36220: [TableCell] TableCell does not refresh Contributed-by: Mario Ivankovits Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: f06a098b55c4 Author: jgiles Date: 2014-03-17 13:44 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f06a098b55c4 RT-35949: TreeView: ContextMenu does not selects the TreeCell on which the menu has been started ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 748893eeb873 Author: jgiles Date: 2014-03-17 16:23 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/748893eeb873 RT-36234: Cell behavior code is highly duplicated ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java + modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CellSkinBase.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/ListViewAnchorRetriever.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/TreeViewAnchorRetriever.java From hang.vo at oracle.com Mon Mar 17 08:02:55 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 08:02:55 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403170803.s2H83CFn025759@aojmv0008> Changeset: 93a63c9eb06f Author: Martin Sladecek Date: 2014-03-17 08:59 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/93a63c9eb06f RT-36152 TableHeaders behave badly when horizontal scrollbar is visible RT-34897 [ListView] ListView not downsizing cells when its breadth shrinks Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: a9e3c226abab Author: Martin Sladecek Date: 2014-03-17 09:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a9e3c226abab RT-36134 [ScrollPane] Scrolling into bounds not consistent Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From petr.pchelko at oracle.com Mon Mar 17 09:01:03 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 17 Mar 2014 13:01:03 +0400 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: Message-ID: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> Hello, Sven. Looks like you are not specifying the representation class for the DataFlavor and it defaults to the InputStream. So, scene builder puts a ByteBuffer while the DataTransferer is trying to treat it as an InputStream. Could you please try to explicitly specify the representation class in the DataFlavor you are trying to put? Like this: new DataFlavor("scene.builder/internal; class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") With best regards. Petr. On 17.03.2014, at 0:13, Sven Reimers wrote: > Ok... figured it out. It seems scene.builder.internal crashes the Swing > parsing mechanism for mime types in the data transfer. Changing it to > scene.builder/internal fixes this problem. > > Shall I open an issue in Jira for it? > > Having fixed this I get another problem :-( > (see stacktrace below) > > Not sure how to fix this... investigating now. > > -Sven > > java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to > java.io.InputStream > at > sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) > at > sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) > at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > at java.awt.EventQueue.access$400(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:697) > at java.awt.EventQueue$3.run(EventQueue.java:691) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:719) > at java.awt.EventQueue$4.run(EventQueue.java:717) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > > On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers wrote: > >> Hi guys, >> >> hope someone can help me with the exception pasted below. >> >> Any idea how to go on from here? >> >> The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ >> >> Thanks >> >> -Sven >> >> java.lang.IllegalArgumentException: failed to parse:scene.builder.internal >> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) >> at >> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) >> at >> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) >> at >> sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) >> at >> sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) >> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) >> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) >> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) >> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) >> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) >> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >> at java.awt.EventQueue.access$400(EventQueue.java:97) >> at java.awt.EventQueue$3.run(EventQueue.java:697) >> at java.awt.EventQueue$3.run(EventQueue.java:691) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >> at >> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) >> [catch] at >> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >> at >> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >> at >> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> * Duke's Choice Award Winner 2009 >> * Blog: https://www.java.net//blog/sven >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > * Blog: https://www.java.net//blog/sven > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From sven.reimers at gmail.com Mon Mar 17 09:39:14 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 17 Mar 2014 10:39:14 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> Message-ID: The problem seems to be in AbstractDragSource in SceneBuilder. It defines a javafx.scene.input.DataFormat. This seems to cause problems if running embedded in Swing. I do not define my own DataFlavors.. Any further help appreciated.. -Sven Am 17.03.2014 09:54 schrieb "Petr Pchelko" : > Hello, Sven. > > Looks like you are not specifying the representation class for the > DataFlavor and it defaults > to the InputStream. So, scene builder puts a ByteBuffer while the > DataTransferer is trying to treat it as an > InputStream. > > Could you please try to explicitly specify the representation class in the > DataFlavor you are trying to put? > Like this: new DataFlavor("scene.builder/internal; > class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") > > With best regards. Petr. > > On 17.03.2014, at 0:13, Sven Reimers wrote: > > > Ok... figured it out. It seems scene.builder.internal crashes the Swing > > parsing mechanism for mime types in the data transfer. Changing it to > > scene.builder/internal fixes this problem. > > > > Shall I open an issue in Jira for it? > > > > Having fixed this I get another problem :-( > > (see stacktrace below) > > > > Not sure how to fix this... investigating now. > > > > -Sven > > > > java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to > > java.io.InputStream > > at > > > sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) > > at > > > sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) > > at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) > > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > > at java.awt.EventQueue.access$400(EventQueue.java:97) > > at java.awt.EventQueue$3.run(EventQueue.java:697) > > at java.awt.EventQueue$3.run(EventQueue.java:691) > > at java.security.AccessController.doPrivileged(Native Method) > > at > > > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > > at > > > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) > > at java.awt.EventQueue$4.run(EventQueue.java:719) > > at java.awt.EventQueue$4.run(EventQueue.java:717) > > at java.security.AccessController.doPrivileged(Native Method) > > at > > > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) > > at > > > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) > > at > > > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > > at > > > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > > at > > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > > > > > On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers >wrote: > > > >> Hi guys, > >> > >> hope someone can help me with the exception pasted below. > >> > >> Any idea how to go on from here? > >> > >> The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ > >> > >> Thanks > >> > >> -Sven > >> > >> java.lang.IllegalArgumentException: failed to > parse:scene.builder.internal > >> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) > >> at > >> > javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) > >> at > >> > sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) > >> at > >> > sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) > >> at > >> > sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) > >> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) > >> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) > >> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) > >> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) > >> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) > >> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) > >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > >> at java.awt.EventQueue.access$400(EventQueue.java:97) > >> at java.awt.EventQueue$3.run(EventQueue.java:697) > >> at java.awt.EventQueue$3.run(EventQueue.java:691) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at > >> > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > >> at > >> > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) > >> [catch] at > >> > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > >> at > >> > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > >> at > >> > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > >> > >> -- > >> Sven Reimers > >> > >> * Senior Expert Software Architect > >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >> * Community Leader NetBeans: http://community.java.net/netbeans > >> Desktop Java: > >> http://community.java.net/javadesktop > >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > >> * Duke's Choice Award Winner 2009 > >> * Blog: https://www.java.net//blog/sven > >> > >> * XING: https://www.xing.com/profile/Sven_Reimers8 > >> * LinkedIn: http://www.linkedin.com/in/svenreimers > >> > >> Join the NetBeans Groups: > >> * XING: http://www.xing.com/group-20148.82db20 > >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >> http://www.linkedin.com/groups?gid=107402 > >> http://www.linkedin.com/groups?gid=1684717 > >> * Oracle: https://mix.oracle.com/groups/18497 > >> > > > > > > > > -- > > Sven Reimers > > > > * Senior Expert Software Architect > > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > > * Community Leader NetBeans: http://community.java.net/netbeans > > Desktop Java: > > http://community.java.net/javadesktop > > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > > * Duke's Choice Award Winner 2009 > > * Blog: https://www.java.net//blog/sven > > > > * XING: https://www.xing.com/profile/Sven_Reimers8 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > > > > Join the NetBeans Groups: > > * XING: http://www.xing.com/group-20148.82db20 > > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > > http://www.linkedin.com/groups?gid=107402 > > http://www.linkedin.com/groups?gid=1684717 > > * Oracle: https://mix.oracle.com/groups/18497 > > From petr.pchelko at oracle.com Mon Mar 17 10:11:54 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 17 Mar 2014 14:11:54 +0400 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> Message-ID: Ok, I see. This is the problem in FX interop. In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that wraps the FX dragboard into the Swing Trasferable. It is a simple class and many features are simply not implemented. The implementation is very basic - it just creates the DataFlavor with the mime-type corresponding to the DataFormat mime-type. However it does not take into account the representation class. This works fine for basic types like text or may be image, but it completely does not work for custom types with custom representation classes. You could file a bug for this. With best regards. Petr. On 17.03.2014, at 13:39, Sven Reimers wrote: > The problem seems to be in AbstractDragSource in SceneBuilder. It defines a javafx.scene.input.DataFormat. > This seems to cause problems if running embedded in Swing. I do not define my own DataFlavors.. > > Any further help appreciated.. > > -Sven > > Am 17.03.2014 09:54 schrieb "Petr Pchelko" : > Hello, Sven. > > Looks like you are not specifying the representation class for the DataFlavor and it defaults > to the InputStream. So, scene builder puts a ByteBuffer while the DataTransferer is trying to treat it as an > InputStream. > > Could you please try to explicitly specify the representation class in the DataFlavor you are trying to put? > Like this: new DataFlavor("scene.builder/internal; class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") > > With best regards. Petr. > > On 17.03.2014, at 0:13, Sven Reimers wrote: > > > Ok... figured it out. It seems scene.builder.internal crashes the Swing > > parsing mechanism for mime types in the data transfer. Changing it to > > scene.builder/internal fixes this problem. > > > > Shall I open an issue in Jira for it? > > > > Having fixed this I get another problem :-( > > (see stacktrace below) > > > > Not sure how to fix this... investigating now. > > > > -Sven > > > > java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to > > java.io.InputStream > > at > > sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) > > at > > sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) > > at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) > > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > > at java.awt.EventQueue.access$400(EventQueue.java:97) > > at java.awt.EventQueue$3.run(EventQueue.java:697) > > at java.awt.EventQueue$3.run(EventQueue.java:691) > > at java.security.AccessController.doPrivileged(Native Method) > > at > > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > > at > > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) > > at java.awt.EventQueue$4.run(EventQueue.java:719) > > at java.awt.EventQueue$4.run(EventQueue.java:717) > > at java.security.AccessController.doPrivileged(Native Method) > > at > > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) > > at > > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) > > at > > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > > at > > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > > > > > On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers wrote: > > > >> Hi guys, > >> > >> hope someone can help me with the exception pasted below. > >> > >> Any idea how to go on from here? > >> > >> The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ > >> > >> Thanks > >> > >> -Sven > >> > >> java.lang.IllegalArgumentException: failed to parse:scene.builder.internal > >> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) > >> at > >> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) > >> at > >> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) > >> at > >> sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) > >> at > >> sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) > >> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) > >> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) > >> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) > >> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) > >> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) > >> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) > >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > >> at java.awt.EventQueue.access$400(EventQueue.java:97) > >> at java.awt.EventQueue$3.run(EventQueue.java:697) > >> at java.awt.EventQueue$3.run(EventQueue.java:691) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at > >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > >> at > >> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) > >> [catch] at > >> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > >> at > >> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > >> at > >> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > >> > >> -- > >> Sven Reimers > >> > >> * Senior Expert Software Architect > >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >> * Community Leader NetBeans: http://community.java.net/netbeans > >> Desktop Java: > >> http://community.java.net/javadesktop > >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > >> * Duke's Choice Award Winner 2009 > >> * Blog: https://www.java.net//blog/sven > >> > >> * XING: https://www.xing.com/profile/Sven_Reimers8 > >> * LinkedIn: http://www.linkedin.com/in/svenreimers > >> > >> Join the NetBeans Groups: > >> * XING: http://www.xing.com/group-20148.82db20 > >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >> http://www.linkedin.com/groups?gid=107402 > >> http://www.linkedin.com/groups?gid=1684717 > >> * Oracle: https://mix.oracle.com/groups/18497 > >> > > > > > > > > -- > > Sven Reimers > > > > * Senior Expert Software Architect > > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > > * Community Leader NetBeans: http://community.java.net/netbeans > > Desktop Java: > > http://community.java.net/javadesktop > > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > > * Duke's Choice Award Winner 2009 > > * Blog: https://www.java.net//blog/sven > > > > * XING: https://www.xing.com/profile/Sven_Reimers8 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > > > > Join the NetBeans Groups: > > * XING: http://www.xing.com/group-20148.82db20 > > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > > http://www.linkedin.com/groups?gid=107402 > > http://www.linkedin.com/groups?gid=1684717 > > * Oracle: https://mix.oracle.com/groups/18497 > From hang.vo at oracle.com Mon Mar 17 10:17:35 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 10:17:35 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35681: Rendering difference between platforms when specular map is used Message-ID: <201403171017.s2HAHkPC015493@aojmv0008> Changeset: a595dd55588f Author: vadim Date: 2014-03-17 14:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a595dd55588f RT-35681: Rendering difference between platforms when specular map is used Reviewed-by: ckyang ! modules/graphics/src/main/resources/com/sun/prism/es2/glsl/specular_mix.frag From sven.reimers at gmail.com Mon Mar 17 10:25:49 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 17 Mar 2014 11:25:49 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> Message-ID: Ok. Will file an issue and if possible create a patch. Any this could end up in 8u20 (or earlier)? Thanks -Sven Am 17.03.2014 11:05 schrieb "Petr Pchelko" : > Ok, I see. > > This is the problem in FX interop. > In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that > wraps the FX dragboard into the Swing Trasferable. > It is a simple class and many features are simply not implemented. The > implementation is very basic - it just creates the DataFlavor with the > mime-type corresponding to the DataFormat mime-type. However it does not > take into account the representation class. This works fine for basic types > like text or may be image, but it completely does not work for custom types > with custom representation classes. > > You could file a bug for this. > > With best regards. Petr. > > On 17.03.2014, at 13:39, Sven Reimers wrote: > > The problem seems to be in AbstractDragSource in SceneBuilder. It defines > a javafx.scene.input.DataFormat. > This seems to cause problems if running embedded in Swing. I do not define > my own DataFlavors.. > > Any further help appreciated.. > > -Sven > Am 17.03.2014 09:54 schrieb "Petr Pchelko" : > >> Hello, Sven. >> >> Looks like you are not specifying the representation class for the >> DataFlavor and it defaults >> to the InputStream. So, scene builder puts a ByteBuffer while the >> DataTransferer is trying to treat it as an >> InputStream. >> >> Could you please try to explicitly specify the representation class in >> the DataFlavor you are trying to put? >> Like this: new DataFlavor("scene.builder/internal; >> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") >> >> With best regards. Petr. >> >> On 17.03.2014, at 0:13, Sven Reimers wrote: >> >> > Ok... figured it out. It seems scene.builder.internal crashes the Swing >> > parsing mechanism for mime types in the data transfer. Changing it to >> > scene.builder/internal fixes this problem. >> > >> > Shall I open an issue in Jira for it? >> > >> > Having fixed this I get another problem :-( >> > (see stacktrace below) >> > >> > Not sure how to fix this... investigating now. >> > >> > -Sven >> > >> > java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to >> > java.io.InputStream >> > at >> > >> sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) >> > at >> > >> sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) >> > at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) >> > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >> > at java.awt.EventQueue.access$400(EventQueue.java:97) >> > at java.awt.EventQueue$3.run(EventQueue.java:697) >> > at java.awt.EventQueue$3.run(EventQueue.java:691) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at >> > >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> > at >> > >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) >> > at java.awt.EventQueue$4.run(EventQueue.java:719) >> > at java.awt.EventQueue$4.run(EventQueue.java:717) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at >> > >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> > at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) >> > at >> > >> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) >> > at >> > >> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >> > at >> > >> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >> > at >> > >> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >> > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >> > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> > >> > >> > On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers > >wrote: >> > >> >> Hi guys, >> >> >> >> hope someone can help me with the exception pasted below. >> >> >> >> Any idea how to go on from here? >> >> >> >> The code is available at >> https://bitbucket.org/sreimers/nbscenebuilder/ >> >> >> >> Thanks >> >> >> >> -Sven >> >> >> >> java.lang.IllegalArgumentException: failed to >> parse:scene.builder.internal >> >> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) >> >> at >> >> >> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) >> >> at >> >> >> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) >> >> at >> >> >> sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) >> >> at >> >> >> sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) >> >> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) >> >> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) >> >> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) >> >> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) >> >> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) >> >> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) >> >> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >> >> at java.awt.EventQueue.access$400(EventQueue.java:97) >> >> at java.awt.EventQueue$3.run(EventQueue.java:697) >> >> at java.awt.EventQueue$3.run(EventQueue.java:691) >> >> at java.security.AccessController.doPrivileged(Native Method) >> >> at >> >> >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >> >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >> >> at >> >> >> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) >> >> [catch] at >> >> >> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >> >> at >> >> >> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >> >> at >> >> >> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >> >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >> >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >> >> >> -- >> >> Sven Reimers >> >> >> >> * Senior Expert Software Architect >> >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >> * Community Leader NetBeans: http://community.java.net/netbeans >> >> Desktop Java: >> >> http://community.java.net/javadesktop >> >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> >> * Duke's Choice Award Winner 2009 >> >> * Blog: https://www.java.net//blog/sven >> >> >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> >> >> Join the NetBeans Groups: >> >> * XING: http://www.xing.com/group-20148.82db20 >> >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >> http://www.linkedin.com/groups?gid=107402 >> >> http://www.linkedin.com/groups?gid=1684717 >> >> * Oracle: https://mix.oracle.com/groups/18497 >> >> >> > >> > >> > >> > -- >> > Sven Reimers >> > >> > * Senior Expert Software Architect >> > * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> > * Community Leader NetBeans: http://community.java.net/netbeans >> > Desktop Java: >> > http://community.java.net/javadesktop >> > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> > * Duke's Choice Award Winner 2009 >> > * Blog: https://www.java.net//blog/sven >> > >> > * XING: https://www.xing.com/profile/Sven_Reimers8 >> > * LinkedIn: http://www.linkedin.com/in/svenreimers >> > >> > Join the NetBeans Groups: >> > * XING: http://www.xing.com/group-20148.82db20 >> > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> > http://www.linkedin.com/groups?gid=107402 >> > http://www.linkedin.com/groups?gid=1684717 >> > * Oracle: https://mix.oracle.com/groups/18497 >> >> > From vadim.pakhnushev at oracle.com Mon Mar 17 10:40:43 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 17 Mar 2014 14:40:43 +0400 Subject: [8u20] Review request for RT-36235: Zero specular power can lead to rendering artifacts. Message-ID: <5326D12B.5@oracle.com> Hi Chien, Kevin, Please review this fix: https://javafx-jira.kenai.com/browse/RT-36235 Thanks, Vadim From kevin.rushforth at oracle.com Mon Mar 17 12:10:13 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Mar 2014 05:10:13 -0700 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> Message-ID: <5326E625.3080807@oracle.com> Hi Sven, If you file the bug then yes, we can look at it for 8u20 (there is no "earlier"). And thanks to Petr for providing the evaluation for this. -- Kevin Sven Reimers wrote: > Ok. > > Will file an issue and if possible create a patch. > > Any this could end up in 8u20 (or earlier)? > > Thanks > > -Sven > Am 17.03.2014 11:05 schrieb "Petr Pchelko" : > > >> Ok, I see. >> >> This is the problem in FX interop. >> In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that >> wraps the FX dragboard into the Swing Trasferable. >> It is a simple class and many features are simply not implemented. The >> implementation is very basic - it just creates the DataFlavor with the >> mime-type corresponding to the DataFormat mime-type. However it does not >> take into account the representation class. This works fine for basic types >> like text or may be image, but it completely does not work for custom types >> with custom representation classes. >> >> You could file a bug for this. >> >> With best regards. Petr. >> >> On 17.03.2014, at 13:39, Sven Reimers wrote: >> >> The problem seems to be in AbstractDragSource in SceneBuilder. It defines >> a javafx.scene.input.DataFormat. >> This seems to cause problems if running embedded in Swing. I do not define >> my own DataFlavors.. >> >> Any further help appreciated.. >> >> -Sven >> Am 17.03.2014 09:54 schrieb "Petr Pchelko" : >> >> >>> Hello, Sven. >>> >>> Looks like you are not specifying the representation class for the >>> DataFlavor and it defaults >>> to the InputStream. So, scene builder puts a ByteBuffer while the >>> DataTransferer is trying to treat it as an >>> InputStream. >>> >>> Could you please try to explicitly specify the representation class in >>> the DataFlavor you are trying to put? >>> Like this: new DataFlavor("scene.builder/internal; >>> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") >>> >>> With best regards. Petr. >>> >>> On 17.03.2014, at 0:13, Sven Reimers wrote: >>> >>> >>>> Ok... figured it out. It seems scene.builder.internal crashes the Swing >>>> parsing mechanism for mime types in the data transfer. Changing it to >>>> scene.builder/internal fixes this problem. >>>> >>>> Shall I open an issue in Jira for it? >>>> >>>> Having fixed this I get another problem :-( >>>> (see stacktrace below) >>>> >>>> Not sure how to fix this... investigating now. >>>> >>>> -Sven >>>> >>>> java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to >>>> java.io.InputStream >>>> at >>>> >>>> >>> sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) >>> >>>> at >>>> >>>> >>> sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) >>> >>>> at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) >>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at >>>> >>>> >>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >>> >>>> at >>>> >>>> >>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) >>> >>>> at java.awt.EventQueue$4.run(EventQueue.java:719) >>>> at java.awt.EventQueue$4.run(EventQueue.java:717) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at >>>> >>>> >>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >>> >>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) >>>> at >>>> >>>> >>> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) >>> >>>> at >>>> >>>> >>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >>> >>>> at >>>> >>>> >>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >>> >>>> at >>>> >>>> >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >>> >>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >>>> >>>> >>>> On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers >>> wrote: >>>> >>>> >>>>> Hi guys, >>>>> >>>>> hope someone can help me with the exception pasted below. >>>>> >>>>> Any idea how to go on from here? >>>>> >>>>> The code is available at >>>>> >>> https://bitbucket.org/sreimers/nbscenebuilder/ >>> >>>>> Thanks >>>>> >>>>> -Sven >>>>> >>>>> java.lang.IllegalArgumentException: failed to >>>>> >>> parse:scene.builder.internal >>> >>>>> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) >>>>> at >>>>> >>>>> >>> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) >>> >>>>> at >>>>> >>>>> >>> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) >>> >>>>> at >>>>> >>>>> >>> sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) >>> >>>>> at >>>>> >>>>> >>> sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) >>> >>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) >>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) >>>>> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) >>>>> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) >>>>> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) >>>>> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) >>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at >>>>> >>>>> >>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) >>> >>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >>>>> at >>>>> >>>>> >>> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) >>> >>>>> [catch] at >>>>> >>>>> >>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >>> >>>>> at >>>>> >>>>> >>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >>> >>>>> at >>>>> >>>>> >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >>> >>>>> at >>>>> >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >>> >>>>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >>>>> >>>>> -- >>>>> Sven Reimers >>>>> >>>>> * Senior Expert Software Architect >>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>>> Desktop Java: >>>>> http://community.java.net/javadesktop >>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>>> * Duke's Choice Award Winner 2009 >>>>> * Blog: https://www.java.net//blog/sven >>>>> >>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>>> >>>>> Join the NetBeans Groups: >>>>> * XING: http://www.xing.com/group-20148.82db20 >>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>>> http://www.linkedin.com/groups?gid=107402 >>>>> http://www.linkedin.com/groups?gid=1684717 >>>>> * Oracle: https://mix.oracle.com/groups/18497 >>>>> >>>>> >>>> >>>> -- >>>> Sven Reimers >>>> >>>> * Senior Expert Software Architect >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>> Desktop Java: >>>> http://community.java.net/javadesktop >>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>> * Duke's Choice Award Winner 2009 >>>> * Blog: https://www.java.net//blog/sven >>>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>> >>>> Join the NetBeans Groups: >>>> * XING: http://www.xing.com/group-20148.82db20 >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>> http://www.linkedin.com/groups?gid=107402 >>>> http://www.linkedin.com/groups?gid=1684717 >>>> * Oracle: https://mix.oracle.com/groups/18497 >>>> >>> From hang.vo at oracle.com Mon Mar 17 12:32:39 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 12:32:39 +0000 Subject: hg: openjfx/8u-dev/rt: 3 new changesets Message-ID: <201403171233.s2HCX2YC004792@aojmv0008> Changeset: 6820d900774a Author: Martin Sladecek Date: 2014-03-17 13:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6820d900774a RT-36185 Custom TraversalEngine introduced in RT-36065 cannot delegate subtree traversal to the default traversal algorithm Reviewed by: dgrieve ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/Algorithm.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/Direction.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/Hueristic2D.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TabOrderHelper.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TopMostTraversalEngine.java + modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TraversalContext.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TraversalEngine.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/WeightedClosestCorner.java ! modules/web/src/main/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java Changeset: c0d5845f82d5 Author: kcr Date: 2014-03-17 05:28 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c0d5845f82d5 RT-36141: Gtk: SecurityException using WebView when running app with security manager Reviewed-by: anthony ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java Changeset: 73f0beec1171 Author: kcr Date: 2014-03-17 05:28 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/73f0beec1171 RT-36232: [Quantum] SecurityException on exit when running any FX program with security manager Reviewed-by: felipe, anthony ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java From hang.vo at oracle.com Mon Mar 17 13:03:11 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 13:03:11 +0000 Subject: hg: openjfx/8u-dev/rt: RT-34283: [Swing] Drag&Drop with interop on Mac OS X between two processes does not transfer data Message-ID: <201403171303.s2HD3MWL009675@aojmv0008> Changeset: c7f043d40430 Author: Anthony Petrov Date: 2014-03-17 16:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c7f043d40430 RT-34283: [Swing] Drag&Drop with interop on Mac OS X between two processes does not transfer data Summary: Cache the drop result in dragOver() handler, and use it in drop() to fetch data Reviewed-by: pchelko ! modules/swing/src/main/java/javafx/embed/swing/DataFlavorUtils.java ! modules/swing/src/main/java/javafx/embed/swing/SwingDnD.java ! modules/swing/src/main/java/javafx/embed/swing/SwingDragSource.java From sven.reimers at gmail.com Mon Mar 17 13:49:45 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 17 Mar 2014 14:49:45 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: <5326E625.3080807@oracle.com> References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> <5326E625.3080807@oracle.com> Message-ID: Created RT-36240 -Sven Am 17.03.2014 13:10 schrieb "Kevin Rushforth" : > Hi Sven, > > If you file the bug then yes, we can look at it for 8u20 (there is no > "earlier"). > > And thanks to Petr for providing the evaluation for this. > > -- Kevin > > > Sven Reimers wrote: > >> Ok. >> >> Will file an issue and if possible create a patch. >> >> Any this could end up in 8u20 (or earlier)? >> >> Thanks >> >> -Sven >> Am 17.03.2014 11:05 schrieb "Petr Pchelko" : >> >> >> >>> Ok, I see. >>> >>> This is the problem in FX interop. >>> In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that >>> wraps the FX dragboard into the Swing Trasferable. >>> It is a simple class and many features are simply not implemented. The >>> implementation is very basic - it just creates the DataFlavor with the >>> mime-type corresponding to the DataFormat mime-type. However it does not >>> take into account the representation class. This works fine for basic >>> types >>> like text or may be image, but it completely does not work for custom >>> types >>> with custom representation classes. >>> >>> You could file a bug for this. >>> >>> With best regards. Petr. >>> >>> On 17.03.2014, at 13:39, Sven Reimers wrote: >>> >>> The problem seems to be in AbstractDragSource in SceneBuilder. It defines >>> a javafx.scene.input.DataFormat. >>> This seems to cause problems if running embedded in Swing. I do not >>> define >>> my own DataFlavors.. >>> >>> Any further help appreciated.. >>> >>> -Sven >>> Am 17.03.2014 09:54 schrieb "Petr Pchelko" : >>> >>> >>> >>>> Hello, Sven. >>>> >>>> Looks like you are not specifying the representation class for the >>>> DataFlavor and it defaults >>>> to the InputStream. So, scene builder puts a ByteBuffer while the >>>> DataTransferer is trying to treat it as an >>>> InputStream. >>>> >>>> Could you please try to explicitly specify the representation class in >>>> the DataFlavor you are trying to put? >>>> Like this: new DataFlavor("scene.builder/internal; >>>> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") >>>> >>>> With best regards. Petr. >>>> >>>> On 17.03.2014, at 0:13, Sven Reimers wrote: >>>> >>>> >>>> >>>>> Ok... figured it out. It seems scene.builder.internal crashes the Swing >>>>> parsing mechanism for mime types in the data transfer. Changing it to >>>>> scene.builder/internal fixes this problem. >>>>> >>>>> Shall I open an issue in Jira for it? >>>>> >>>>> Having fixed this I get another problem :-( >>>>> (see stacktrace below) >>>>> >>>>> Not sure how to fix this... investigating now. >>>>> >>>>> -Sven >>>>> >>>>> java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to >>>>> java.io.InputStream >>>>> at >>>>> >>>>> >>>>> >>>> sun.awt.datatransfer.DataTransferer.translateTransferable( >>>> DataTransferer.java:1372) >>>> >>>> >>>>> at >>>>> >>>>> >>>>> >>>> sun.lwawt.macosx.CDataTransferer.translateTransferable( >>>> CDataTransferer.java:131) >>>> >>>> >>>>> at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) >>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at >>>>> >>>>> >>>>> >>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>> ProtectionDomain.java:75) >>>> >>>> >>>>> at >>>>> >>>>> >>>>> >>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>> ProtectionDomain.java:86) >>>> >>>> >>>>> at java.awt.EventQueue$4.run(EventQueue.java:719) >>>>> at java.awt.EventQueue$4.run(EventQueue.java:717) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at >>>>> >>>>> >>>>> >>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>> ProtectionDomain.java:75) >>>> >>>> >>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) >>>>> at >>>>> >>>>> >>>>> >>>> org.netbeans.core.TimableEventQueue.dispatchEvent( >>>> TimableEventQueue.java:159) >>>> >>>> >>>>> at >>>>> >>>>> >>>>> >>>> java.awt.EventDispatchThread.pumpOneEventForFilters( >>>> EventDispatchThread.java:201) >>>> >>>> >>>>> at >>>>> >>>>> >>>>> >>>> java.awt.EventDispatchThread.pumpEventsForFilter( >>>> EventDispatchThread.java:116) >>>> >>>> >>>>> at >>>>> >>>>> >>>>> >>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( >>>> EventDispatchThread.java:105) >>>> >>>> >>>>> at java.awt.EventDispatchThread.pumpEvents( >>>>> EventDispatchThread.java:101) >>>>> at java.awt.EventDispatchThread.pumpEvents( >>>>> EventDispatchThread.java:93) >>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >>>>> >>>>> >>>>> On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers >>>> wrote: >>>>> >>>>> >>>>> >>>>>> Hi guys, >>>>>> >>>>>> hope someone can help me with the exception pasted below. >>>>>> >>>>>> Any idea how to go on from here? >>>>>> >>>>>> The code is available at >>>>>> >>>>>> >>>>> https://bitbucket.org/sreimers/nbscenebuilder/ >>>> >>>> >>>>> Thanks >>>>>> >>>>>> -Sven >>>>>> >>>>>> java.lang.IllegalArgumentException: failed to >>>>>> >>>>>> >>>>> parse:scene.builder.internal >>>> >>>> >>>>> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors( >>>> SwingDnD.java:398) >>>> >>>> >>>>> at >>>>>> >>>>>> >>>>>> >>>>> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable( >>>> DataTransferer.java:655) >>>> >>>> >>>>> at >>>>>> >>>>>> >>>>>> >>>>> sun.awt.dnd.SunDragSourceContextPeer.startDrag( >>>> SunDragSourceContextPeer.java:131) >>>> >>>> >>>>> at >>>>>> >>>>>> >>>>>> >>>>> sun.lwawt.macosx.CDragSourceContextPeer.startDrag( >>>> CDragSourceContextPeer.java:88) >>>> >>>> >>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) >>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) >>>>>> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) >>>>>> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) >>>>>> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) >>>>>> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) >>>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>> ProtectionDomain.java:75) >>>> >>>> >>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( >>>> TimableEventQueue.java:159) >>>> >>>> >>>>> [catch] at >>>>>> >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( >>>> EventDispatchThread.java:201) >>>> >>>> >>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpEventsForFilter( >>>> EventDispatchThread.java:116) >>>> >>>> >>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( >>>> EventDispatchThread.java:105) >>>> >>>> >>>>> at >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >>>> >>>> >>>>> at java.awt.EventDispatchThread.pumpEvents( >>>>>> EventDispatchThread.java:93) >>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >>>>>> >>>>>> -- >>>>>> Sven Reimers >>>>>> >>>>>> * Senior Expert Software Architect >>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>>>> Desktop Java: >>>>>> http://community.java.net/javadesktop >>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>>>> * Duke's Choice Award Winner 2009 >>>>>> * Blog: https://www.java.net//blog/sven >>>>>> >>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>>>> >>>>>> Join the NetBeans Groups: >>>>>> * XING: http://www.xing.com/group-20148.82db20 >>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>>>> http://www.linkedin.com/groups?gid=107402 >>>>>> http://www.linkedin.com/groups?gid=1684717 >>>>>> * Oracle: https://mix.oracle.com/groups/18497 >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Sven Reimers >>>>> >>>>> * Senior Expert Software Architect >>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>>> Desktop Java: >>>>> http://community.java.net/javadesktop >>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>>> * Duke's Choice Award Winner 2009 >>>>> * Blog: https://www.java.net//blog/sven >>>>> >>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>>> >>>>> Join the NetBeans Groups: >>>>> * XING: http://www.xing.com/group-20148.82db20 >>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>>> http://www.linkedin.com/groups?gid=107402 >>>>> http://www.linkedin.com/groups?gid=1684717 >>>>> * Oracle: https://mix.oracle.com/groups/18497 >>>>> >>>>> >>>> >>>> >>> From eric.le.ponner at oracle.com Mon Mar 17 14:32:37 2014 From: eric.le.ponner at oracle.com (Eric Le Ponner) Date: Mon, 17 Mar 2014 15:32:37 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> <5326E625.3080807@oracle.com> Message-ID: Hi Sven, As you mentioned, some fixes are also required at SB level (the strings passed to DataFormat). I'm going to file a JIRA against Scene Builder for that. I did a sample Swing test with Scene Builder Kit and reproduced the exception reported in RT-36240. However it seems that this exception does not prevent SB to complete its drag and drop gestures. Does it match what you've observed ? Cheers. Eric Le 17 mars 2014 ? 14:49, Sven Reimers a ?crit : > Created RT-36240 > > -Sven > Am 17.03.2014 13:10 schrieb "Kevin Rushforth" : > >> Hi Sven, >> >> If you file the bug then yes, we can look at it for 8u20 (there is no >> "earlier"). >> >> And thanks to Petr for providing the evaluation for this. >> >> -- Kevin >> >> >> Sven Reimers wrote: >> >>> Ok. >>> >>> Will file an issue and if possible create a patch. >>> >>> Any this could end up in 8u20 (or earlier)? >>> >>> Thanks >>> >>> -Sven >>> Am 17.03.2014 11:05 schrieb "Petr Pchelko" : >>> >>> >>> >>>> Ok, I see. >>>> >>>> This is the problem in FX interop. >>>> In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that >>>> wraps the FX dragboard into the Swing Trasferable. >>>> It is a simple class and many features are simply not implemented. The >>>> implementation is very basic - it just creates the DataFlavor with the >>>> mime-type corresponding to the DataFormat mime-type. However it does not >>>> take into account the representation class. This works fine for basic >>>> types >>>> like text or may be image, but it completely does not work for custom >>>> types >>>> with custom representation classes. >>>> >>>> You could file a bug for this. >>>> >>>> With best regards. Petr. >>>> >>>> On 17.03.2014, at 13:39, Sven Reimers wrote: >>>> >>>> The problem seems to be in AbstractDragSource in SceneBuilder. It defines >>>> a javafx.scene.input.DataFormat. >>>> This seems to cause problems if running embedded in Swing. I do not >>>> define >>>> my own DataFlavors.. >>>> >>>> Any further help appreciated.. >>>> >>>> -Sven >>>> Am 17.03.2014 09:54 schrieb "Petr Pchelko" : >>>> >>>> >>>> >>>>> Hello, Sven. >>>>> >>>>> Looks like you are not specifying the representation class for the >>>>> DataFlavor and it defaults >>>>> to the InputStream. So, scene builder puts a ByteBuffer while the >>>>> DataTransferer is trying to treat it as an >>>>> InputStream. >>>>> >>>>> Could you please try to explicitly specify the representation class in >>>>> the DataFlavor you are trying to put? >>>>> Like this: new DataFlavor("scene.builder/internal; >>>>> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") >>>>> >>>>> With best regards. Petr. >>>>> >>>>> On 17.03.2014, at 0:13, Sven Reimers wrote: >>>>> >>>>> >>>>> >>>>>> Ok... figured it out. It seems scene.builder.internal crashes the Swing >>>>>> parsing mechanism for mime types in the data transfer. Changing it to >>>>>> scene.builder/internal fixes this problem. >>>>>> >>>>>> Shall I open an issue in Jira for it? >>>>>> >>>>>> Having fixed this I get another problem :-( >>>>>> (see stacktrace below) >>>>>> >>>>>> Not sure how to fix this... investigating now. >>>>>> >>>>>> -Sven >>>>>> >>>>>> java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to >>>>>> java.io.InputStream >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> sun.awt.datatransfer.DataTransferer.translateTransferable( >>>>> DataTransferer.java:1372) >>>>> >>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> sun.lwawt.macosx.CDataTransferer.translateTransferable( >>>>> CDataTransferer.java:131) >>>>> >>>>> >>>>>> at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) >>>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>>> ProtectionDomain.java:75) >>>>> >>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>>> ProtectionDomain.java:86) >>>>> >>>>> >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:719) >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:717) >>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>>> ProtectionDomain.java:75) >>>>> >>>>> >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( >>>>> TimableEventQueue.java:159) >>>>> >>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( >>>>> EventDispatchThread.java:201) >>>>> >>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpEventsForFilter( >>>>> EventDispatchThread.java:116) >>>>> >>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( >>>>> EventDispatchThread.java:105) >>>>> >>>>> >>>>>> at java.awt.EventDispatchThread.pumpEvents( >>>>>> EventDispatchThread.java:101) >>>>>> at java.awt.EventDispatchThread.pumpEvents( >>>>>> EventDispatchThread.java:93) >>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >>>>>> >>>>>> >>>>>> On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> hope someone can help me with the exception pasted below. >>>>>>> >>>>>>> Any idea how to go on from here? >>>>>>> >>>>>>> The code is available at >>>>>>> >>>>>>> >>>>>> https://bitbucket.org/sreimers/nbscenebuilder/ >>>>> >>>>> >>>>>> Thanks >>>>>>> >>>>>>> -Sven >>>>>>> >>>>>>> java.lang.IllegalArgumentException: failed to >>>>>>> >>>>>>> >>>>>> parse:scene.builder.internal >>>>> >>>>> >>>>>> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors( >>>>> SwingDnD.java:398) >>>>> >>>>> >>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable( >>>>> DataTransferer.java:655) >>>>> >>>>> >>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> sun.awt.dnd.SunDragSourceContextPeer.startDrag( >>>>> SunDragSourceContextPeer.java:131) >>>>> >>>>> >>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> sun.lwawt.macosx.CDragSourceContextPeer.startDrag( >>>>> CDragSourceContextPeer.java:88) >>>>> >>>>> >>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) >>>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) >>>>>>> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) >>>>>>> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) >>>>>>> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) >>>>>>> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) >>>>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >>>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >>>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >>>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >>>>> ProtectionDomain.java:75) >>>>> >>>>> >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( >>>>> TimableEventQueue.java:159) >>>>> >>>>> >>>>>> [catch] at >>>>>>> >>>>>>> >>>>>>> >>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( >>>>> EventDispatchThread.java:201) >>>>> >>>>> >>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> java.awt.EventDispatchThread.pumpEventsForFilter( >>>>> EventDispatchThread.java:116) >>>>> >>>>> >>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( >>>>> EventDispatchThread.java:105) >>>>> >>>>> >>>>>> at >>>>>>> >>>>>>> >>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >>>>> >>>>> >>>>>> at java.awt.EventDispatchThread.pumpEvents( >>>>>>> EventDispatchThread.java:93) >>>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >>>>>>> >>>>>>> -- >>>>>>> Sven Reimers >>>>>>> >>>>>>> * Senior Expert Software Architect >>>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>>>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>>>>> Desktop Java: >>>>>>> http://community.java.net/javadesktop >>>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>>>>> * Duke's Choice Award Winner 2009 >>>>>>> * Blog: https://www.java.net//blog/sven >>>>>>> >>>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>>>>> >>>>>>> Join the NetBeans Groups: >>>>>>> * XING: http://www.xing.com/group-20148.82db20 >>>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>>>>> http://www.linkedin.com/groups?gid=107402 >>>>>>> http://www.linkedin.com/groups?gid=1684717 >>>>>>> * Oracle: https://mix.oracle.com/groups/18497 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Sven Reimers >>>>>> >>>>>> * Senior Expert Software Architect >>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>>>> Desktop Java: >>>>>> http://community.java.net/javadesktop >>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>>>> * Duke's Choice Award Winner 2009 >>>>>> * Blog: https://www.java.net//blog/sven >>>>>> >>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>>>> >>>>>> Join the NetBeans Groups: >>>>>> * XING: http://www.xing.com/group-20148.82db20 >>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>>>> http://www.linkedin.com/groups?gid=107402 >>>>>> http://www.linkedin.com/groups?gid=1684717 >>>>>> * Oracle: https://mix.oracle.com/groups/18497 >>>>>> >>>>>> >>>>> >>>>> >>>> From sven.reimers at gmail.com Mon Mar 17 15:10:56 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 17 Mar 2014 16:10:56 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> <5326E625.3080807@oracle.com> Message-ID: Yes, I can confirm everything looks ok.. but exceptions all over the place don't make feel comfortable... This is with fixed DataFormat String.. Thanks -Sven Am 17.03.2014 15:32 schrieb "Eric Le Ponner" : > Hi Sven, > > As you mentioned, some fixes are also required at SB level (the strings > passed to DataFormat). > I'm going to file a JIRA against Scene Builder for that. > > I did a sample Swing test with Scene Builder Kit and reproduced the > exception > reported in RT-36240. However it seems that this exception does not prevent > SB to complete its drag and drop gestures. Does it match what you've > observed ? > > Cheers. > > Eric > > > > Le 17 mars 2014 ? 14:49, Sven Reimers a ?crit : > > > Created RT-36240 > > > > -Sven > > Am 17.03.2014 13:10 schrieb "Kevin Rushforth" < > kevin.rushforth at oracle.com>: > > > >> Hi Sven, > >> > >> If you file the bug then yes, we can look at it for 8u20 (there is no > >> "earlier"). > >> > >> And thanks to Petr for providing the evaluation for this. > >> > >> -- Kevin > >> > >> > >> Sven Reimers wrote: > >> > >>> Ok. > >>> > >>> Will file an issue and if possible create a patch. > >>> > >>> Any this could end up in 8u20 (or earlier)? > >>> > >>> Thanks > >>> > >>> -Sven > >>> Am 17.03.2014 11:05 schrieb "Petr Pchelko" : > >>> > >>> > >>> > >>>> Ok, I see. > >>>> > >>>> This is the problem in FX interop. > >>>> In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper > that > >>>> wraps the FX dragboard into the Swing Trasferable. > >>>> It is a simple class and many features are simply not implemented. The > >>>> implementation is very basic - it just creates the DataFlavor with the > >>>> mime-type corresponding to the DataFormat mime-type. However it does > not > >>>> take into account the representation class. This works fine for basic > >>>> types > >>>> like text or may be image, but it completely does not work for custom > >>>> types > >>>> with custom representation classes. > >>>> > >>>> You could file a bug for this. > >>>> > >>>> With best regards. Petr. > >>>> > >>>> On 17.03.2014, at 13:39, Sven Reimers wrote: > >>>> > >>>> The problem seems to be in AbstractDragSource in SceneBuilder. It > defines > >>>> a javafx.scene.input.DataFormat. > >>>> This seems to cause problems if running embedded in Swing. I do not > >>>> define > >>>> my own DataFlavors.. > >>>> > >>>> Any further help appreciated.. > >>>> > >>>> -Sven > >>>> Am 17.03.2014 09:54 schrieb "Petr Pchelko" : > >>>> > >>>> > >>>> > >>>>> Hello, Sven. > >>>>> > >>>>> Looks like you are not specifying the representation class for the > >>>>> DataFlavor and it defaults > >>>>> to the InputStream. So, scene builder puts a ByteBuffer while the > >>>>> DataTransferer is trying to treat it as an > >>>>> InputStream. > >>>>> > >>>>> Could you please try to explicitly specify the representation class > in > >>>>> the DataFlavor you are trying to put? > >>>>> Like this: new DataFlavor("scene.builder/internal; > >>>>> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") > >>>>> > >>>>> With best regards. Petr. > >>>>> > >>>>> On 17.03.2014, at 0:13, Sven Reimers wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Ok... figured it out. It seems scene.builder.internal crashes the > Swing > >>>>>> parsing mechanism for mime types in the data transfer. Changing it > to > >>>>>> scene.builder/internal fixes this problem. > >>>>>> > >>>>>> Shall I open an issue in Jira for it? > >>>>>> > >>>>>> Having fixed this I get another problem :-( > >>>>>> (see stacktrace below) > >>>>>> > >>>>>> Not sure how to fix this... investigating now. > >>>>>> > >>>>>> -Sven > >>>>>> > >>>>>> java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be > cast to > >>>>>> java.io.InputStream > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> sun.awt.datatransfer.DataTransferer.translateTransferable( > >>>>> DataTransferer.java:1372) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> sun.lwawt.macosx.CDataTransferer.translateTransferable( > >>>>> CDataTransferer.java:131) > >>>>> > >>>>> > >>>>>> at > sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) > >>>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > >>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > >>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) > >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) > >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) > >>>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:75) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:86) > >>>>> > >>>>> > >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:719) > >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:717) > >>>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:75) > >>>>> > >>>>> > >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( > >>>>> TimableEventQueue.java:159) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( > >>>>> EventDispatchThread.java:201) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.awt.EventDispatchThread.pumpEventsForFilter( > >>>>> EventDispatchThread.java:116) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( > >>>>> EventDispatchThread.java:105) > >>>>> > >>>>> > >>>>>> at java.awt.EventDispatchThread.pumpEvents( > >>>>>> EventDispatchThread.java:101) > >>>>>> at java.awt.EventDispatchThread.pumpEvents( > >>>>>> EventDispatchThread.java:93) > >>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > >>>>>> > >>>>>> > >>>>>> On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers < > sven.reimers at gmail.com > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi guys, > >>>>>>> > >>>>>>> hope someone can help me with the exception pasted below. > >>>>>>> > >>>>>>> Any idea how to go on from here? > >>>>>>> > >>>>>>> The code is available at > >>>>>>> > >>>>>>> > >>>>>> https://bitbucket.org/sreimers/nbscenebuilder/ > >>>>> > >>>>> > >>>>>> Thanks > >>>>>>> > >>>>>>> -Sven > >>>>>>> > >>>>>>> java.lang.IllegalArgumentException: failed to > >>>>>>> > >>>>>>> > >>>>>> parse:scene.builder.internal > >>>>> > >>>>> > >>>>>> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors( > >>>>> SwingDnD.java:398) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable( > >>>>> DataTransferer.java:655) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> sun.awt.dnd.SunDragSourceContextPeer.startDrag( > >>>>> SunDragSourceContextPeer.java:131) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> sun.lwawt.macosx.CDragSourceContextPeer.startDrag( > >>>>> CDragSourceContextPeer.java:88) > >>>>> > >>>>> > >>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) > >>>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) > >>>>>>> at > java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) > >>>>>>> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) > >>>>>>> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) > >>>>>>> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) > >>>>>>> at > java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > >>>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > >>>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) > >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) > >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) > >>>>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:75) > >>>>> > >>>>> > >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( > >>>>> TimableEventQueue.java:159) > >>>>> > >>>>> > >>>>>> [catch] at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( > >>>>> EventDispatchThread.java:201) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpEventsForFilter( > >>>>> EventDispatchThread.java:116) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( > >>>>> EventDispatchThread.java:105) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > >>>>> > >>>>> > >>>>>> at java.awt.EventDispatchThread.pumpEvents( > >>>>>>> EventDispatchThread.java:93) > >>>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > >>>>>>> > >>>>>>> -- > >>>>>>> Sven Reimers > >>>>>>> > >>>>>>> * Senior Expert Software Architect > >>>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>>>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>>>>> Desktop Java: > >>>>>>> http://community.java.net/javadesktop > >>>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > >>>>>>> * Duke's Choice Award Winner 2009 > >>>>>>> * Blog: https://www.java.net//blog/sven > >>>>>>> > >>>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>>>>> > >>>>>>> Join the NetBeans Groups: > >>>>>>> * XING: http://www.xing.com/group-20148.82db20 > >>>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>>>>> http://www.linkedin.com/groups?gid=107402 > >>>>>>> http://www.linkedin.com/groups?gid=1684717 > >>>>>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Sven Reimers > >>>>>> > >>>>>> * Senior Expert Software Architect > >>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>>>> Desktop Java: > >>>>>> http://community.java.net/javadesktop > >>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > >>>>>> * Duke's Choice Award Winner 2009 > >>>>>> * Blog: https://www.java.net//blog/sven > >>>>>> > >>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>>>> > >>>>>> Join the NetBeans Groups: > >>>>>> * XING: http://www.xing.com/group-20148.82db20 > >>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>>>> http://www.linkedin.com/groups?gid=107402 > >>>>>> http://www.linkedin.com/groups?gid=1684717 > >>>>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > > From eric.le.ponner at oracle.com Mon Mar 17 15:52:51 2014 From: eric.le.ponner at oracle.com (Eric Le Ponner) Date: Mon, 17 Mar 2014 16:52:51 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> <5326E625.3080807@oracle.com> Message-ID: <993B27A8-0335-4B9B-910F-C0F4BE9208ED@oracle.com> Le 17 mars 2014 ? 16:10, Sven Reimers a ?crit : > Yes, I can confirm everything looks ok.. but exceptions all over the place don't make feel comfortable... > > Sure. I created DTL-6648 to track issue at Scene Builder level. Eric > This is with fixed DataFormat String.. > > Thanks > > -Sven > > Am 17.03.2014 15:32 schrieb "Eric Le Ponner" : > Hi Sven, > > As you mentioned, some fixes are also required at SB level (the strings passed to DataFormat). > I'm going to file a JIRA against Scene Builder for that. > > I did a sample Swing test with Scene Builder Kit and reproduced the exception > reported in RT-36240. However it seems that this exception does not prevent > SB to complete its drag and drop gestures. Does it match what you've observed ? > > Cheers. > > Eric > > > > Le 17 mars 2014 ? 14:49, Sven Reimers a ?crit : > > > Created RT-36240 > > > > -Sven > > Am 17.03.2014 13:10 schrieb "Kevin Rushforth" : > > > >> Hi Sven, > >> > >> If you file the bug then yes, we can look at it for 8u20 (there is no > >> "earlier"). > >> > >> And thanks to Petr for providing the evaluation for this. > >> > >> -- Kevin > >> > >> > >> Sven Reimers wrote: > >> > >>> Ok. > >>> > >>> Will file an issue and if possible create a patch. > >>> > >>> Any this could end up in 8u20 (or earlier)? > >>> > >>> Thanks > >>> > >>> -Sven > >>> Am 17.03.2014 11:05 schrieb "Petr Pchelko" : > >>> > >>> > >>> > >>>> Ok, I see. > >>>> > >>>> This is the problem in FX interop. > >>>> In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that > >>>> wraps the FX dragboard into the Swing Trasferable. > >>>> It is a simple class and many features are simply not implemented. The > >>>> implementation is very basic - it just creates the DataFlavor with the > >>>> mime-type corresponding to the DataFormat mime-type. However it does not > >>>> take into account the representation class. This works fine for basic > >>>> types > >>>> like text or may be image, but it completely does not work for custom > >>>> types > >>>> with custom representation classes. > >>>> > >>>> You could file a bug for this. > >>>> > >>>> With best regards. Petr. > >>>> > >>>> On 17.03.2014, at 13:39, Sven Reimers wrote: > >>>> > >>>> The problem seems to be in AbstractDragSource in SceneBuilder. It defines > >>>> a javafx.scene.input.DataFormat. > >>>> This seems to cause problems if running embedded in Swing. I do not > >>>> define > >>>> my own DataFlavors.. > >>>> > >>>> Any further help appreciated.. > >>>> > >>>> -Sven > >>>> Am 17.03.2014 09:54 schrieb "Petr Pchelko" : > >>>> > >>>> > >>>> > >>>>> Hello, Sven. > >>>>> > >>>>> Looks like you are not specifying the representation class for the > >>>>> DataFlavor and it defaults > >>>>> to the InputStream. So, scene builder puts a ByteBuffer while the > >>>>> DataTransferer is trying to treat it as an > >>>>> InputStream. > >>>>> > >>>>> Could you please try to explicitly specify the representation class in > >>>>> the DataFlavor you are trying to put? > >>>>> Like this: new DataFlavor("scene.builder/internal; > >>>>> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") > >>>>> > >>>>> With best regards. Petr. > >>>>> > >>>>> On 17.03.2014, at 0:13, Sven Reimers wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Ok... figured it out. It seems scene.builder.internal crashes the Swing > >>>>>> parsing mechanism for mime types in the data transfer. Changing it to > >>>>>> scene.builder/internal fixes this problem. > >>>>>> > >>>>>> Shall I open an issue in Jira for it? > >>>>>> > >>>>>> Having fixed this I get another problem :-( > >>>>>> (see stacktrace below) > >>>>>> > >>>>>> Not sure how to fix this... investigating now. > >>>>>> > >>>>>> -Sven > >>>>>> > >>>>>> java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to > >>>>>> java.io.InputStream > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> sun.awt.datatransfer.DataTransferer.translateTransferable( > >>>>> DataTransferer.java:1372) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> sun.lwawt.macosx.CDataTransferer.translateTransferable( > >>>>> CDataTransferer.java:131) > >>>>> > >>>>> > >>>>>> at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) > >>>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > >>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > >>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) > >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) > >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) > >>>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:75) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:86) > >>>>> > >>>>> > >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:719) > >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:717) > >>>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:75) > >>>>> > >>>>> > >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( > >>>>> TimableEventQueue.java:159) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( > >>>>> EventDispatchThread.java:201) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.awt.EventDispatchThread.pumpEventsForFilter( > >>>>> EventDispatchThread.java:116) > >>>>> > >>>>> > >>>>>> at > >>>>>> > >>>>>> > >>>>>> > >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( > >>>>> EventDispatchThread.java:105) > >>>>> > >>>>> > >>>>>> at java.awt.EventDispatchThread.pumpEvents( > >>>>>> EventDispatchThread.java:101) > >>>>>> at java.awt.EventDispatchThread.pumpEvents( > >>>>>> EventDispatchThread.java:93) > >>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > >>>>>> > >>>>>> > >>>>>> On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi guys, > >>>>>>> > >>>>>>> hope someone can help me with the exception pasted below. > >>>>>>> > >>>>>>> Any idea how to go on from here? > >>>>>>> > >>>>>>> The code is available at > >>>>>>> > >>>>>>> > >>>>>> https://bitbucket.org/sreimers/nbscenebuilder/ > >>>>> > >>>>> > >>>>>> Thanks > >>>>>>> > >>>>>>> -Sven > >>>>>>> > >>>>>>> java.lang.IllegalArgumentException: failed to > >>>>>>> > >>>>>>> > >>>>>> parse:scene.builder.internal > >>>>> > >>>>> > >>>>>> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors( > >>>>> SwingDnD.java:398) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable( > >>>>> DataTransferer.java:655) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> sun.awt.dnd.SunDragSourceContextPeer.startDrag( > >>>>> SunDragSourceContextPeer.java:131) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> sun.lwawt.macosx.CDragSourceContextPeer.startDrag( > >>>>> CDragSourceContextPeer.java:88) > >>>>> > >>>>> > >>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) > >>>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) > >>>>>>> at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) > >>>>>>> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) > >>>>>>> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) > >>>>>>> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) > >>>>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > >>>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > >>>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) > >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) > >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) > >>>>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( > >>>>> ProtectionDomain.java:75) > >>>>> > >>>>> > >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > >>>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( > >>>>> TimableEventQueue.java:159) > >>>>> > >>>>> > >>>>>> [catch] at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( > >>>>> EventDispatchThread.java:201) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpEventsForFilter( > >>>>> EventDispatchThread.java:116) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( > >>>>> EventDispatchThread.java:105) > >>>>> > >>>>> > >>>>>> at > >>>>>>> > >>>>>>> > >>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > >>>>> > >>>>> > >>>>>> at java.awt.EventDispatchThread.pumpEvents( > >>>>>>> EventDispatchThread.java:93) > >>>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > >>>>>>> > >>>>>>> -- > >>>>>>> Sven Reimers > >>>>>>> > >>>>>>> * Senior Expert Software Architect > >>>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>>>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>>>>> Desktop Java: > >>>>>>> http://community.java.net/javadesktop > >>>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > >>>>>>> * Duke's Choice Award Winner 2009 > >>>>>>> * Blog: https://www.java.net//blog/sven > >>>>>>> > >>>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>>>>> > >>>>>>> Join the NetBeans Groups: > >>>>>>> * XING: http://www.xing.com/group-20148.82db20 > >>>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>>>>> http://www.linkedin.com/groups?gid=107402 > >>>>>>> http://www.linkedin.com/groups?gid=1684717 > >>>>>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Sven Reimers > >>>>>> > >>>>>> * Senior Expert Software Architect > >>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>>>> Desktop Java: > >>>>>> http://community.java.net/javadesktop > >>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > >>>>>> * Duke's Choice Award Winner 2009 > >>>>>> * Blog: https://www.java.net//blog/sven > >>>>>> > >>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>>>> > >>>>>> Join the NetBeans Groups: > >>>>>> * XING: http://www.xing.com/group-20148.82db20 > >>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>>>> http://www.linkedin.com/groups?gid=107402 > >>>>>> http://www.linkedin.com/groups?gid=1684717 > >>>>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > From sven.reimers at gmail.com Mon Mar 17 15:54:35 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 17 Mar 2014 16:54:35 +0100 Subject: SceneBuilder Integration in NetBeans In-Reply-To: <993B27A8-0335-4B9B-910F-C0F4BE9208ED@oracle.com> References: <5696927D-4E4E-4944-9C1F-B1EDE7D34143@oracle.com> <5326E625.3080807@oracle.com> <993B27A8-0335-4B9B-910F-C0F4BE9208ED@oracle.com> Message-ID: Watching it now :-) Thanks -Sven Am 17.03.2014 16:52 schrieb "Eric Le Ponner" : > Le 17 mars 2014 ? 16:10, Sven Reimers a ?crit : > > Yes, I can confirm everything looks ok.. but exceptions all over the place > don't make feel comfortable... > > > Sure. > I created DTL-6648 to track issue at Scene Builder level. > > Eric > > This is with fixed DataFormat String.. > > Thanks > > -Sven > Am 17.03.2014 15:32 schrieb "Eric Le Ponner" : > >> Hi Sven, >> >> As you mentioned, some fixes are also required at SB level (the strings >> passed to DataFormat). >> I'm going to file a JIRA against Scene Builder for that. >> >> I did a sample Swing test with Scene Builder Kit and reproduced the >> exception >> reported in RT-36240. However it seems that this exception does not >> prevent >> SB to complete its drag and drop gestures. Does it match what you've >> observed ? >> >> Cheers. >> >> Eric >> >> >> >> Le 17 mars 2014 ? 14:49, Sven Reimers a ?crit : >> >> > Created RT-36240 >> > >> > -Sven >> > Am 17.03.2014 13:10 schrieb "Kevin Rushforth" < >> kevin.rushforth at oracle.com>: >> > >> >> Hi Sven, >> >> >> >> If you file the bug then yes, we can look at it for 8u20 (there is no >> >> "earlier"). >> >> >> >> And thanks to Petr for providing the evaluation for this. >> >> >> >> -- Kevin >> >> >> >> >> >> Sven Reimers wrote: >> >> >> >>> Ok. >> >>> >> >>> Will file an issue and if possible create a patch. >> >>> >> >>> Any this could end up in 8u20 (or earlier)? >> >>> >> >>> Thanks >> >>> >> >>> -Sven >> >>> Am 17.03.2014 11:05 schrieb "Petr Pchelko" : >> >>> >> >>> >> >>> >> >>>> Ok, I see. >> >>>> >> >>>> This is the problem in FX interop. >> >>>> In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper >> that >> >>>> wraps the FX dragboard into the Swing Trasferable. >> >>>> It is a simple class and many features are simply not implemented. >> The >> >>>> implementation is very basic - it just creates the DataFlavor with >> the >> >>>> mime-type corresponding to the DataFormat mime-type. However it does >> not >> >>>> take into account the representation class. This works fine for basic >> >>>> types >> >>>> like text or may be image, but it completely does not work for custom >> >>>> types >> >>>> with custom representation classes. >> >>>> >> >>>> You could file a bug for this. >> >>>> >> >>>> With best regards. Petr. >> >>>> >> >>>> On 17.03.2014, at 13:39, Sven Reimers >> wrote: >> >>>> >> >>>> The problem seems to be in AbstractDragSource in SceneBuilder. It >> defines >> >>>> a javafx.scene.input.DataFormat. >> >>>> This seems to cause problems if running embedded in Swing. I do not >> >>>> define >> >>>> my own DataFlavors.. >> >>>> >> >>>> Any further help appreciated.. >> >>>> >> >>>> -Sven >> >>>> Am 17.03.2014 09:54 schrieb "Petr Pchelko" > >: >> >>>> >> >>>> >> >>>> >> >>>>> Hello, Sven. >> >>>>> >> >>>>> Looks like you are not specifying the representation class for the >> >>>>> DataFlavor and it defaults >> >>>>> to the InputStream. So, scene builder puts a ByteBuffer while the >> >>>>> DataTransferer is trying to treat it as an >> >>>>> InputStream. >> >>>>> >> >>>>> Could you please try to explicitly specify the representation class >> in >> >>>>> the DataFlavor you are trying to put? >> >>>>> Like this: new DataFlavor("scene.builder/internal; >> >>>>> class=java.nio.HeapByteBuffer", "SceneBuilder internal DF"") >> >>>>> >> >>>>> With best regards. Petr. >> >>>>> >> >>>>> On 17.03.2014, at 0:13, Sven Reimers >> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>>> Ok... figured it out. It seems scene.builder.internal crashes the >> Swing >> >>>>>> parsing mechanism for mime types in the data transfer. Changing it >> to >> >>>>>> scene.builder/internal fixes this problem. >> >>>>>> >> >>>>>> Shall I open an issue in Jira for it? >> >>>>>> >> >>>>>> Having fixed this I get another problem :-( >> >>>>>> (see stacktrace below) >> >>>>>> >> >>>>>> Not sure how to fix this... investigating now. >> >>>>>> >> >>>>>> -Sven >> >>>>>> >> >>>>>> java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be >> cast to >> >>>>>> java.io.InputStream >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> sun.awt.datatransfer.DataTransferer.translateTransferable( >> >>>>> DataTransferer.java:1372) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> sun.lwawt.macosx.CDataTransferer.translateTransferable( >> >>>>> CDataTransferer.java:131) >> >>>>> >> >>>>> >> >>>>>> at >> sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) >> >>>>>> at >> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> >>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >> >>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >> >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >> >>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >> >>>>>> at java.security.AccessController.doPrivileged(Native Method) >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >> >>>>> ProtectionDomain.java:75) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >> >>>>> ProtectionDomain.java:86) >> >>>>> >> >>>>> >> >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:719) >> >>>>>> at java.awt.EventQueue$4.run(EventQueue.java:717) >> >>>>>> at java.security.AccessController.doPrivileged(Native Method) >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >> >>>>> ProtectionDomain.java:75) >> >>>>> >> >>>>> >> >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( >> >>>>> TimableEventQueue.java:159) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( >> >>>>> EventDispatchThread.java:201) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> java.awt.EventDispatchThread.pumpEventsForFilter( >> >>>>> EventDispatchThread.java:116) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( >> >>>>> EventDispatchThread.java:105) >> >>>>> >> >>>>> >> >>>>>> at java.awt.EventDispatchThread.pumpEvents( >> >>>>>> EventDispatchThread.java:101) >> >>>>>> at java.awt.EventDispatchThread.pumpEvents( >> >>>>>> EventDispatchThread.java:93) >> >>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >>>>>> >> >>>>>> >> >>>>>> On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers < >> sven.reimers at gmail.com >> >>>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>> Hi guys, >> >>>>>>> >> >>>>>>> hope someone can help me with the exception pasted below. >> >>>>>>> >> >>>>>>> Any idea how to go on from here? >> >>>>>>> >> >>>>>>> The code is available at >> >>>>>>> >> >>>>>>> >> >>>>>> https://bitbucket.org/sreimers/nbscenebuilder/ >> >>>>> >> >>>>> >> >>>>>> Thanks >> >>>>>>> >> >>>>>>> -Sven >> >>>>>>> >> >>>>>>> java.lang.IllegalArgumentException: failed to >> >>>>>>> >> >>>>>>> >> >>>>>> parse:scene.builder.internal >> >>>>> >> >>>>> >> >>>>>> at java.awt.datatransfer.DataFlavor.(DataFlavor.java:488) >> >>>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors( >> >>>>> SwingDnD.java:398) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> sun.awt.datatransfer.DataTransferer.getFormatsForTransferable( >> >>>>> DataTransferer.java:655) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> sun.awt.dnd.SunDragSourceContextPeer.startDrag( >> >>>>> SunDragSourceContextPeer.java:131) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> sun.lwawt.macosx.CDragSourceContextPeer.startDrag( >> >>>>> CDragSourceContextPeer.java:88) >> >>>>> >> >>>>> >> >>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:321) >> >>>>>>> at java.awt.dnd.DragSource.startDrag(DragSource.java:426) >> >>>>>>> at >> java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) >> >>>>>>> at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) >> >>>>>>> at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) >> >>>>>>> at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) >> >>>>>>> at >> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) >> >>>>>>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >> >>>>>>> at java.awt.EventQueue.access$400(EventQueue.java:97) >> >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:697) >> >>>>>>> at java.awt.EventQueue$3.run(EventQueue.java:691) >> >>>>>>> at java.security.AccessController.doPrivileged(Native Method) >> >>>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege( >> >>>>> ProtectionDomain.java:75) >> >>>>> >> >>>>> >> >>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >> >>>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> org.netbeans.core.TimableEventQueue.dispatchEvent( >> >>>>> TimableEventQueue.java:159) >> >>>>> >> >>>>> >> >>>>>> [catch] at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters( >> >>>>> EventDispatchThread.java:201) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> java.awt.EventDispatchThread.pumpEventsForFilter( >> >>>>> EventDispatchThread.java:116) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy( >> >>>>> EventDispatchThread.java:105) >> >>>>> >> >>>>> >> >>>>>> at >> >>>>>>> >> >>>>>>> >> >>>>>> >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> >>>>> >> >>>>> >> >>>>>> at java.awt.EventDispatchThread.pumpEvents( >> >>>>>>> EventDispatchThread.java:93) >> >>>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Sven Reimers >> >>>>>>> >> >>>>>>> * Senior Expert Software Architect >> >>>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >>>>>>> * Community Leader NetBeans: http://community.java.net/netbeans >> >>>>>>> Desktop Java: >> >>>>>>> http://community.java.net/javadesktop >> >>>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> >>>>>>> * Duke's Choice Award Winner 2009 >> >>>>>>> * Blog: https://www.java.net//blog/sven >> >>>>>>> >> >>>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >>>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >>>>>>> >> >>>>>>> Join the NetBeans Groups: >> >>>>>>> * XING: http://www.xing.com/group-20148.82db20 >> >>>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >>>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >>>>>>> http://www.linkedin.com/groups?gid=107402 >> >>>>>>> http://www.linkedin.com/groups?gid=1684717 >> >>>>>>> * Oracle: https://mix.oracle.com/groups/18497 >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Sven Reimers >> >>>>>> >> >>>>>> * Senior Expert Software Architect >> >>>>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >>>>>> * Community Leader NetBeans: http://community.java.net/netbeans >> >>>>>> Desktop Java: >> >>>>>> http://community.java.net/javadesktop >> >>>>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> >>>>>> * Duke's Choice Award Winner 2009 >> >>>>>> * Blog: https://www.java.net//blog/sven >> >>>>>> >> >>>>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >>>>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >>>>>> >> >>>>>> Join the NetBeans Groups: >> >>>>>> * XING: http://www.xing.com/group-20148.82db20 >> >>>>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >>>>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >>>>>> http://www.linkedin.com/groups?gid=107402 >> >>>>>> http://www.linkedin.com/groups?gid=1684717 >> >>>>>> * Oracle: https://mix.oracle.com/groups/18497 >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >> > From hang.vo at oracle.com Mon Mar 17 16:03:19 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 16:03:19 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35635: new bundlers for fxpackager Message-ID: <201403171603.s2HG3UTt008111@aojmv0008> Changeset: 7339a5bb9864 Author: Danno Ferrin (shemnon) Date: 2014-03-17 09:51 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7339a5bb9864 RT-35635: new bundlers for fxpackager RT-35969: Daemon and Services apps for fxpackager ! modules/fxpackager/src/main/java/com/oracle/bundlers/AbstractBundler.java + modules/fxpackager/src/main/java/com/oracle/bundlers/BasicBundlers.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/BundlerParamInfo.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/Bundlers.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/EnumeratedBundlerParam.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/InvalidBundlerParamException.java + modules/fxpackager/src/main/java/com/oracle/bundlers/JreUtils.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/StandardBundlerParam.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacAppStoreBundler.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacBaseInstallerBundler.java + modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacDaemonBundler.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacPKGBundler.java ! modules/fxpackager/src/main/java/com/oracle/bundlers/windows/WindowsBundlerParam.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/DeployParams.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/Log.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/Main.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/PackagerLib.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/BundleParams.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/ConfigException.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxAppBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxDebBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxRPMBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/MacAppBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/MacDMGBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/WinAppBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/WinExeBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/WinMsiBundler.java + modules/fxpackager/src/main/native/launcher/win/WinLauncherSvc.cpp ! modules/fxpackager/src/main/resources/com/oracle/bundlers/StandardBundlerParam.properties ! modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxDebBundler.properties ! modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxRpmBundler.properties + modules/fxpackager/src/main/resources/com/oracle/bundlers/mac/MacAppBundler.properties + modules/fxpackager/src/main/resources/com/oracle/bundlers/mac/MacAppStoreBundler.properties + modules/fxpackager/src/main/resources/com/oracle/bundlers/mac/MacBaseInstallerBundler.properties + modules/fxpackager/src/main/resources/com/oracle/bundlers/mac/MacDaemonBundler.properties + modules/fxpackager/src/main/resources/com/oracle/bundlers/mac/MacPKGBundler.properties ! modules/fxpackager/src/main/resources/com/oracle/bundlers/windows/WinExeBundler.properties ! modules/fxpackager/src/main/resources/com/oracle/bundlers/windows/WinMsiBundler.properties ! modules/fxpackager/src/main/resources/com/sun/javafx/tools/packager/Bundle.properties + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.deb.init.script ! modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.postinst ! modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.postrm + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.rpm.init.script ! modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/linux/template.spec + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/mac/GenericAppHiDPI.icns + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/mac/MacAppStore.entitlements + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/mac/MacAppStore_Inherit.entitlements + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/mac/launchd.plist.template + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/mac/postinstall.template + modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/mac/preinstall.template ! modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/windows/template.iss ! modules/fxpackager/src/test/java/com/oracle/bundlers/BundlersTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxAppBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxRpmBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacAppBundlerTest.java + modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacAppStoreBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacDMGBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacPKGBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/windows/WinAppBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/windows/WinEXEBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/bundlers/windows/WinMSIBundlerTest.java + modules/fxpackager/src/test/java/com/sun/javafx/tools/packager/CLITest.java From felipe.heidrich at oracle.com Mon Mar 17 16:13:12 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Mon, 17 Mar 2014 09:13:12 -0700 Subject: review RT-36230: [Accessibility] New accessibility implementation Message-ID: Hi Kevin and David Please review Jira: https://javafx-jira.kenai.com/browse/RT-36230 Wiki: https://wiki.openjdk.java.net/display/OpenJFX/Accessibility (it has information about the design, test plan, etc) WebRev: http://cr.openjdk.java.net/~fheidric/RT-36230/webrev/ More information about new accessibility work on JavaFX will be send to the list shortly. Thank you Felipe From hang.vo at oracle.com Mon Mar 17 16:47:38 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 16:47:38 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36216 - Open-source the WebTerminal app Message-ID: <201403171647.s2HGloiY015482@aojmv0008> Changeset: 03b02a7bcfb9 Author: Per Bothner Date: 2014-03-17 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/03b02a7bcfb9 RT-36216 - Open-source the WebTerminal app See README.txt for more information. + apps/experiments/WebTerminal/.ant-targets-build.xml + apps/experiments/WebTerminal/README.txt + apps/experiments/WebTerminal/build.xml + apps/experiments/WebTerminal/manifest.mf + apps/experiments/WebTerminal/nbproject/build-impl.xml + apps/experiments/WebTerminal/nbproject/genfiles.properties + apps/experiments/WebTerminal/nbproject/project.properties + apps/experiments/WebTerminal/nbproject/project.xml + apps/experiments/WebTerminal/src/webterminal/NodeWriter.java + apps/experiments/WebTerminal/src/webterminal/RunInConsole.java + apps/experiments/WebTerminal/src/webterminal/ShellConsole.java + apps/experiments/WebTerminal/src/webterminal/WTDebug.java + apps/experiments/WebTerminal/src/webterminal/WebOutputStream.java + apps/experiments/WebTerminal/src/webterminal/WebTerminal.java + apps/experiments/WebTerminal/src/webterminal/WebWriter.java + apps/experiments/WebTerminal/src/webterminal/repl.html + apps/experiments/WebTerminal/src/webterminal/repl.xml + apps/experiments/WebTerminal/terminfo/j/jfxterm + apps/experiments/WebTerminal/terminfo/j/jfxterm.ti + apps/experiments/WebTerminal/terminfo/j/xjfxterm.ti + apps/experiments/WebTerminal/util/hcat + apps/experiments/WebTerminal/util/myemacs From jasper.potts at oracle.com Mon Mar 17 16:51:10 2014 From: jasper.potts at oracle.com (Jasper Potts) Date: Mon, 17 Mar 2014 09:51:10 -0700 Subject: Opacity in Image.getPixelReader.getColor() In-Reply-To: <53259F5D.30108@bestsolution.at> References: <53259F5D.30108@bestsolution.at> Message-ID: <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> My understanding is alpha and opacity are same just different range. Opacity is 0.0 to 1.0 Alpha is 0 to 255 Jim or Kevin will be authority on this. Jasper > On Mar 16, 2014, at 5:55 AM, Tom Schindl wrote: > > Hi, > > Maybe I'm completely wrong but to me it looks like the opacity I get > from Image.getPixelReader.getColor() is wrong. > > If not mistaken the relation between alpha and opacity is expressed with: > > opacity = (255 - alpha) / 255.0 > > which means: > > opacity 0 => alpha 255 > opacity 1 => alpha 0 > > Running the following programm on a gif > >> public class OpacityBug extends Application { >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> Image image = new Image(getClass().getResourceAsStream("methpri_obj.gif")); >> int width = (int) image.getWidth(); >> int height = (int) image.getHeight(); >> >> PixelReader reader = image.getPixelReader(); >> for (int x = width - 1; x >= 0; x--) { >> for (int y = height - 1; y >= 0; y--) { >> int argb = reader.getArgb(x, y); >> int alphaArgb = (argb >> 24) & 0xFF; >> Color color = reader.getColor(x, y); >> double opacity = color.getOpacity(); >> System.err.println(x+","+y + " => alpha: " + alphaArgb + " op: " + opacity + " op-alpha: " + opacityToAlpha(opacity) + " color: " + color); >> } >> } >> } >> >> >> private static int opacityToAlpha(double opacity) { >> return (int)Math.round((((opacity * 255.0) - 255) * -1)); >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> } > > produces and output like: > 15,15 => alpha: 0 op: 0.0 op-alpha: 255 color: 0x00000000 > > which to my understanding is wrong. The argb value is correct (if > compared to the image because the pixel at 15,15 is fully transparent) > but then the the opacity should be 1.0 but is the opposite. > > Looking at the code in Image I see: >> @Override >> public Color getColor(int x, int y) { >> int argb = getArgb(x, y); >> int a = argb >>> 24; >> int r = (argb >> 16) & 0xff; >> int g = (argb >> 8) & 0xff; >> int b = (argb ) & 0xff; >> return Color.rgb(r, g, b, a / 255.0); >> } > > which means that: > a) my formula from the above is wrong > b) or there's the bug because it should be > return Color.rgb(r, g, b, (255 - a) / 255.0); > > May I also suggest to add get a > - Color.argb(int r,int g,int b,int alpha) > maybe it is just me but I'm so much more used to alpha than opacity that > I always have to look it up when i need it. > > Tom From felipe.heidrich at oracle.com Mon Mar 17 16:51:56 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Mon, 17 Mar 2014 09:51:56 -0700 Subject: review: RT-36246: NPE on Node#localToScreen Message-ID: <4E364FF1-936B-409B-B507-3F31BB952FE8@oracle.com> Hi Martin, Can I get a quick review for https://javafx-jira.kenai.com/browse/RT-36246 The patch is attached to Jira. The accessibility code is affected by this bug. Thank you Felipe From han.solo at muenster.de Mon Mar 17 16:55:19 2014 From: han.solo at muenster.de (Gerrit Grunwald) Date: Mon, 17 Mar 2014 17:55:19 +0100 Subject: Opacity in Image.getPixelReader.getColor() In-Reply-To: <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> References: <53259F5D.30108@bestsolution.at> <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> Message-ID: <7FD49F12-F4E3-4F6E-923B-2963D5436443@muenster.de> +1 Am 17.03.2014 um 17:51 schrieb Jasper Potts : > My understanding is alpha and opacity are same just different range. > > Opacity is 0.0 to 1.0 > Alpha is 0 to 255 > > Jim or Kevin will be authority on this. > > Jasper > >> On Mar 16, 2014, at 5:55 AM, Tom Schindl wrote: >> >> Hi, >> >> Maybe I'm completely wrong but to me it looks like the opacity I get >> from Image.getPixelReader.getColor() is wrong. >> >> If not mistaken the relation between alpha and opacity is expressed with: >> >> opacity = (255 - alpha) / 255.0 >> >> which means: >> >> opacity 0 => alpha 255 >> opacity 1 => alpha 0 >> >> Running the following programm on a gif >> >>> public class OpacityBug extends Application { >>> >>> @Override >>> public void start(Stage primaryStage) throws Exception { >>> Image image = new Image(getClass().getResourceAsStream("methpri_obj.gif")); >>> int width = (int) image.getWidth(); >>> int height = (int) image.getHeight(); >>> >>> PixelReader reader = image.getPixelReader(); >>> for (int x = width - 1; x >= 0; x--) { >>> for (int y = height - 1; y >= 0; y--) { >>> int argb = reader.getArgb(x, y); >>> int alphaArgb = (argb >> 24) & 0xFF; >>> Color color = reader.getColor(x, y); >>> double opacity = color.getOpacity(); >>> System.err.println(x+","+y + " => alpha: " + alphaArgb + " op: " + opacity + " op-alpha: " + opacityToAlpha(opacity) + " color: " + color); >>> } >>> } >>> } >>> >>> >>> private static int opacityToAlpha(double opacity) { >>> return (int)Math.round((((opacity * 255.0) - 255) * -1)); >>> } >>> >>> public static void main(String[] args) { >>> Application.launch(args); >>> } >>> } >> >> produces and output like: >> 15,15 => alpha: 0 op: 0.0 op-alpha: 255 color: 0x00000000 >> >> which to my understanding is wrong. The argb value is correct (if >> compared to the image because the pixel at 15,15 is fully transparent) >> but then the the opacity should be 1.0 but is the opposite. >> >> Looking at the code in Image I see: >>> @Override >>> public Color getColor(int x, int y) { >>> int argb = getArgb(x, y); >>> int a = argb >>> 24; >>> int r = (argb >> 16) & 0xff; >>> int g = (argb >> 8) & 0xff; >>> int b = (argb ) & 0xff; >>> return Color.rgb(r, g, b, a / 255.0); >>> } >> >> which means that: >> a) my formula from the above is wrong >> b) or there's the bug because it should be >> return Color.rgb(r, g, b, (255 - a) / 255.0); >> >> May I also suggest to add get a >> - Color.argb(int r,int g,int b,int alpha) >> maybe it is just me but I'm so much more used to alpha than opacity that >> I always have to look it up when i need it. >> >> Tom From kevin.rushforth at oracle.com Mon Mar 17 17:03:30 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Mar 2014 10:03:30 -0700 Subject: Opacity in Image.getPixelReader.getColor() In-Reply-To: <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> References: <53259F5D.30108@bestsolution.at> <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> Message-ID: <53272AE2.1070004@oracle.com> I'm sure Jim could word this better, but here goes... Opacity and alpha are mostly used interchangeably. Whether the range is expressed as a normalized value [0.0,1.0] or an 8-bit pixel value [0,255], the meaning is the same. A value of 0 means that the color is completely transparent. When using the default SRC_OVER blend equation, a pixel with this color will have no effect. A value of 1.0 (if using a normalized value) or 255 (if using an 8-bit integer value) means that the color is fully opaque. When using the default SRC_OVER blend equation, a pixel with this color will overwrite whatever is underneath it. Perhaps Tom is thinking of "transparency" which, if we were to have such an attribute, would be defined as (1.0-opacity). -- Kevin Jasper Potts wrote: > My understanding is alpha and opacity are same just different range. > > Opacity is 0.0 to 1.0 > Alpha is 0 to 255 > > Jim or Kevin will be authority on this. > > Jasper > > >> On Mar 16, 2014, at 5:55 AM, Tom Schindl wrote: >> >> Hi, >> >> Maybe I'm completely wrong but to me it looks like the opacity I get >> from Image.getPixelReader.getColor() is wrong. >> >> If not mistaken the relation between alpha and opacity is expressed with: >> >> opacity = (255 - alpha) / 255.0 >> >> which means: >> >> opacity 0 => alpha 255 >> opacity 1 => alpha 0 >> >> Running the following programm on a gif >> >> >>> public class OpacityBug extends Application { >>> >>> @Override >>> public void start(Stage primaryStage) throws Exception { >>> Image image = new Image(getClass().getResourceAsStream("methpri_obj.gif")); >>> int width = (int) image.getWidth(); >>> int height = (int) image.getHeight(); >>> >>> PixelReader reader = image.getPixelReader(); >>> for (int x = width - 1; x >= 0; x--) { >>> for (int y = height - 1; y >= 0; y--) { >>> int argb = reader.getArgb(x, y); >>> int alphaArgb = (argb >> 24) & 0xFF; >>> Color color = reader.getColor(x, y); >>> double opacity = color.getOpacity(); >>> System.err.println(x+","+y + " => alpha: " + alphaArgb + " op: " + opacity + " op-alpha: " + opacityToAlpha(opacity) + " color: " + color); >>> } >>> } >>> } >>> >>> >>> private static int opacityToAlpha(double opacity) { >>> return (int)Math.round((((opacity * 255.0) - 255) * -1)); >>> } >>> >>> public static void main(String[] args) { >>> Application.launch(args); >>> } >>> } >>> >> produces and output like: >> 15,15 => alpha: 0 op: 0.0 op-alpha: 255 color: 0x00000000 >> >> which to my understanding is wrong. The argb value is correct (if >> compared to the image because the pixel at 15,15 is fully transparent) >> but then the the opacity should be 1.0 but is the opposite. >> >> Looking at the code in Image I see: >> >>> @Override >>> public Color getColor(int x, int y) { >>> int argb = getArgb(x, y); >>> int a = argb >>> 24; >>> int r = (argb >> 16) & 0xff; >>> int g = (argb >> 8) & 0xff; >>> int b = (argb ) & 0xff; >>> return Color.rgb(r, g, b, a / 255.0); >>> } >>> >> which means that: >> a) my formula from the above is wrong >> b) or there's the bug because it should be >> return Color.rgb(r, g, b, (255 - a) / 255.0); >> >> May I also suggest to add get a >> - Color.argb(int r,int g,int b,int alpha) >> maybe it is just me but I'm so much more used to alpha than opacity that >> I always have to look it up when i need it. >> >> Tom >> From kevin.rushforth at oracle.com Mon Mar 17 18:03:10 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Mar 2014 11:03:10 -0700 Subject: [8u] review request: RT-36197: Create regression tests that run JavaFX apps with a security manager Message-ID: <532738DE.9070005@oracle.com> Chien & Felipe, Please review the following unit tests: https://javafx-jira.kenai.com/browse/RT-36197 Thanks. -- Kevin From hang.vo at oracle.com Mon Mar 17 18:32:40 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 18:32:40 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35635: new bundlers for fxpackager - missed two files Message-ID: <201403171832.s2HIWqlT002536@aojmv0008> Changeset: c66b3066b41e Author: shemnon Date: 2014-03-17 12:21 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c66b3066b41e RT-35635: new bundlers for fxpackager - missed two files ! modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxDebBundlerTest.java ! modules/fxpackager/src/test/java/com/sun/javafx/tools/packager/PackagerLibTest.java From lisa.selle at oracle.com Mon Mar 17 18:49:43 2014 From: lisa.selle at oracle.com (Lisa Selle) Date: Mon, 17 Mar 2014 14:49:43 -0400 Subject: [8u26] Review request: RT-35245 [Monocle] EGL setup for Freescale i.MX6 Message-ID: <532743C7.4090802@oracle.com> Daniel, Please review the fix for jira: https://javafx-jira.kenai.com/browse/RT-35245 webrev posted: http://cr.openjdk.java.net/~kselle/webrev-20140317-1433-RT-35245/webrev/ Thanks, Lisa From tom.schindl at bestsolution.at Mon Mar 17 20:07:18 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 17 Mar 2014 13:07:18 -0700 Subject: Opacity in Image.getPixelReader.getColor() In-Reply-To: <53272AE2.1070004@oracle.com> References: <53259F5D.30108@bestsolution.at> <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> <53272AE2.1070004@oracle.com> Message-ID: <532755F6.7000906@bestsolution.at> Hi, Yes it looks like i mixed this up with transparency! Tom On 17.03.14 10:03, Kevin Rushforth wrote: > I'm sure Jim could word this better, but here goes... > > Opacity and alpha are mostly used interchangeably. Whether the range is > expressed as a normalized value [0.0,1.0] or an 8-bit pixel value > [0,255], the meaning is the same. A value of 0 means that the color is > completely transparent. When using the default SRC_OVER blend equation, > a pixel with this color will have no effect. A value of 1.0 (if using a > normalized value) or 255 (if using an 8-bit integer value) means that > the color is fully opaque. When using the default SRC_OVER blend > equation, a pixel with this color will overwrite whatever is underneath it. > > Perhaps Tom is thinking of "transparency" which, if we were to have such > an attribute, would be defined as (1.0-opacity). > > -- Kevin > > > Jasper Potts wrote: >> My understanding is alpha and opacity are same just different range. >> Opacity is 0.0 to 1.0 >> Alpha is 0 to 255 >> >> Jim or Kevin will be authority on this. >> Jasper >> >> >>> On Mar 16, 2014, at 5:55 AM, Tom Schindl >>> wrote: >>> >>> Hi, >>> >>> Maybe I'm completely wrong but to me it looks like the opacity I get >>> from Image.getPixelReader.getColor() is wrong. >>> >>> If not mistaken the relation between alpha and opacity is expressed >>> with: >>> >>> opacity = (255 - alpha) / 255.0 >>> >>> which means: >>> >>> opacity 0 => alpha 255 >>> opacity 1 => alpha 0 >>> >>> Running the following programm on a gif >>> >>> >>>> public class OpacityBug extends Application { >>>> >>>> @Override >>>> public void start(Stage primaryStage) throws Exception { >>>> Image image = new >>>> Image(getClass().getResourceAsStream("methpri_obj.gif")); >>>> int width = (int) image.getWidth(); >>>> int height = (int) image.getHeight(); >>>> PixelReader reader = image.getPixelReader(); >>>> for (int x = width - 1; x >= 0; x--) { >>>> for (int y = height - 1; y >= 0; y--) { >>>> int argb = reader.getArgb(x, y); >>>> int alphaArgb = (argb >> 24) & 0xFF; >>>> Color color = reader.getColor(x, y); >>>> double opacity = color.getOpacity(); >>>> System.err.println(x+","+y + " => alpha: " + >>>> alphaArgb + " op: " + opacity + " op-alpha: " + >>>> opacityToAlpha(opacity) + " color: " + color); >>>> } >>>> } >>>> } >>>> private static int opacityToAlpha(double opacity) { >>>> return (int)Math.round((((opacity * 255.0) - 255) * -1)); >>>> } >>>> >>>> public static void main(String[] args) { >>>> Application.launch(args); >>>> } >>>> } >>>> >>> produces and output like: >>> 15,15 => alpha: 0 op: 0.0 op-alpha: 255 color: 0x00000000 >>> >>> which to my understanding is wrong. The argb value is correct (if >>> compared to the image because the pixel at 15,15 is fully transparent) >>> but then the the opacity should be 1.0 but is the opposite. >>> >>> Looking at the code in Image I see: >>> >>>> @Override >>>> public Color getColor(int x, int y) { >>>> int argb = getArgb(x, y); >>>> int a = argb >>> 24; >>>> int r = (argb >> 16) & 0xff; >>>> int g = (argb >> 8) & 0xff; >>>> int b = (argb ) & 0xff; >>>> return Color.rgb(r, g, b, a / 255.0); >>>> } >>>> >>> which means that: >>> a) my formula from the above is wrong >>> b) or there's the bug because it should be >>> return Color.rgb(r, g, b, (255 - a) / 255.0); >>> >>> May I also suggest to add get a >>> - Color.argb(int r,int g,int b,int alpha) >>> maybe it is just me but I'm so much more used to alpha than opacity that >>> I always have to look it up when i need it. >>> >>> Tom >>> From hang.vo at oracle.com Mon Mar 17 22:32:50 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Mar 2014 22:32:50 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36246: NPE on Node#localToScreen Message-ID: <201403172233.s2HMX1c7008817@aojmv0008> Changeset: 10d656e22fbd Author: Felipe Heidrich Date: 2014-03-17 15:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/10d656e22fbd RT-36246: NPE on Node#localToScreen ! modules/graphics/src/main/java/javafx/scene/Node.java From hang.vo at oracle.com Tue Mar 18 01:47:26 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 01:47:26 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35891: TreeTableView cells are not in parameterised CellTest class Message-ID: <201403180147.s2I1lb5I008384@aojmv0008> Changeset: 2f2379857779 Author: jgiles Date: 2014-03-18 14:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2f2379857779 RT-35891: TreeTableView cells are not in parameterised CellTest class This changeset adds the TreeTableRow and TreeTableCell classes to the CellTest parameterised test class, enabling these two classes to have the ~41 unit tests run against each of them. ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/CellTest.java From hang.vo at oracle.com Tue Mar 18 13:32:53 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 13:32:53 +0000 Subject: hg: openjfx/8u-dev/rt: Fix for RT-35245 [Monocle] EGL setup for Freescale i.MX6 - implements prism es2 on monocle on imx. Currently this is not the default, it can be activated by using runtime flags -Djavafx.platform=monocle -Dembedded=monocle. Message-ID: <201403181333.s2IDX5BN023128@aojmv0008> Changeset: a50800b8372c Author: Lisa.Selle at oracle.com Date: 2014-03-18 09:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a50800b8372c Fix for RT-35245 [Monocle] EGL setup for Freescale i.MX6 - implements prism es2 on monocle on imx. Currently this is not the default, it can be activated by using runtime flags -Djavafx.platform=monocle -Dembedded=monocle. Tested with HelloSanity. ! buildSrc/armv6hf.gradle ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/AcceleratedScreen.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6AcceleratedScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6Platform.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6PlatformFactory.java + modules/graphics/src/main/native-glass/monocle/mx6/MX6AcceleratedScreen.c From hang.vo at oracle.com Tue Mar 18 14:47:47 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 14:47:47 +0000 Subject: hg: openjfx/8u-dev/rt: SWT Glass: Return the window handle for the Shell (rather than the view handle) Message-ID: <201403181447.s2IElwlu005317@aojmv0008> Changeset: 15f389017ffb Author: snorthov Date: 2014-03-18 07:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/15f389017ffb SWT Glass: Return the window handle for the Shell (rather than the view handle) ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTApplication.java From hang.vo at oracle.com Tue Mar 18 16:17:38 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 16:17:38 +0000 Subject: hg: openjfx/8u-dev/rt: 3 new changesets Message-ID: <201403181618.s2IGI1nW020904@aojmv0008> Changeset: 286673912389 Author: David Grieve Date: 2014-03-18 11:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/286673912389 RT-33319: The issue is that the ladder function used to generate -fx-text-background-color (see modena.css) takes a Color but the style given in the example resolves to a Paint. In the case where the ClassCastException comes not because the lookup failed but because the type is truely not right, a better warning message is issued. ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java Changeset: 2b9df4db108e Author: David Grieve Date: 2014-03-18 11:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2b9df4db108e RT-30868: from computeClippedWrappedText if ellipsis doesn't fit, return text ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java Changeset: 5159a070e730 Author: David Grieve Date: 2014-03-18 11:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5159a070e730 RT-28458: add rtl icons for HTMLEditor. Fix bug in SimpleSelector causing rtl selection to fail + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-Black-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-Black at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-White-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-White at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-Yellow-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-Yellow at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Bullets at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-Black-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-Black at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-White-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-White at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-Yellow-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-Yellow at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Indent at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-Black-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-Black at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-White-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-White at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-Yellow-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-Yellow at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Numbered at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-Black-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-Black at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-White-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-White at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-Yellow-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-Yellow at 2x-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent-rtl.png + modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/HTMLEditor-Outdent at 2x-rtl.png ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/blackOnWhite.css ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/whiteOnBlack.css ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/yellowOnBlack.css ! modules/graphics/src/main/java/com/sun/javafx/css/SimpleSelector.java ! modules/web/src/main/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java From hang.vo at oracle.com Tue Mar 18 20:03:01 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 20:03:01 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36230: [Accessibility] New accessibility implementation Message-ID: <201403182003.s2IK3D0m027159@aojmv0008> Changeset: d3f5ba2e8117 Author: Felipe Heidrich Date: 2014-03-18 12:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d3f5ba2e8117 RT-36230: [Accessibility] New accessibility implementation Reviewed-by: Kevin Rushforth, David Hill + apps/toys/Hello/src/main/java/a11y/HelloPasswordField.java + apps/toys/Hello/src/main/java/a11y/HelloSimpleCheckBox.java + apps/toys/Hello/src/main/java/a11y/HelloSimpleListView.java + apps/toys/Hello/src/main/java/a11y/HelloSimpleTableView.java + apps/toys/Hello/src/main/java/a11y/HelloSimpleTreeTableView.java + apps/toys/Hello/src/main/java/a11y/HelloSimpleTreeView.java + apps/toys/Hello/src/main/java/a11y/HelloTabPane.java + apps/toys/Hello/src/main/java/a11y/HelloText.java + apps/toys/Hello/src/main/java/a11y/HelloToolBar.java ! build.gradle ! buildSrc/android.gradle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/armv7hft.gradle ! buildSrc/armv7sft.gradle ! buildSrc/ios.gradle ! buildSrc/linux.gradle ! buildSrc/mac.gradle ! buildSrc/win.gradle ! buildSrc/x86egl.gradle - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleButton.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleCheckBox.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleControl.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleList.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleListItem.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleMenuButton.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleRadioButton.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleSlider.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SliderSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/Accordion.java ! modules/controls/src/main/java/javafx/scene/control/Button.java ! modules/controls/src/main/java/javafx/scene/control/ButtonBase.java ! modules/controls/src/main/java/javafx/scene/control/Cell.java ! modules/controls/src/main/java/javafx/scene/control/CheckBox.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/controls/src/main/java/javafx/scene/control/Hyperlink.java ! modules/controls/src/main/java/javafx/scene/control/Label.java ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! modules/controls/src/main/java/javafx/scene/control/Pagination.java ! modules/controls/src/main/java/javafx/scene/control/PasswordField.java ! modules/controls/src/main/java/javafx/scene/control/ProgressBar.java ! modules/controls/src/main/java/javafx/scene/control/ProgressIndicator.java ! modules/controls/src/main/java/javafx/scene/control/RadioButton.java ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/TabPane.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TextArea.java ! modules/controls/src/main/java/javafx/scene/control/TextField.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java ! modules/controls/src/main/java/javafx/scene/control/ToggleButton.java ! modules/controls/src/main/java/javafx/scene/control/ToolBar.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/graphics/src/main/java/com/sun/glass/events/WindowEvent.java ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java + modules/graphics/src/main/java/com/sun/glass/ui/PlatformAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/PlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/View.java ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleBasePatternProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleBaseProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleLogger.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleAttributes.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleBasePatternProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleBaseProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleEventIds.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleRoles.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleRoot.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleSelectionItemProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleSelectionProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleToggleProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleBasePatternProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleBaseProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleGridItemProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleGridProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleRangeValueProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleRoot.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleSelectionItemProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleSelectionProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleToggleProvider.java ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkPlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/ios/IosPlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/mac/MacVariant.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacView.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonoclePlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/swtPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinPlatformFactory.java + modules/graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java + modules/graphics/src/main/java/com/sun/glass/ui/win/WinVariant.java - modules/graphics/src/main/java/com/sun/javafx/accessible/AccessibleNode.java - modules/graphics/src/main/java/com/sun/javafx/accessible/AccessibleStage.java - modules/graphics/src/main/java/com/sun/javafx/accessible/AccessibleText.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/Accessible.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/AccessibleProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/AccessibleStageProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/ExpandCollapseProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/GridItemProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/GridProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/InvokeProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/RangeValueProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/SelectionItemProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/SelectionProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/ToggleProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/ValueProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ControlTypeIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/EventIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ExpandCollapseState.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/NavigateDirection.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/OrientationType.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/PatternIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/PropertyIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ProviderOptions.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/Rect.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ToggleState.java ! modules/graphics/src/main/java/com/sun/javafx/scene/NodeHelper.java ! modules/graphics/src/main/java/com/sun/javafx/stage/StagePeerListener.java ! modules/graphics/src/main/java/com/sun/javafx/stage/WindowPeerListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKStage.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKStageListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedStage.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassWindowEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/Scene.java + modules/graphics/src/main/java/javafx/scene/accessibility/Accessible.java + modules/graphics/src/main/java/javafx/scene/accessibility/Action.java + modules/graphics/src/main/java/javafx/scene/accessibility/Attribute.java + modules/graphics/src/main/java/javafx/scene/accessibility/Role.java + modules/graphics/src/main/java/javafx/scene/accessibility/package.html ! modules/graphics/src/main/java/javafx/scene/image/ImageView.java ! modules/graphics/src/main/java/javafx/scene/text/Text.java + modules/graphics/src/main/native-glass/mac/GlassAccessible.h + modules/graphics/src/main/native-glass/mac/GlassAccessible.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleBaseProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleBaseProvider.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleRoot.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleRoot.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionItemProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionItemProvider.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionProvider.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleToggleProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleToggleProvider.m ! modules/graphics/src/main/native-glass/mac/GlassStatics.h ! modules/graphics/src/main/native-glass/mac/GlassStatics.m ! modules/graphics/src/main/native-glass/mac/GlassView.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.h ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.m ! modules/graphics/src/main/native-glass/mac/GlassWindow+Java.h ! modules/graphics/src/main/native-glass/mac/GlassWindow+Java.m ! modules/graphics/src/main/native-glass/mac/GlassWindow.h ! modules/graphics/src/main/native-glass/mac/GlassWindow.m - modules/graphics/src/main/native-glass/win/AccessibleBasePatternProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleBasePatternProvider.h - modules/graphics/src/main/native-glass/win/AccessibleBaseProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleBaseProvider.h - modules/graphics/src/main/native-glass/win/AccessibleGridItemProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleGridItemProvider.h - modules/graphics/src/main/native-glass/win/AccessibleGridProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleGridProvider.h - modules/graphics/src/main/native-glass/win/AccessibleRangeValueProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleRangeValueProvider.h - modules/graphics/src/main/native-glass/win/AccessibleRoot.cpp - modules/graphics/src/main/native-glass/win/AccessibleRoot.h - modules/graphics/src/main/native-glass/win/AccessibleSelectionItemProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleSelectionItemProvider.h - modules/graphics/src/main/native-glass/win/AccessibleSelectionProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleSelectionProvider.h - modules/graphics/src/main/native-glass/win/AccessibleToggleProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleToggleProvider.h ! modules/graphics/src/main/native-glass/win/FullScreenWindow.cpp + modules/graphics/src/main/native-glass/win/GlassAccessible.cpp + modules/graphics/src/main/native-glass/win/GlassAccessible.h ! modules/graphics/src/main/native-glass/win/GlassApplication.h + modules/graphics/src/main/native-glass/win/GlassTextRangeProvider.cpp + modules/graphics/src/main/native-glass/win/GlassTextRangeProvider.h ! modules/graphics/src/main/native-glass/win/GlassView.cpp ! modules/graphics/src/main/native-glass/win/GlassWindow.cpp ! modules/graphics/src/main/native-glass/win/GlassWindow.h ! modules/graphics/src/main/native-glass/win/Utils.h ! modules/graphics/src/main/native-glass/win/ViewContainer.cpp ! modules/graphics/src/main/native-glass/win/ViewContainer.h ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubStage.java From hang.vo at oracle.com Tue Mar 18 20:17:34 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 20:17:34 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403182017.s2IKHqRe029526@aojmv0008> Changeset: 99caa949ca39 Author: David Grieve Date: 2014-03-18 15:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/99caa949ca39 RT-27548: simplify code that removes/adds Axis tick-marks. ! modules/controls/src/main/java/javafx/scene/chart/Axis.java ! modules/controls/src/main/java/javafx/scene/chart/ValueAxis.java Changeset: c73e9b0c222e Author: David Grieve Date: 2014-03-18 15:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c73e9b0c222e RT-36121: popup should not consume auto-hiding event ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DatePickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java From hang.vo at oracle.com Tue Mar 18 20:47:53 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 20:47:53 +0000 Subject: hg: openjfx/8u-dev/rt: RT-35635: app store test broke build server. Ignore it for now. Message-ID: <201403182048.s2IKm5Xa004320@aojmv0008> Changeset: dce5642a3cee Author: shemnon Date: 2014-03-18 14:29 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dce5642a3cee RT-35635: app store test broke build server. Ignore it for now. ! modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacAppStoreBundlerTest.java From hang.vo at oracle.com Tue Mar 18 21:17:34 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 21:17:34 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36265: Disable robot tests by default for developers Message-ID: <201403182117.s2ILHktH009103@aojmv0008> Changeset: 15fdfaeb91f6 Author: kcr Date: 2014-03-18 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/15fdfaeb91f6 RT-36265: Disable robot tests by default for developers ! build.gradle ! gradle.properties.template From kevin.rushforth at oracle.com Tue Mar 18 21:29:04 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Mar 2014 14:29:04 -0700 Subject: [8u20] post-commit review: RT-36265: Disable robot tests by default for developers Message-ID: <5328BAA0.3000007@oracle.com> I just pushed the fix for the following bug: JIRA: https://javafx-jira.kenai.com/browse/RT-36265 Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/15fdfaeb91f6 With this changeset, the default value of the gradle "USE_ROBOT" flag is now false. Use "-PUSE_ROBOT=true" to enable the robot-based tests. Note that this flag is only relevant when "-PFULL_TEST=true" (that hasn't changed). -- Kevin From hang.vo at oracle.com Tue Mar 18 22:03:16 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 22:03:16 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36197: Create regression tests that run JavaFX apps with a security manager Message-ID: <201403182203.s2IM3Rfa016519@aojmv0008> Changeset: 9604915644c1 Author: kcr Date: 2014-03-18 14:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9604915644c1 RT-36197: Create regression tests that run JavaFX apps with a security manager Reviewed-by: felipe, ckyang + tests/system/src/test/java/sandbox/Constants.java + tests/system/src/test/java/sandbox/SandboxAppTest.java + tests/system/src/test/java/sandbox/app/FXApp.java + tests/system/src/test/java/sandbox/app/FXNonApp.java + tests/system/src/test/java/sandbox/app/JFXPanelApp.java + tests/system/src/test/java/sandbox/app/JFXPanelImplicitExitApp.java + tests/system/src/test/java/sandbox/app/Util.java + tests/system/src/test/resources/sandbox/app/test.css + tests/system/src/test/resources/sandbox/app/test.fxml + tests/system/src/test/resources/sandbox/app/test.html + tests/system/src/test/resources/sandbox/test.policy From hang.vo at oracle.com Tue Mar 18 23:47:40 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 18 Mar 2014 23:47:40 +0000 Subject: hg: openjfx/8u-dev/rt: [Accessibility] Tree clean up, implement expand/collapse for windows, remove Attribute.NEXT_SIBLING, PREVIOUS_SIBLING, remove TreeCell ugly helpers, use indices on the same currency Message-ID: <201403182347.s2INlpjq004587@aojmv0008> Changeset: 579fbfe34c8c Author: Felipe Heidrich Date: 2014-03-18 16:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/579fbfe34c8c [Accessibility] Tree clean up, implement expand/collapse for windows, remove Attribute.NEXT_SIBLING, PREVIOUS_SIBLING, remove TreeCell ugly helpers, use indices on the same currency ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Attribute.java From steve.x.northover at oracle.com Wed Mar 19 00:06:52 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 18 Mar 2014 17:06:52 -0700 Subject: Accessibility in OpenJFX: The Saga Continues Message-ID: <5328DF9C.4090803@oracle.com> Hi all, We've been looking at Accessibility in FX for quite a while now and it has proved a very difficult component to implement. For one reason or another it has simply not made it into the toolkit. Accessibility is a critical component and one that is essential for a number of reasons. I'm pleased to announce that we've been working hard to tame the beast: https://wiki.openjdk.java.net/display/OpenJFX/Accessibility+Exploration The results of this exploration are looking really good. Just like previous accessibility implementations, the plan is to make the code available in OpenJFX, but have it be disabled by default until it is ready. Fortunately, the Accessibility API is small and the code does not run unless triggered by the screen reader. This allows us to include the implementation before it is ready without destabilizing the code base. The idea behind releasing Accessibility now is to allow people to try the code and contribute. It is important to understand that we are at the alpha stage in development. The API is not settled and neither is the implementation, but we have reached the point where we have proved the design with working code. Working code is worth its weight in gold, especially when dealing with the low level details of different operating systems. If not careful, it is quite easy to design an API that cannot be implemented on a particular platform and then be stuck with it. There is nothing official in terms of the release date, but as important dates get closer (8u20, 8u40 and 9), we will be evaluating where we are at. This might mean that the experimental Accessibility API may disappear temporarily only to reappear quickly in the early days of the next release. There will be no API before its time. Please follow along with us in JIRA, on this list and in the wikihttps://wiki.openjdk.java.net/display/OpenJFX/Accessibility You will need to set -Djavafx.accessible=true to enable accessibility (it is disabled by default). Currently only Windows 8 and Mac OSX 10.9 are supported. Of course, Windows 7 and Mac 10.8 need to eventually work too and the brave among you can force the code to run using -Djavafx.accessible.force=true. We are at the point where we're looking for community involvement in testing and implementation. We are not yet ready for third party controls. First, we need to get the built in FX controls working to be accessible and then use what we have learned. Thanks for being so patient with us, Steve From randahl at rockit.dk Wed Mar 19 08:46:32 2014 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 19 Mar 2014 09:46:32 +0100 Subject: Backwards compatibility broken: Why was Color made final Message-ID: <0FF00690-FE50-49AA-A830-163FBA8D3CF9@rockit.dk> After upgrading to FX8, the framework I have been developing since the early access release of JavaFX three years ago is now broken. My framework has some really cool features for working with color, which relies on our own class PaletteColor which extends javafx.scene.paint.Color. Why would you, after three years, make the Color class final, thereby breaking backwards compatibility? I would really like to know the thoughts behind that decision. Yours Randahl From johan at lodgon.com Wed Mar 19 11:17:59 2014 From: johan at lodgon.com (Johan Vos) Date: Wed, 19 Mar 2014 12:17:59 +0100 Subject: recognizing gestures Message-ID: Hi, At this moment, we can detect SWIPE gestures on Android since the quantum toolkit has a SwipeGestureRecognizer. While everything seems to be in place to add more implementations of GestureRecognizer, I don't see them. Are there plans to add e.g. ZoomGestureRecognizer and RotateGestureRecognizer? The alternative is that we detect the gestures using the Android API's in the FXActivity launch class, send them through the native layer, and pick them up the way we do with touchEvents in general. That's ok, but I wanted to check first in order to avoid duplicate work. - Johan From martin.sladecek at oracle.com Wed Mar 19 11:25:33 2014 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Wed, 19 Mar 2014 12:25:33 +0100 Subject: Backwards compatibility broken: Why was Color made final In-Reply-To: <0FF00690-FE50-49AA-A830-163FBA8D3CF9@rockit.dk> References: <0FF00690-FE50-49AA-A830-163FBA8D3CF9@rockit.dk> Message-ID: <53297EAD.2000904@oracle.com> Here's the related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31746 -Martin On 03/19/2014 09:46 AM, Randahl Fink Isaksen wrote: > After upgrading to FX8, the framework I have been developing since the early access release of JavaFX three years ago is now broken. > > My framework has some really cool features for working with color, which relies on our own class PaletteColor which extends javafx.scene.paint.Color. > > Why would you, after three years, make the Color class final, thereby breaking backwards compatibility? > > I would really like to know the thoughts behind that decision. > > Yours > > Randahl > From johan at lodgon.com Wed Mar 19 11:25:46 2014 From: johan at lodgon.com (Johan Vos) Date: Wed, 19 Mar 2014 12:25:46 +0100 Subject: Congratulations Message-ID: Hi, I hate sending non-technical messages to a technical mailinglist. But for this special occasion, I'm making an exception. I am extremely glad and relieved that JavaFX has made its way into the mainstream Java distribution. JavaFX is now the way to write Java Client applications, and there is no going back. (next todo for the whole community: increase the number of Java Client Apps ;)) Big congratulations to the whole JavaFX team, and all the early users, customers and supporters. Thank you. - Johan From seeon.birger at oracle.com Wed Mar 19 12:00:45 2014 From: seeon.birger at oracle.com (Seeon Birger) Date: Wed, 19 Mar 2014 05:00:45 -0700 (PDT) Subject: recognizing gestures In-Reply-To: References: Message-ID: <13607da1-0b4b-4743-960b-d74819d20737@default> Hi Johan, I'm currently working on implementations for ZoomGestureRecognizer and RotateGestureRecognizer, so you can expect them to be added soon.. :) Regards, Seeon -----Original Message----- From: Johan Vos [mailto:johan at lodgon.com] Sent: Wednesday, 19 March 2014 13:18 To: openjfx-dev at openjdk.java.net Mailing Subject: recognizing gestures Hi, At this moment, we can detect SWIPE gestures on Android since the quantum toolkit has a SwipeGestureRecognizer. While everything seems to be in place to add more implementations of GestureRecognizer, I don't see them. Are there plans to add e.g. ZoomGestureRecognizer and RotateGestureRecognizer? The alternative is that we detect the gestures using the Android API's in the FXActivity launch class, send them through the native layer, and pick them up the way we do with touchEvents in general. That's ok, but I wanted to check first in order to avoid duplicate work. - Johan From johan at lodgon.com Wed Mar 19 12:04:07 2014 From: johan at lodgon.com (Johan Vos) Date: Wed, 19 Mar 2014 13:04:07 +0100 Subject: recognizing gestures In-Reply-To: <13607da1-0b4b-4743-960b-d74819d20737@default> References: <13607da1-0b4b-4743-960b-d74819d20737@default> Message-ID: Excellent! Thanks for letting me know, that really saves lots of otherwise duplicate work. - Johan 2014-03-19 13:00 GMT+01:00 Seeon Birger : > Hi Johan, > > I'm currently working on implementations for ZoomGestureRecognizer and > RotateGestureRecognizer, so you can expect them to be added soon.. :) > > Regards, > Seeon > > -----Original Message----- > From: Johan Vos [mailto:johan at lodgon.com] > Sent: Wednesday, 19 March 2014 13:18 > To: openjfx-dev at openjdk.java.net Mailing > Subject: recognizing gestures > > Hi, > > At this moment, we can detect SWIPE gestures on Android since the quantum > toolkit has a SwipeGestureRecognizer. While everything seems to be in place > to add more implementations of GestureRecognizer, I don't see them. Are > there plans to add e.g. ZoomGestureRecognizer and RotateGestureRecognizer? > > The alternative is that we detect the gestures using the Android API's in > the FXActivity launch class, send them through the native layer, and pick > them up the way we do with touchEvents in general. > That's ok, but I wanted to check first in order to avoid duplicate work. > > - Johan > From felix.bembrick at gmail.com Wed Mar 19 12:05:35 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 19 Mar 2014 23:05:35 +1100 Subject: Congratulations In-Reply-To: References: Message-ID: I totally agree with Johan except that I would say that JavaFX is not only the way to write *Java* client applications but is a way to *rewrite* client applications developed using any language or technologies because it is simply the best GUI toolkit out there, especially when you consider that it comes with the enormous and vast functionality available as standard in the Java platform and libraries. JavaFX is a *killer* technology. I have surveyed all other options for cross-platform application/app development and nothing else stacks up. It's that simple. And over time, it's advantage over HTML5 for example will only grow. And, who wants to use any language other than Java (or a JVM language)? C++ or Objective-C anyone? Not me! So yes, a big THANK YOU to Richard and his team and everyone at Oracle and all the other individuals and 3rd parties who have contributed to getting JavaFX (and Java) to where it is today. You guys/gals should be really proud :-) On 19 March 2014 22:25, Johan Vos wrote: > Hi, > > I hate sending non-technical messages to a technical mailinglist. But for > this special occasion, I'm making an exception. > I am extremely glad and relieved that JavaFX has made its way into the > mainstream Java distribution. JavaFX is now the way to write Java Client > applications, and there is no going back. (next todo for the whole > community: increase the number of Java Client Apps ;)) > > Big congratulations to the whole JavaFX team, and all the early users, > customers and supporters. Thank you. > > - Johan > From rafi.tayar at oracle.com Wed Mar 19 13:48:03 2014 From: rafi.tayar at oracle.com (Rafi Tayar) Date: Wed, 19 Mar 2014 06:48:03 -0700 (PDT) Subject: [8u] review request : RT-35618 IMX6-SDP / Yocto hard float : hello.HelloButton : the highlighting blue rectangle is missing the bottom blue line in each of the top two buttons Message-ID: Lisa, Daniel, Please review the patch attached to the Jira : https://javafx-jira.kenai.com/browse/RT-35618 Thanks, Rafi From kevin.rushforth at oracle.com Wed Mar 19 14:30:34 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Mar 2014 07:30:34 -0700 Subject: Backwards compatibility broken: Why was Color made final In-Reply-To: <0FF00690-FE50-49AA-A830-163FBA8D3CF9@rockit.dk> References: <0FF00690-FE50-49AA-A830-163FBA8D3CF9@rockit.dk> Message-ID: <5329AA0A.7040604@oracle.com> Hi Randhal, The reasons are captured in the description of RT-31746 which was the JIRA used to track this change in FX 8. The fact that Color wasn't final was an unfortunate oversight in FX 2. -- Kevin Randahl Fink Isaksen wrote: > After upgrading to FX8, the framework I have been developing since the early access release of JavaFX three years ago is now broken. > > My framework has some really cool features for working with color, which relies on our own class PaletteColor which extends javafx.scene.paint.Color. > > Why would you, after three years, make the Color class final, thereby breaking backwards compatibility? > > I would really like to know the thoughts behind that decision. > > Yours > > Randahl > > From hang.vo at oracle.com Wed Mar 19 14:48:01 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 14:48:01 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403191448.s2JEmIuL017470@aojmv0008> Changeset: 9823085ebf0e Author: David Grieve Date: 2014-03-19 10:42 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9823085ebf0e RT-32573: Change Legend to extend from TilePane rather than managing its own layout. Reviewed by: Martin ! modules/controls/src/main/java/com/sun/javafx/charts/Legend.java ! modules/controls/src/main/java/javafx/scene/chart/Chart.java Changeset: 8a0dd88b5456 Author: Danno Ferrin (shemnon) Date: 2014-03-19 08:46 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a0dd88b5456 RT-35635: A more aggressive disabling of the test ! modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacAppStoreBundlerTest.java From tomas.mikula at gmail.com Wed Mar 19 16:12:02 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 19 Mar 2014 17:12:02 +0100 Subject: EasyBind: custom bindings made easy (with lambdas) Message-ID: Hi all, I just released EasyBind (http://www.fxmisc.org/easybind/), a tiny library with several factory methods to create bindings using lambdas. The most prominent feature is probably the type-safe select binding based on this feature request for JavaFX 9: https://javafx-jira.kenai.com/browse/RT-35923. Regards, Tomas From richard.bair at oracle.com Wed Mar 19 16:34:15 2014 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 19 Mar 2014 09:34:15 -0700 Subject: EasyBind: custom bindings made easy (with lambdas) In-Reply-To: References: Message-ID: <54D381F4-78BD-4A99-A91B-1930BF8AA80A@oracle.com> Ah, this is really nice! Binding bb = EasyBind.select(control.sceneProperty()) .select(s -> s.windowProperty()) .selectObject(w -> w.showingProperty()); On Mar 19, 2014, at 9:12 AM, Tomas Mikula wrote: > Hi all, > > I just released EasyBind (http://www.fxmisc.org/easybind/), a tiny > library with several factory methods to create bindings using lambdas. > The most prominent feature is probably the type-safe select binding > based on this feature request for JavaFX 9: > https://javafx-jira.kenai.com/browse/RT-35923. > > Regards, > Tomas From lisa.selle at oracle.com Wed Mar 19 17:08:19 2014 From: lisa.selle at oracle.com (Lisa Selle) Date: Wed, 19 Mar 2014 13:08:19 -0400 Subject: [8u6] review request: RT-34982 IMX6 - cursor image is seen even though a mouse is not plugged in Message-ID: <5329CF03.4060906@oracle.com> Rafi and Daniel, Please review the fix for https://javafx-jira.kenai.com/browse/RT-34982. Patch included in jira. Thanks, Lisa From hang.vo at oracle.com Wed Mar 19 18:17:20 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 18:17:20 +0000 Subject: hg: openjfx/8u-dev/rt: Fixed RT-36178: Printing: Scene is not printed when blending is used. Message-ID: <201403191817.s2JIHW3Q021256@aojmv0008> Changeset: d1d4b24e037d Author: prr Date: 2014-03-19 11:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d1d4b24e037d Fixed RT-36178: Printing: Scene is not printed when blending is used. Reviewed-by: flar ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPresentable.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DRTTexture.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DResourceFactory.java ! modules/graphics/src/main/java/com/sun/prism/j2d/PrismPrintGraphics.java From tbee at tbee.org Wed Mar 19 18:21:25 2014 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 19 Mar 2014 19:21:25 +0100 Subject: CircularPane Message-ID: <5329E025.5020102@tbee.org> For those interested, I've just put an implementation of a CircularPane in JFXtras-labs. http://jfxtras.org/images/gallery/CircularPane.png One never knows how to put such a thing to use. Regards, Tom From han.solo at muenster.de Wed Mar 19 18:29:01 2014 From: han.solo at muenster.de (Gerrit Grunwald) Date: Wed, 19 Mar 2014 19:29:01 +0100 Subject: CircularPane In-Reply-To: <5329E025.5020102@tbee.org> References: <5329E025.5020102@tbee.org> Message-ID: <8F575334-1003-4255-8700-9019D2E54151@muenster.de> Very nice Tom, thanx for the contribution!!! Cheers, Gerrit > Am 19.03.2014 um 19:21 schrieb Tom Eugelink : > > > For those interested, I've just put an implementation of a CircularPane in JFXtras-labs. > > http://jfxtras.org/images/gallery/CircularPane.png > > One never knows how to put such a thing to use. > > Regards, Tom > > From richard.bair at oracle.com Wed Mar 19 18:46:35 2014 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 19 Mar 2014 11:46:35 -0700 Subject: Congratulations In-Reply-To: References: Message-ID: <7B2D2278-6ED9-4DDA-AAEB-F4F85E2E6191@oracle.com> > So yes, a big THANK YOU to Richard and his team and everyone at Oracle and > all the other individuals and 3rd parties who have contributed to getting > JavaFX (and Java) to where it is today. > > You guys/gals should be really proud :-) I agree, congrats to all the folks inside and outside Oracle that have been making tremendous contributions to JavaFX! A special thanks to Steve for really pushing OpenJFX as a real open source project with an open development process. We really want to work with the community on this project on an equal footing. We?ve had tons of valuable contributions in the form of bug fixes, blog posts, technical discussions, and patches. Keep up the great work! 8u20 has a big pile of bug fixes, so please do kick the tires on that one. Lots of great work going on in terms of Accessibility right now, also embedded work and as always performance work. Scene Builder is healthy and active, we?d love to see it embedded in all the IDEs and direct contributions from the community to Scene Builder would be fantastic. A big thanks to the porters brining JavaFX to Android/iOS and other platforms! Looking forward to 8u20 and Java 9! Richard From ngalarneau at ABINITIO.COM Wed Mar 19 18:51:35 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Wed, 19 Mar 2014 14:51:35 -0400 Subject: Congratulations In-Reply-To: <7B2D2278-6ED9-4DDA-AAEB-F4F85E2E6191@oracle.com> References: <7B2D2278-6ED9-4DDA-AAEB-F4F85E2E6191@oracle.com> Message-ID: Congratulations and Thank You to all of the JavaFX folks! Richard, in one of your Java One talks you spoke about opening up the OpenJFX project further. Will there be discussions on the list as to what is coming next? Thanks, Neil From: Richard Bair To: Felix Bembrick Cc: "openjfx-dev at openjdk.java.net Mailing" Date: 03/19/2014 02:46 PM Subject: Re: Congratulations Sent by: "openjfx-dev" > So yes, a big THANK YOU to Richard and his team and everyone at Oracle and > all the other individuals and 3rd parties who have contributed to getting > JavaFX (and Java) to where it is today. > > You guys/gals should be really proud :-) I agree, congrats to all the folks inside and outside Oracle that have been making tremendous contributions to JavaFX! A special thanks to Steve for really pushing OpenJFX as a real open source project with an open development process. We really want to work with the community on this project on an equal footing. We?ve had tons of valuable contributions in the form of bug fixes, blog posts, technical discussions, and patches. Keep up the great work! 8u20 has a big pile of bug fixes, so please do kick the tires on that one. Lots of great work going on in terms of Accessibility right now, also embedded work and as always performance work. Scene Builder is healthy and active, we?d love to see it embedded in all the IDEs and direct contributions from the community to Scene Builder would be fantastic. A big thanks to the porters brining JavaFX to Android/iOS and other platforms! Looking forward to 8u20 and Java 9! Richard NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From richard.bair at oracle.com Wed Mar 19 18:53:48 2014 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 19 Mar 2014 11:53:48 -0700 Subject: Congratulations In-Reply-To: References: <7B2D2278-6ED9-4DDA-AAEB-F4F85E2E6191@oracle.com> Message-ID: <647B6E57-4723-427E-B128-9D84BEC721EA@oracle.com> Hi Neil, Yes, I expect that feature planning for 9 and so forth should happen on this list and I hope will be in large part driven by those features / bugs / ideas that come from people in the community, and that they would include code contributions to help get it done :-) Richard On Mar 19, 2014, at 11:51 AM, ngalarneau at ABINITIO.COM wrote: > Congratulations and Thank You to all of the JavaFX folks! > > Richard, in one of your Java One talks you spoke about opening up the OpenJFX project further. > > Will there be discussions on the list as to what is coming next? > > > Thanks, > > Neil > > > > > From: Richard Bair > To: Felix Bembrick > Cc: "openjfx-dev at openjdk.java.net Mailing" > Date: 03/19/2014 02:46 PM > Subject: Re: Congratulations > Sent by: "openjfx-dev" > > > > > So yes, a big THANK YOU to Richard and his team and everyone at Oracle and > > all the other individuals and 3rd parties who have contributed to getting > > JavaFX (and Java) to where it is today. > > > > You guys/gals should be really proud :-) > > I agree, congrats to all the folks inside and outside Oracle that have been making tremendous contributions to JavaFX! A special thanks to Steve for really pushing OpenJFX as a real open source project with an open development process. We really want to work with the community on this project on an equal footing. We?ve had tons of valuable contributions in the form of bug fixes, blog posts, technical discussions, and patches. Keep up the great work! 8u20 has a big pile of bug fixes, so please do kick the tires on that one. Lots of great work going on in terms of Accessibility right now, also embedded work and as always performance work. Scene Builder is healthy and active, we?d love to see it embedded in all the IDEs and direct contributions from the community to Scene Builder would be fantastic. A big thanks to the porters brining JavaFX to Android/iOS and other platforms! Looking forward to 8u20 and Java 9! > > Richard > > > > NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From peter.penzov at gmail.com Wed Mar 19 19:09:02 2014 From: peter.penzov at gmail.com (Peter Penzov) Date: Wed, 19 Mar 2014 21:09:02 +0200 Subject: Create ContextMenu in Task Message-ID: Hi, I'm working on a application which is using Task to load content. I have a Context Menu insight the Task which is not working due to these problems: https://javafx-jira.kenai.com/browse/RT-25127 https://javafx-jira.kenai.com/browse/RT-17716 This is a limitation. Is there any plans to fix these issues? BR, Peter From hang.vo at oracle.com Wed Mar 19 20:17:47 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 20:17:47 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403192018.s2JKI6TM012624@aojmv0008> Changeset: c9411d50a822 Author: hudson Date: 2014-03-19 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c9411d50a822 Added tag 8u20-b06 for changeset c7f043d40430 ! .hgtags Changeset: 7123e5a61cee Author: kcr Date: 2014-03-19 13:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7123e5a61cee Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8u/master/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleButton.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleCheckBox.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleControl.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleList.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleListItem.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleMenuButton.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleRadioButton.java - modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleSlider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleBasePatternProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleBaseProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleLogger.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleAttributes.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleBasePatternProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleBaseProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleEventIds.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleRoles.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleRoot.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleSelectionItemProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleSelectionProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/mac/MacAccessibleToggleProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleBasePatternProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleBaseProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleGridItemProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleGridProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleRangeValueProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleRoot.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleSelectionItemProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleSelectionProvider.java - modules/graphics/src/main/java/com/sun/glass/ui/accessible/win/WinAccessibleToggleProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/AccessibleNode.java - modules/graphics/src/main/java/com/sun/javafx/accessible/AccessibleStage.java - modules/graphics/src/main/java/com/sun/javafx/accessible/AccessibleText.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/Accessible.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/AccessibleProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/AccessibleStageProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/ExpandCollapseProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/GridItemProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/GridProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/InvokeProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/RangeValueProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/SelectionItemProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/SelectionProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/ToggleProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/providers/ValueProvider.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ControlTypeIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/EventIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ExpandCollapseState.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/NavigateDirection.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/OrientationType.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/PatternIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/PropertyIds.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ProviderOptions.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/Rect.java - modules/graphics/src/main/java/com/sun/javafx/accessible/utils/ToggleState.java - modules/graphics/src/main/native-glass/mac/GlassAccessibleBaseProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleBaseProvider.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleRoot.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleRoot.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionItemProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionItemProvider.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleSelectionProvider.m - modules/graphics/src/main/native-glass/mac/GlassAccessibleToggleProvider.h - modules/graphics/src/main/native-glass/mac/GlassAccessibleToggleProvider.m - modules/graphics/src/main/native-glass/win/AccessibleBasePatternProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleBasePatternProvider.h - modules/graphics/src/main/native-glass/win/AccessibleBaseProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleBaseProvider.h - modules/graphics/src/main/native-glass/win/AccessibleGridItemProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleGridItemProvider.h - modules/graphics/src/main/native-glass/win/AccessibleGridProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleGridProvider.h - modules/graphics/src/main/native-glass/win/AccessibleRangeValueProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleRangeValueProvider.h - modules/graphics/src/main/native-glass/win/AccessibleRoot.cpp - modules/graphics/src/main/native-glass/win/AccessibleRoot.h - modules/graphics/src/main/native-glass/win/AccessibleSelectionItemProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleSelectionItemProvider.h - modules/graphics/src/main/native-glass/win/AccessibleSelectionProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleSelectionProvider.h - modules/graphics/src/main/native-glass/win/AccessibleToggleProvider.cpp - modules/graphics/src/main/native-glass/win/AccessibleToggleProvider.h From hang.vo at oracle.com Wed Mar 19 20:32:56 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 20:32:56 +0000 Subject: hg: openjfx/8u-dev/rt: 3 new changesets Message-ID: <201403192033.s2JKXJ7g014831@aojmv0008> Changeset: 4dc1ba8b86ee Author: David Grieve Date: 2014-03-19 16:19 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4dc1ba8b86ee [DOCS-ONLY] RT-23933: clarify the affect of the -fx-tooltip-visible property on the Pagination control. ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 96ca9d80b159 Author: David Grieve Date: 2014-03-19 16:19 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/96ca9d80b159 RT-24086: disallow uni-directional bind on currentPageIndex ! modules/controls/src/main/java/javafx/scene/control/Pagination.java ! modules/controls/src/test/java/javafx/scene/control/PaginationTest.java Changeset: 9940be2f94f3 Author: David Grieve Date: 2014-03-19 16:19 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9940be2f94f3 RT-36283: override Legend computePrefWidth/Height to return zero if there are no legend items ! modules/controls/src/main/java/com/sun/javafx/charts/Legend.java From hang.vo at oracle.com Wed Mar 19 21:13:49 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 21:13:49 +0000 Subject: hg: openjfx/2u/dev/rt: 2 new changesets Message-ID: <201403192113.s2JLDoml022120@aojmv0008> Changeset: 350a698900e9 Author: hudson Date: 2014-03-12 14:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/350a698900e9 Added tag 2.2.60-b10 for changeset 143b27648d96 ! .hgtags Changeset: c1541c2d6a96 Author: hudson Date: 2014-03-19 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/c1541c2d6a96 Added tag 2.2.60-b11 for changeset 350a698900e9 ! .hgtags From hang.vo at oracle.com Wed Mar 19 21:47:32 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 21:47:32 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403192147.s2JLln6Z026825@aojmv0008> Changeset: 7ecb97f4d8ff Author: felipe Date: 2014-03-19 14:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7ecb97f4d8ff remove unused import ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java Changeset: 6b8ba389829c Author: felipe Date: 2014-03-19 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6b8ba389829c improve JNI code ! modules/graphics/src/main/native-glass/win/GlassAccessible.cpp ! modules/graphics/src/main/native-glass/win/GlassTextRangeProvider.cpp From hang.vo at oracle.com Wed Mar 19 23:03:14 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 23:03:14 +0000 Subject: hg: openjfx/8u-dev/rt: RT-34973: TextArea: the next line is selected when triple clicking the last word of a line. Message-ID: <201403192303.s2JN3Qbp008885@aojmv0008> Changeset: 54d4f4b10dec Author: leifs Date: 2014-03-19 15:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/54d4f4b10dec RT-34973: TextArea: the next line is selected when triple clicking the last word of a line. ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java From hang.vo at oracle.com Wed Mar 19 23:47:36 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 19 Mar 2014 23:47:36 +0000 Subject: hg: openjfx/8u-dev/rt: [Accessibility] improve JNI code Message-ID: <201403192347.s2JNllZJ017168@aojmv0008> Changeset: 27df155347e9 Author: Felipe Heidrich Date: 2014-03-19 16:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27df155347e9 [Accessibility] improve JNI code ! modules/graphics/src/main/native-glass/mac/GlassAccessible.m From hang.vo at oracle.com Thu Mar 20 00:02:56 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 20 Mar 2014 00:02:56 +0000 Subject: hg: openjfx/8u-dev/rt: RT-29629: redirect navigation control mouse events to behavior. Message-ID: <201403200003.s2K037sC019682@aojmv0008> Changeset: c58357d30622 Author: David Grieve Date: 2014-03-19 19:49 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c58357d30622 RT-29629: redirect navigation control mouse events to behavior. Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java From james.graham at oracle.com Thu Mar 20 02:01:29 2014 From: james.graham at oracle.com (Jim Graham) Date: Wed, 19 Mar 2014 19:01:29 -0700 Subject: Opacity in Image.getPixelReader.getColor() In-Reply-To: <532755F6.7000906@bestsolution.at> References: <53259F5D.30108@bestsolution.at> <8D512025-89FF-44FC-87C3-1795D4B87F65@oracle.com> <53272AE2.1070004@oracle.com> <532755F6.7000906@bestsolution.at> Message-ID: <532A4BF9.90507@oracle.com> Kevin and Jasper hit the nail on the head (Jasper's comment that the words are usually associated with particular ranges is mostly true AFAIRemember, but I can't guarantee it). If there is part of the documentation here that could be made clearer, let us know... ...jim On 3/17/14 1:07 PM, Tom Schindl wrote: > Hi, > > Yes it looks like i mixed this up with transparency! > > Tom > > On 17.03.14 10:03, Kevin Rushforth wrote: >> I'm sure Jim could word this better, but here goes... >> >> Opacity and alpha are mostly used interchangeably. Whether the range is >> expressed as a normalized value [0.0,1.0] or an 8-bit pixel value >> [0,255], the meaning is the same. A value of 0 means that the color is >> completely transparent. When using the default SRC_OVER blend equation, >> a pixel with this color will have no effect. A value of 1.0 (if using a >> normalized value) or 255 (if using an 8-bit integer value) means that >> the color is fully opaque. When using the default SRC_OVER blend >> equation, a pixel with this color will overwrite whatever is underneath it. >> >> Perhaps Tom is thinking of "transparency" which, if we were to have such >> an attribute, would be defined as (1.0-opacity). >> >> -- Kevin >> >> >> Jasper Potts wrote: >>> My understanding is alpha and opacity are same just different range. >>> Opacity is 0.0 to 1.0 >>> Alpha is 0 to 255 >>> >>> Jim or Kevin will be authority on this. >>> Jasper >>> >>> >>>> On Mar 16, 2014, at 5:55 AM, Tom Schindl >>>> wrote: >>>> >>>> Hi, >>>> >>>> Maybe I'm completely wrong but to me it looks like the opacity I get >>>> from Image.getPixelReader.getColor() is wrong. >>>> >>>> If not mistaken the relation between alpha and opacity is expressed >>>> with: >>>> >>>> opacity = (255 - alpha) / 255.0 >>>> >>>> which means: >>>> >>>> opacity 0 => alpha 255 >>>> opacity 1 => alpha 0 >>>> >>>> Running the following programm on a gif >>>> >>>> >>>>> public class OpacityBug extends Application { >>>>> >>>>> @Override >>>>> public void start(Stage primaryStage) throws Exception { >>>>> Image image = new >>>>> Image(getClass().getResourceAsStream("methpri_obj.gif")); >>>>> int width = (int) image.getWidth(); >>>>> int height = (int) image.getHeight(); >>>>> PixelReader reader = image.getPixelReader(); >>>>> for (int x = width - 1; x >= 0; x--) { >>>>> for (int y = height - 1; y >= 0; y--) { >>>>> int argb = reader.getArgb(x, y); >>>>> int alphaArgb = (argb >> 24) & 0xFF; >>>>> Color color = reader.getColor(x, y); >>>>> double opacity = color.getOpacity(); >>>>> System.err.println(x+","+y + " => alpha: " + >>>>> alphaArgb + " op: " + opacity + " op-alpha: " + >>>>> opacityToAlpha(opacity) + " color: " + color); >>>>> } >>>>> } >>>>> } >>>>> private static int opacityToAlpha(double opacity) { >>>>> return (int)Math.round((((opacity * 255.0) - 255) * -1)); >>>>> } >>>>> >>>>> public static void main(String[] args) { >>>>> Application.launch(args); >>>>> } >>>>> } >>>>> >>>> produces and output like: >>>> 15,15 => alpha: 0 op: 0.0 op-alpha: 255 color: 0x00000000 >>>> >>>> which to my understanding is wrong. The argb value is correct (if >>>> compared to the image because the pixel at 15,15 is fully transparent) >>>> but then the the opacity should be 1.0 but is the opposite. >>>> >>>> Looking at the code in Image I see: >>>> >>>>> @Override >>>>> public Color getColor(int x, int y) { >>>>> int argb = getArgb(x, y); >>>>> int a = argb >>> 24; >>>>> int r = (argb >> 16) & 0xff; >>>>> int g = (argb >> 8) & 0xff; >>>>> int b = (argb ) & 0xff; >>>>> return Color.rgb(r, g, b, a / 255.0); >>>>> } >>>>> >>>> which means that: >>>> a) my formula from the above is wrong >>>> b) or there's the bug because it should be >>>> return Color.rgb(r, g, b, (255 - a) / 255.0); >>>> >>>> May I also suggest to add get a >>>> - Color.argb(int r,int g,int b,int alpha) >>>> maybe it is just me but I'm so much more used to alpha than opacity that >>>> I always have to look it up when i need it. >>>> >>>> Tom >>>> > From hang.vo at oracle.com Thu Mar 20 06:47:22 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 20 Mar 2014 06:47:22 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36256 Using showAndWait in the onFinished EventHandler of an Animation doesn't work Message-ID: <201403200647.s2K6lXet018098@aojmv0008> Changeset: c5ebcc5268b4 Author: Martin Sladecek Date: 2014-03-20 07:38 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c5ebcc5268b4 RT-36256 Using showAndWait in the onFinished EventHandler of an Animation doesn't work Reviewed by: kcr ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/javafx/stage/Stage.java From hang.vo at oracle.com Thu Mar 20 10:03:19 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 20 Mar 2014 10:03:19 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403201003.s2KA3bIo015819@aojmv0008> Changeset: 492c42c21d9f Author: Anthony Petrov Date: 2014-03-20 13:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/492c42c21d9f RT-36267: [Accessibility] Fix LABELED_BY on Windows Reviewed-by: fheidric ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Attribute.java Changeset: 5852ce9869cd Author: Rafi Tayar Date: 2014-03-20 11:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5852ce9869cd RT-35618 IMX6-SDP / Yocto hard float : hello.HelloButton : the highlighting blue rectangle is missing the bottom blue line in each of the top two buttons Reviewed-by : kselle, dblaukopf ! apps/toys/Hello/src/main/java/hello/HelloButton.java From martin.sladecek at oracle.com Thu Mar 20 13:45:12 2014 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Thu, 20 Mar 2014 14:45:12 +0100 Subject: Review request: RT-36238, [Ensemble8] SwingInterop throws IllegalStateException: Not on FX application thread Message-ID: <532AF0E8.7050702@oracle.com> Lisa, please review the following change in Ensemble8: https://javafx-jira.kenai.com/browse/RT-36238 http://cr.openjdk.java.net/~msladecek/rt-36238/webrev.00/ Thanks, -Martin From hrjet9 at gmail.com Thu Mar 20 15:12:06 2014 From: hrjet9 at gmail.com (HRJet) Date: Thu, 20 Mar 2014 20:42:06 +0530 Subject: Node.impl_getMatchingStyles Message-ID: Hi, >From previous discussions, it seems like Node.impl_getMatchingStyles() is going to be made a public API. The lastest reference I can find is in June 2013: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-June/008370.html In the source code, the ticket number for this is RT-21096, but I am not able to view it in JIRA. Just wanted to know what is the status of this. Is it still planned to be made public and if so when? thanks, HRJ From kevin.rushforth at oracle.com Thu Mar 20 15:24:43 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Mar 2014 08:24:43 -0700 Subject: Node.impl_getMatchingStyles In-Reply-To: References: Message-ID: <532B083B.1080308@oracle.com> I just made RT-21096 visible. We have no concrete plan to implement this, but David Grieve might wish to comment. -- Kevin HRJet wrote: > Hi, > > From previous discussions, it seems like Node.impl_getMatchingStyles() is > going to be made a public API. > > The lastest reference I can find is in June 2013: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-June/008370.html > > In the source code, the ticket number for this is RT-21096, but I am not > able to view it in JIRA. > > Just wanted to know what is the status of this. Is it still planned to be > made public and if so when? > > thanks, > HRJ > From david.grieve at oracle.com Thu Mar 20 15:31:47 2014 From: david.grieve at oracle.com (David Grieve) Date: Thu, 20 Mar 2014 11:31:47 -0400 Subject: Node.impl_getMatchingStyles In-Reply-To: References: Message-ID: <532B09E3.2070309@oracle.com> The JIRA issue (now public) just says that these impl_ methods that SceneBuilder uses need to be public API. Much work needs to be done in the area of public API for accessing CSS styles and whatnot. But, unless I'm told otherwise, there won't be any implementation of such an API before 9. FYI, the two impl_ methods mentioned in the bug are likely to be removed altogether in 9. On 3/20/14, 11:12 AM, HRJet wrote: > Hi, > > From previous discussions, it seems like Node.impl_getMatchingStyles() is > going to be made a public API. > > The lastest reference I can find is in June 2013: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-June/008370.html > > In the source code, the ticket number for this is RT-21096, but I am not > able to view it in JIRA. > > Just wanted to know what is the status of this. Is it still planned to be > made public and if so when? > > thanks, > HRJ From david.grieve at oracle.com Thu Mar 20 15:47:30 2014 From: david.grieve at oracle.com (David Grieve) Date: Thu, 20 Mar 2014 11:47:30 -0400 Subject: [8u Review Request] RT-36808: items added to AreaChart have no symbol Message-ID: <532B0D92.9070803@oracle.com> Jonathan, Please review http://cr.openjdk.java.net/~dgrieve/RT-36068/webrev.00/ Details of the change can be found in https://javafx-jira.kenai.com/browse/RT-36068 Thanks, -- David From hang.vo at oracle.com Thu Mar 20 19:03:17 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 20 Mar 2014 19:03:17 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403201903.s2KJ3YHg009684@aojmv0008> Changeset: a0a619f9f425 Author: Lisa.Selle at oracle.com Date: 2014-03-20 14:49 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a0a619f9f425 RT-34982 - IMX6 - cursor image is seen even though a mouse is not plugged in. Adjust cursor logic to properly show/hide the cursor depending on whether or not a pointing device is connected. Reviewed by Rafi Tayar. Tested with HelloCursors. ! modules/graphics/src/main/native-glass/lens/lensport/imx6Cursor.c Changeset: f005f3f08277 Author: Felipe Heidrich Date: 2014-03-20 11:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f005f3f08277 [Accessibility] small JNI improvement, init VARIANT set to zero. ! modules/graphics/src/main/native-glass/win/GlassAccessible.cpp From swpalmer at gmail.com Thu Mar 20 19:54:42 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 20 Mar 2014 15:54:42 -0400 Subject: Lambda Lambda Message-ID: So I'm looking at Java 8 stuff now and I see that addListener has methods. One takes a ChangeListener, the other an InvalidationListener. So what does this do: Node n = getSomeNode(); n.managedProperty().addListener(x -> test(x)); Well it seems it adds an InvalidationListener. So I tried this: n.managedProperty().addListener(x -> test(x)); which seems to be accepted syntax, but it still adds an InvalidationListener !!! Help Please. Why didn't JavaFX 8 add two new methods: addChangeListener addInvalidationListener ? Scott From tom.schindl at bestsolution.at Thu Mar 20 19:57:54 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 20 Mar 2014 12:57:54 -0700 Subject: Proposal on getting warning free (controls) packages Message-ID: <532B4842.5010601@bestsolution.at> Hi, I've just started looking into getting the controls package warning free and/or suppress them in case not fixable. Most of the generic warnings I've come accross in a first pass involve StyleableProperty cast like this: ((StyleableProperty)graphicProperty()).applyStyle(origin, null); In fact above code has 2 warnings: a) unchecked type cast b) usage of raw-type the raw type in this case can be fixed with: ((StyleableProperty)graphicProperty()).applyStyle(origin, null); leaving us with the unchecked cast so we could add: @SuppressWarnings({ "unchecked" }) e.g. on the method but I'm uncertain this is a good idea because it might hide unchecked warnings we have a possibility to fix. So what are other options: a) Create a static helper in Util to make the cast and for us (we could even add it as a static method in the StyleableProperty-interface) b) provide a private/package-scoped method the public one delegates Both of them work but have different problems where I think b) has the bigger ones like blowing up class-file, modification of the field to be of type StyleableObjectProperty. I'd really like to get the source warning free. Thoughts? Tom From richard.bair at oracle.com Thu Mar 20 20:00:58 2014 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 20 Mar 2014 13:00:58 -0700 Subject: Lambda Lambda In-Reply-To: References: Message-ID: InvalidationListener has one param, ChangeListener has 3. So the arity of the lambda tells the compiler which kind to produce. If there was ambiguity, the compiler would complain. Richard On Mar 20, 2014, at 12:54 PM, Scott Palmer wrote: > So I'm looking at Java 8 stuff now and I see that addListener has > methods. One takes a ChangeListener, the other an > InvalidationListener. > > So what does this do: > > Node n = getSomeNode(); > n.managedProperty().addListener(x -> test(x)); > > Well it seems it adds an InvalidationListener. > > So I tried this: > > n.managedProperty().addListener(x -> test(x)); > > which seems to be accepted syntax, but it still adds an InvalidationListener !!! > > Help Please. > > Why didn't JavaFX 8 add two new methods: > addChangeListener > addInvalidationListener > > ? > > Scott From swpalmer at gmail.com Thu Mar 20 20:02:24 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 20 Mar 2014 16:02:24 -0400 Subject: Lambda Lambda In-Reply-To: References: Message-ID: Thanks.. just figured that out myself. As my colleague just said to me "the world is good again" On Thu, Mar 20, 2014 at 4:00 PM, Richard Bair wrote: > InvalidationListener has one param, ChangeListener has 3. So the arity of the lambda tells the compiler which kind to produce. If there was ambiguity, the compiler would complain. > > Richard > > On Mar 20, 2014, at 12:54 PM, Scott Palmer wrote: > >> So I'm looking at Java 8 stuff now and I see that addListener has >> methods. One takes a ChangeListener, the other an >> InvalidationListener. >> >> So what does this do: >> >> Node n = getSomeNode(); >> n.managedProperty().addListener(x -> test(x)); >> >> Well it seems it adds an InvalidationListener. >> >> So I tried this: >> >> n.managedProperty().addListener(x -> test(x)); >> >> which seems to be accepted syntax, but it still adds an InvalidationListener !!! >> >> Help Please. >> >> Why didn't JavaFX 8 add two new methods: >> addChangeListener >> addInvalidationListener >> >> ? >> >> Scott > From hang.vo at oracle.com Thu Mar 20 20:03:18 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 20 Mar 2014 20:03:18 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36068: if animating, add item to plot children in onFinished handler of first KeyFrame. Message-ID: <201403202003.s2KK3UbJ018532@aojmv0008> Changeset: 901931021129 Author: David Grieve Date: 2014-03-20 15:43 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/901931021129 RT-36068: if animating, add item to plot children in onFinished handler of first KeyFrame. Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/AreaChart.java ! modules/controls/src/main/java/javafx/scene/chart/BubbleChart.java ! modules/controls/src/main/java/javafx/scene/chart/LineChart.java ! modules/controls/src/main/java/javafx/scene/chart/ScatterChart.java ! modules/controls/src/main/java/javafx/scene/chart/StackedAreaChart.java ! modules/controls/src/test/java/javafx/scene/chart/LineChartTest.java From jonathan.giles at oracle.com Thu Mar 20 20:03:27 2014 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 21 Mar 2014 09:03:27 +1300 Subject: Proposal on getting warning free (controls) packages In-Reply-To: <532B4842.5010601@bestsolution.at> References: <532B4842.5010601@bestsolution.at> Message-ID: <532B498F.50901@oracle.com> I'll leave it to David to comment on the specifics of these warnings, but in general I'm very supportive of improving the quality of the controls code. It would be best to file a new jira issue and start putting patches up there (although for that to happen you'll need to email the patch to me so that I may attach it on your behalf). Thanks! -- Jonathan On 21/03/2014 8:57 a.m., Tom Schindl wrote: > Hi, > > I've just started looking into getting the controls package warning free > and/or suppress them in case not fixable. > > Most of the generic warnings I've come accross in a first pass involve > StyleableProperty cast like this: > > ((StyleableProperty)graphicProperty()).applyStyle(origin, null); > > In fact above code has 2 warnings: > a) unchecked type cast > b) usage of raw-type > > the raw type in this case can be fixed with: > > ((StyleableProperty)graphicProperty()).applyStyle(origin, null); > > leaving us with the unchecked cast so we could add: > > @SuppressWarnings({ "unchecked" }) > > e.g. on the method but I'm uncertain this is a good idea because it > might hide unchecked warnings we have a possibility to fix. > > So what are other options: > a) Create a static helper in Util to make the cast and for us (we could > even add it as a static method in the StyleableProperty-interface) > > b) provide a private/package-scoped method the public one delegates > > Both of them work but have different problems where I think b) has the > bigger ones like blowing up class-file, modification of the field to be > of type StyleableObjectProperty. > > I'd really like to get the source warning free. > > Thoughts? > > Tom From swpalmer at gmail.com Thu Mar 20 20:03:59 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 20 Mar 2014 16:03:59 -0400 Subject: Lambda Lambda In-Reply-To: References: Message-ID: So why doesn't this complain: n.managedProperty().addListener(x -> test(x)); "ChangeListener" has no business being there. Scott On Thu, Mar 20, 2014 at 4:02 PM, Scott Palmer wrote: > Thanks.. just figured that out myself. > As my colleague just said to me "the world is good again" > > On Thu, Mar 20, 2014 at 4:00 PM, Richard Bair wrote: >> InvalidationListener has one param, ChangeListener has 3. So the arity of the lambda tells the compiler which kind to produce. If there was ambiguity, the compiler would complain. >> >> Richard >> >> On Mar 20, 2014, at 12:54 PM, Scott Palmer wrote: >> >>> So I'm looking at Java 8 stuff now and I see that addListener has >>> methods. One takes a ChangeListener, the other an >>> InvalidationListener. >>> >>> So what does this do: >>> >>> Node n = getSomeNode(); >>> n.managedProperty().addListener(x -> test(x)); >>> >>> Well it seems it adds an InvalidationListener. >>> >>> So I tried this: >>> >>> n.managedProperty().addListener(x -> test(x)); >>> >>> which seems to be accepted syntax, but it still adds an InvalidationListener !!! >>> >>> Help Please. >>> >>> Why didn't JavaFX 8 add two new methods: >>> addChangeListener >>> addInvalidationListener >>> >>> ? >>> >>> Scott >> From richard.bair at oracle.com Thu Mar 20 20:06:00 2014 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 20 Mar 2014 13:06:00 -0700 Subject: Lambda Lambda In-Reply-To: References: Message-ID: I don?t know. On Mar 20, 2014, at 1:03 PM, Scott Palmer wrote: > So why doesn't this complain: > n.managedProperty().addListener(x -> test(x)); > > "ChangeListener" has no business being there. > > Scott > > On Thu, Mar 20, 2014 at 4:02 PM, Scott Palmer wrote: >> Thanks.. just figured that out myself. >> As my colleague just said to me "the world is good again" >> >> On Thu, Mar 20, 2014 at 4:00 PM, Richard Bair wrote: >>> InvalidationListener has one param, ChangeListener has 3. So the arity of the lambda tells the compiler which kind to produce. If there was ambiguity, the compiler would complain. >>> >>> Richard >>> >>> On Mar 20, 2014, at 12:54 PM, Scott Palmer wrote: >>> >>>> So I'm looking at Java 8 stuff now and I see that addListener has >>>> methods. One takes a ChangeListener, the other an >>>> InvalidationListener. >>>> >>>> So what does this do: >>>> >>>> Node n = getSomeNode(); >>>> n.managedProperty().addListener(x -> test(x)); >>>> >>>> Well it seems it adds an InvalidationListener. >>>> >>>> So I tried this: >>>> >>>> n.managedProperty().addListener(x -> test(x)); >>>> >>>> which seems to be accepted syntax, but it still adds an InvalidationListener !!! >>>> >>>> Help Please. >>>> >>>> Why didn't JavaFX 8 add two new methods: >>>> addChangeListener >>>> addInvalidationListener >>>> >>>> ? >>>> >>>> Scott >>> From lisa.selle at oracle.com Thu Mar 20 20:13:05 2014 From: lisa.selle at oracle.com (Lisa Selle) Date: Thu, 20 Mar 2014 16:13:05 -0400 Subject: [8u] reveiw request: RT-36308 Mouse sometimes jumps to edge of screen on first mouse move Message-ID: <532B4BD1.3040800@oracle.com> Rafi and Daniel, Please review the fix for: https://javafx-jira.kenai.com/browse/RT-36308 diff is in jira. Thanks, Lisa From tom.schindl at bestsolution.at Thu Mar 20 20:14:28 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 20 Mar 2014 13:14:28 -0700 Subject: Lambda Lambda In-Reply-To: References: Message-ID: <532B4C24.80400@bestsolution.at> If I do that in eclipse and hover it I see it still attaches a InvalidationListener! To me it looks like the compiler does not care about what you are trying to tell him because this syntax does only have a meaning on methods who don't declare a generic type in its signature! Tom On 20.03.14 13:03, Scott Palmer wrote: > n.managedProperty().addListener(x -> test(x)); From david.grieve at oracle.com Thu Mar 20 20:32:11 2014 From: david.grieve at oracle.com (David Grieve) Date: Thu, 20 Mar 2014 16:32:11 -0400 Subject: Proposal on getting warning free (controls) packages In-Reply-To: <532B498F.50901@oracle.com> References: <532B4842.5010601@bestsolution.at> <532B498F.50901@oracle.com> Message-ID: <532B504B.2080402@oracle.com> Too bad we can't go back and have WritableValue also extend Styleable... I'm happy to live with the @SuppressWarnings in this particular context since we know that graphicProperty is indeed a StyleableProperty, as is the case where we cast in implementations of the CssMetaData getStyleableProperty() method. The problem you cite could also be solved by changing private ObjectProperty graphic; to private StyleableObjectProperty graphic; and referencing 'graphic' instead of graphicProperty()... or adding a that does the instantiation of graphic private StyleableObjectProperty _graphicProperty() and having the public graphicProperty() delegate to _graphicProperty(); I'm not sure what the util method would do if the cast wasn't safe, or is it just a try-catch that throws an unchecked exception? On 3/20/14, 4:03 PM, Jonathan Giles wrote: > I'll leave it to David to comment on the specifics of these warnings, > but in general I'm very supportive of improving the quality of the > controls code. It would be best to file a new jira issue and start > putting patches up there (although for that to happen you'll need to > email the patch to me so that I may attach it on your behalf). > > Thanks! > > -- Jonathan > > On 21/03/2014 8:57 a.m., Tom Schindl wrote: >> Hi, >> >> I've just started looking into getting the controls package warning free >> and/or suppress them in case not fixable. >> >> Most of the generic warnings I've come accross in a first pass involve >> StyleableProperty cast like this: >> >> ((StyleableProperty)graphicProperty()).applyStyle(origin, null); >> >> In fact above code has 2 warnings: >> a) unchecked type cast >> b) usage of raw-type >> >> the raw type in this case can be fixed with: >> >> ((StyleableProperty)graphicProperty()).applyStyle(origin, null); >> >> leaving us with the unchecked cast so we could add: >> >> @SuppressWarnings({ "unchecked" }) >> >> e.g. on the method but I'm uncertain this is a good idea because it >> might hide unchecked warnings we have a possibility to fix. >> >> So what are other options: >> a) Create a static helper in Util to make the cast and for us (we could >> even add it as a static method in the StyleableProperty-interface) >> >> b) provide a private/package-scoped method the public one delegates >> >> Both of them work but have different problems where I think b) has the >> bigger ones like blowing up class-file, modification of the field to be >> of type StyleableObjectProperty. >> >> I'd really like to get the source warning free. >> >> Thoughts? >> >> Tom From David.Hill at Oracle.com Thu Mar 20 23:02:13 2014 From: David.Hill at Oracle.com (David Hill) Date: Thu, 20 Mar 2014 19:02:13 -0400 Subject: webrev for arm FB screen capture Message-ID: <532B7375.1090001@Oracle.com> fixing some issues I found with a 565 based display and Robot screen capture. Will tackle Monocle later now that I understand better the framebuffer capture issues. jira: https://javafx-jira.kenai.com/browse/RT-35910 review: http://cr.openjdk.java.net/~ddhill/RT-35910/ -- David Hill Java Embedded Development "Experience is that marvelous thing that enables you to recognize a mistake when you make it again." -- Franklin P. Jones From hang.vo at oracle.com Thu Mar 20 23:32:33 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 20 Mar 2014 23:32:33 +0000 Subject: hg: openjfx/8u-dev/rt: RT-24614: in equals method, if both values are strings, compare them with String equalsIgnoreCase Message-ID: <201403202332.s2KNWiUN024698@aojmv0008> Changeset: c8f3fda9ec22 Author: David Grieve Date: 2014-03-20 18:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c8f3fda9ec22 RT-24614: in equals method, if both values are strings, compare them with String equalsIgnoreCase ! modules/graphics/src/main/java/com/sun/javafx/css/ParsedValueImpl.java ! modules/graphics/src/test/java/com/sun/javafx/css/ParsedValueTest.java From hrjet9 at gmail.com Fri Mar 21 04:00:40 2014 From: hrjet9 at gmail.com (HRJet) Date: Fri, 21 Mar 2014 09:30:40 +0530 Subject: Node.impl_getMatchingStyles In-Reply-To: <532B09E3.2070309@oracle.com> References: <532B09E3.2070309@oracle.com> Message-ID: Thanks for the clarification. What about impl_getMatchingStyles ? That is not mentioned in RT-21096. Is it worth tracking as a separate request? On Thu, Mar 20, 2014 at 9:01 PM, David Grieve wrote: > The JIRA issue (now public) just says that these impl_ methods that > SceneBuilder uses need to be public API. Much work needs to be done in the > area of public API for accessing CSS styles and whatnot. But, unless I'm > told otherwise, there won't be any implementation of such an API before 9. > > FYI, the two impl_ methods mentioned in the bug are likely to be removed > altogether in 9. From hjohn at xs4all.nl Fri Mar 21 08:49:18 2014 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 21 Mar 2014 09:49:18 +0100 Subject: Proposal on getting warning free (controls) packages In-Reply-To: <532B4842.5010601@bestsolution.at> References: <532B4842.5010601@bestsolution.at> Message-ID: <532BFD0E.8070609@xs4all.nl> On 20/03/2014 20:57, Tom Schindl wrote: > Hi, > > I've just started looking into getting the controls package warning free > and/or suppress them in case not fixable. > > Most of the generic warnings I've come accross in a first pass involve > StyleableProperty cast like this: > > ((StyleableProperty)graphicProperty()).applyStyle(origin, null); > > In fact above code has 2 warnings: > a) unchecked type cast > b) usage of raw-type > > the raw type in this case can be fixed with: > > ((StyleableProperty)graphicProperty()).applyStyle(origin, null); > > leaving us with the unchecked cast so we could add: > > @SuppressWarnings({ "unchecked" }) > > e.g. on the method but I'm uncertain this is a good idea because it > might hide unchecked warnings we have a possibility to fix. If you are willing to expend another line of code, you could first assign graphicProperty to a variable: StylableProperty property = (StyleableProperty)graphicProperty(); property.applyStyle(origin, null); You can then apply the unchecked annotation to the assignment only, so future unchecked warnings in the same method will still be noticed. --John > So what are other options: > a) Create a static helper in Util to make the cast and for us (we could > even add it as a static method in the StyleableProperty-interface) > > b) provide a private/package-scoped method the public one delegates > > Both of them work but have different problems where I think b) has the > bigger ones like blowing up class-file, modification of the field to be > of type StyleableObjectProperty. > > I'd really like to get the source warning free. > > Thoughts? > > Tom > From hang.vo at oracle.com Fri Mar 21 10:17:36 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 10:17:36 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36235: Zero specular power can lead to rendering artifacts. Message-ID: <201403211017.s2LAHmvs004548@aojmv0008> Changeset: e07207914384 Author: vadim Date: 2014-03-21 14:11 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e07207914384 RT-36235: Zero specular power can lead to rendering artifacts. Reviewed-by: kcr, ckyang Summary: clamp specular power to 0.001 internally. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGPhongMaterial.java From leonid.popov at oracle.com Fri Mar 21 12:31:56 2014 From: leonid.popov at oracle.com (Leonid Popov) Date: Fri, 21 Mar 2014 16:31:56 +0400 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' Message-ID: <532C313C.3040708@oracle.com> Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'. -- -- Thanks, Leonid From kevin.rushforth at oracle.com Fri Mar 21 12:49:49 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 05:49:49 -0700 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' In-Reply-To: <532C313C.3040708@oracle.com> References: <532C313C.3040708@oracle.com> Message-ID: <532C356D.9020507@oracle.com> Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: > Hi, I updated my workspace recently, tried to build it and have got > the following exception. Any suggestions? > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':web:compileGeneratedWin'. > > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 > > * Exception is: > org.gradle.api.tasks.TaskExecutionException: Execution failed for > task ':web:compileGeneratedWin'. > From steve.x.northover at oracle.com Fri Mar 21 13:51:06 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Fri, 21 Mar 2014 06:51:06 -0700 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' In-Reply-To: <532C356D.9020507@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> Message-ID: <532C43CA.1070707@oracle.com> Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: > Are you using gradle 1.8? This looks like a bug we used to have with > prior versions of gradle. > > -- Kevin > > > Leonid Popov wrote: >> Hi, I updated my workspace recently, tried to build it and have got >> the following exception. Any suggestions? >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':web:compileGeneratedWin'. >> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >> >> * Exception is: >> org.gradle.api.tasks.TaskExecutionException: Execution failed for >> task ':web:compileGeneratedWin'. >> From anton.nashatyrev at oracle.com Fri Mar 21 13:54:08 2014 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Fri, 21 Mar 2014 17:54:08 +0400 Subject: [8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video Message-ID: <532C4480.9040007@oracle.com> Hello, could you please review the following fix: Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ Issue: https://javafx-jira.kenai.com/browse/RT-34950 Thank you! Anton. From anthony.petrov at oracle.com Fri Mar 21 14:12:51 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 21 Mar 2014 18:12:51 +0400 Subject: How to build 64-bit FX ? Message-ID: <532C48E3.80506@oracle.com> Hello, I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a 32-bit JDK, and when building FX by executing the `gradle` command, I get a 32-bit FX build. How do I get a 64-bit FX build on the same system? What additional software do I need? I suppose I need a 64-bit JDK, right? I have VS2010 Professional installed. Do I need to install any additional development tools/compilers? What options/environment variables do I specify on the command line to run gradle and get a 64-bit FX build? -- best regards, Anthony From leonid.popov at oracle.com Fri Mar 21 14:21:09 2014 From: leonid.popov at oracle.com (Leonid Popov) Date: Fri, 21 Mar 2014 18:21:09 +0400 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' In-Reply-To: <532C356D.9020507@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> Message-ID: <532C4AD5.1060007@oracle.com> Thanks Kevin, it helped. Leonid On 3/21/2014 4:49 PM, Kevin Rushforth wrote: > Are you using gradle 1.8? This looks like a bug we used to have with > prior versions of gradle. > > -- Kevin > > > Leonid Popov wrote: >> Hi, I updated my workspace recently, tried to build it and have got >> the following exception. Any suggestions? >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':web:compileGeneratedWin'. >> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >> >> * Exception is: >> org.gradle.api.tasks.TaskExecutionException: Execution failed for >> task ':web:compileGeneratedWin'. >> From kevin.rushforth at oracle.com Fri Mar 21 14:46:37 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 07:46:37 -0700 Subject: How to build 64-bit FX ? In-Reply-To: <532C48E3.80506@oracle.com> References: <532C48E3.80506@oracle.com> Message-ID: <532C50CD.6060703@oracle.com> If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX build. No additional options are needed. You need to do a "gradle clean" as part of your build if you previously built a 32-build in the same repo. Also, if not building webkit or media, make sure you update your stub_runtime to point to 64-bit FX binaries (your "caches" dir if doing a closed build). -- Kevin Anthony Petrov wrote: > Hello, > > I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a > 32-bit JDK, and when building FX by executing the `gradle` command, I > get a 32-bit FX build. > > How do I get a 64-bit FX build on the same system? What additional > software do I need? I suppose I need a 64-bit JDK, right? > > I have VS2010 Professional installed. Do I need to install any > additional development tools/compilers? > > What options/environment variables do I specify on the command line to > run gradle and get a 64-bit FX build? > > -- > best regards, > Anthony From kevin.rushforth at oracle.com Fri Mar 21 14:47:12 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 07:47:12 -0700 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' In-Reply-To: <532C43CA.1070707@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> <532C43CA.1070707@oracle.com> Message-ID: <532C50F0.30009@oracle.com> This was a gradle 1.4 bug that is fixed in 1.8: http://issues.gradle.org/browse/GRADLE-2831 Leonid just happened to be running an older gradle. -- Kevin Stephen F Northover wrote: > Was this gradle 1.8 or a problem with an EA version of JDK8? In any > case, update both. If you can't, doing a clean every time should work > but that's not the long term answer. > > Steve > > On 2014-03-21 5:49 AM, Kevin Rushforth wrote: >> Are you using gradle 1.8? This looks like a bug we used to have with >> prior versions of gradle. >> >> -- Kevin >> >> >> Leonid Popov wrote: >>> Hi, I updated my workspace recently, tried to build it and have got >>> the following exception. Any suggestions? >>> >>> FAILURE: Build failed with an exception. >>> >>> * What went wrong: >>> Execution failed for task ':web:compileGeneratedWin'. >>> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >>> >>> * Exception is: >>> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>> task ':web:compileGeneratedWin'. >>> > From hang.vo at oracle.com Fri Mar 21 15:03:00 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 15:03:00 +0000 Subject: hg: openjfx/8u-dev/rt: Fix for RT-36308 [IMX] Mouse sometimes jumps to edge of screen on first mouse move. Message-ID: <201403211503.s2LF3BpP019982@aojmv0008> Changeset: 74b46ab976e2 Author: Lisa.Selle at oracle.com Date: 2014-03-21 10:56 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/74b46ab976e2 Fix for RT-36308 [IMX] Mouse sometimes jumps to edge of screen on first mouse move. Reviewed by dblaukopf. Tested with HelloCursors. ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c From steve.x.northover at oracle.com Fri Mar 21 15:07:08 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Fri, 21 Mar 2014 08:07:08 -0700 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' In-Reply-To: <532C50F0.30009@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> <532C43CA.1070707@oracle.com> <532C50F0.30009@oracle.com> Message-ID: <532C559C.1050302@oracle.com> We fail on gradle 1.11. I have filed this bug: https://javafx-jira.kenai.com/browse/RT-36330 I suggest that if we can't fix the bug quickly, we print out a message that we require gradle 1.8 and exit. We should let people override this choice in the properties file. Steve On 2014-03-21 7:47 AM, Kevin Rushforth wrote: > This was a gradle 1.4 bug that is fixed in 1.8: > http://issues.gradle.org/browse/GRADLE-2831 > > Leonid just happened to be running an older gradle. > > -- Kevin > > > Stephen F Northover wrote: >> Was this gradle 1.8 or a problem with an EA version of JDK8? In any >> case, update both. If you can't, doing a clean every time should >> work but that's not the long term answer. >> >> Steve >> >> On 2014-03-21 5:49 AM, Kevin Rushforth wrote: >>> Are you using gradle 1.8? This looks like a bug we used to have with >>> prior versions of gradle. >>> >>> -- Kevin >>> >>> >>> Leonid Popov wrote: >>>> Hi, I updated my workspace recently, tried to build it and have got >>>> the following exception. Any suggestions? >>>> >>>> FAILURE: Build failed with an exception. >>>> >>>> * What went wrong: >>>> Execution failed for task ':web:compileGeneratedWin'. >>>> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >>>> >>>> * Exception is: >>>> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>>> task ':web:compileGeneratedWin'. >>>> >> From kirill.kirichenko at oracle.com Fri Mar 21 15:17:19 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Fri, 21 Mar 2014 19:17:19 +0400 Subject: [8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video In-Reply-To: <532C4480.9040007@oracle.com> References: <532C4480.9040007@oracle.com> Message-ID: <532C57FF.1030601@oracle.com> Looks good. Approved. On 21.03.2014 17:54, anton nashatyrev wrote: > Hello, > > could you please review the following fix: > > Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ > > Issue: https://javafx-jira.kenai.com/browse/RT-34950 > > Thank you! > Anton. From kevin.rushforth at oracle.com Fri Mar 21 15:34:55 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 08:34:55 -0700 Subject: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin' In-Reply-To: <532C559C.1050302@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> <532C43CA.1070707@oracle.com> <532C50F0.30009@oracle.com> <532C559C.1050302@oracle.com> Message-ID: <532C5C1F.2060601@oracle.com> > I suggest that if we can't fix the bug quickly, we print out a message > that we require gradle 1.8 and exit. We should let people override > this choice in the properties file. Good idea. We already print a warning if not gradle 1.8 so it would be easy to fail the build instead (perhaps we could also allow 1.9 since that is reported to work). -- Kevin Stephen F Northover wrote: > We fail on gradle 1.11. I have filed this bug: > https://javafx-jira.kenai.com/browse/RT-36330 > > I suggest that if we can't fix the bug quickly, we print out a message > that we require gradle 1.8 and exit. We should let people override > this choice in the properties file. > > Steve > > On 2014-03-21 7:47 AM, Kevin Rushforth wrote: >> This was a gradle 1.4 bug that is fixed in 1.8: >> http://issues.gradle.org/browse/GRADLE-2831 >> >> Leonid just happened to be running an older gradle. >> >> -- Kevin >> >> >> Stephen F Northover wrote: >>> Was this gradle 1.8 or a problem with an EA version of JDK8? In any >>> case, update both. If you can't, doing a clean every time should >>> work but that's not the long term answer. >>> >>> Steve >>> >>> On 2014-03-21 5:49 AM, Kevin Rushforth wrote: >>>> Are you using gradle 1.8? This looks like a bug we used to have >>>> with prior versions of gradle. >>>> >>>> -- Kevin >>>> >>>> >>>> Leonid Popov wrote: >>>>> Hi, I updated my workspace recently, tried to build it and have >>>>> got the following exception. Any suggestions? >>>>> >>>>> FAILURE: Build failed with an exception. >>>>> >>>>> * What went wrong: >>>>> Execution failed for task ':web:compileGeneratedWin'. >>>>> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >>>>> >>>>> * Exception is: >>>>> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>>>> task ':web:compileGeneratedWin'. >>>>> >>> > From kevin.rushforth at oracle.com Fri Mar 21 15:36:48 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 08:36:48 -0700 Subject: [8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video In-Reply-To: <532C57FF.1030601@oracle.com> References: <532C4480.9040007@oracle.com> <532C57FF.1030601@oracle.com> Message-ID: <532C5C90.7020306@oracle.com> Please add your "approved" comment to the JIRA. Thanks. -- Kevin Kirill Kirichenko wrote: > Looks good. > Approved. > > On 21.03.2014 17:54, anton nashatyrev wrote: >> Hello, >> >> could you please review the following fix: >> >> Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ >> >> Issue: https://javafx-jira.kenai.com/browse/RT-34950 >> >> Thank you! >> Anton. From anthony.petrov at oracle.com Fri Mar 21 16:26:10 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 21 Mar 2014 20:26:10 +0400 Subject: How to build 64-bit FX ? In-Reply-To: <532C50CD.6060703@oracle.com> References: <532C48E3.80506@oracle.com> <532C50CD.6060703@oracle.com> Message-ID: <532C6822.2050009@oracle.com> Thanks, Kevin. The build went fine. However, when starting an app, I get the infamous "NoSuchMethodError: notifyInitAccessibility" exception (I'm building a fresh 8u20 repo). I tried to specify -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that the x64 JDK I'm using to run the app has its jfxrt.jar removed. But(!), I can actually run the app using the (supposed to be) 64-bit FX binaries with a 32-bit JDK. And it runs fine in this case. But how this could possibly work? And most importantly, how do I get it work with a 64-bit JDK? -- best regards, Anthony On 3/21/2014 6:46 PM, Kevin Rushforth wrote: > If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX > build. No additional options are needed. You need to do a "gradle clean" > as part of your build if you previously built a 32-build in the same > repo. Also, if not building webkit or media, make sure you update your > stub_runtime to point to 64-bit FX binaries (your "caches" dir if doing > a closed build). > > -- Kevin > > > Anthony Petrov wrote: >> Hello, >> >> I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a >> 32-bit JDK, and when building FX by executing the `gradle` command, I >> get a 32-bit FX build. >> >> How do I get a 64-bit FX build on the same system? What additional >> software do I need? I suppose I need a 64-bit JDK, right? >> >> I have VS2010 Professional installed. Do I need to install any >> additional development tools/compilers? >> >> What options/environment variables do I specify on the command line to >> run gradle and get a 64-bit FX build? >> >> -- >> best regards, >> Anthony From David.Hill at Oracle.com Fri Mar 21 16:53:18 2014 From: David.Hill at Oracle.com (David Hill) Date: Fri, 21 Mar 2014 12:53:18 -0400 Subject: Glass Robot and getSCreenCapture Message-ID: <532C6E7E.4000401@Oracle.com> I have been working on a problem with Robot.getScreenCapture() on a 565 ARM device, and while doing so, encountered a couple of questions which I will bring up: Pixxls getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) I don't seem any real documentation that says how x,y + width,height should be treated when compared to the reality of the Screen. What values of x,y + width,height are reasonable ? I can picture any number of scenarios with them that would result in a box that does not fit within the Screen dimensions. The only implementing code I have seen checks to that the width & height are >= 1. Can I/Should I handle -x values ? What if the requested bounds exceed the screen ? If we are making assumptions that the requested box is inside the screen.... then why don't we document that fact and add a check in the Robot class (instead of relying on the native impls). If we are assuming the requested box does not have to lie within the screen bounds - what should the returned values be for the pixels outside the screen ? Pixel Black ? (Currently I think Lens would return 0x instead of 0xff000000) My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. This code is "internal" API, so I expect the real impact would be on SQE. -- David Hill Java Embedded Development Socialism is great until you run out of other peoples money -- Margaret Thatcher From anthony.petrov at oracle.com Fri Mar 21 17:05:04 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 21 Mar 2014 21:05:04 +0400 Subject: Glass Robot and getSCreenCapture In-Reply-To: <532C6E7E.4000401@Oracle.com> References: <532C6E7E.4000401@Oracle.com> Message-ID: <532C7140.7080702@oracle.com> Hi David, I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing. In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen). So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff000000 - both look good. However, I agree that a stricter specification and a check might be the best solution. -- best regards, Anthony On 3/21/2014 8:53 PM, David Hill wrote: > > I have been working on a problem with Robot.getScreenCapture() on a 565 > ARM device, and while doing so, encountered a couple of questions which > I will bring up: > > Pixxls getScreenCapture(int x, int y, int width, int height, boolean > isHiDPI) > > I don't seem any real documentation that says how x,y + width,height > should be treated when compared to the reality of the Screen. > What values of x,y + width,height are reasonable ? I can picture any > number of scenarios with them that would result in a box that does not > fit within the Screen dimensions. The only implementing code I have seen > checks to that the width & height are >= 1. Can I/Should I handle -x > values ? What if the requested bounds exceed the screen ? > > If we are making assumptions that the requested box is inside the > screen.... then why don't we document that fact and add a check in the > Robot class (instead of relying on the native impls). > > If we are assuming the requested box does not have to lie within the > screen bounds - what should the returned values be for the pixels > outside the screen ? Pixel Black ? (Currently I think Lens would return > 0x instead of 0xff000000) > > My recommendation would be modify the JavaDoc contract to specify that > the x,y and x+width, y+height must be within the screen bounds, with an > IllegalArgumentException if out of bounds. This would be checked in > Robot, prior to calling the native impls. > > This code is "internal" API, so I expect the real impact would be on SQE. > From hang.vo at oracle.com Fri Mar 21 17:17:49 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 17:17:49 +0000 Subject: hg: openjfx/8u-dev/rt: RT-32459: CMD-BACKSPACE should delete the line to the left of the caret, not the word (Mac) Message-ID: <201403211718.s2LHI0DD009906@aojmv0008> Changeset: 37b60b405b4b Author: leifs Date: 2014-03-21 10:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/37b60b405b4b RT-32459: CMD-BACKSPACE should delete the line to the left of the caret, not the word (Mac) ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java From hang.vo at oracle.com Fri Mar 21 18:17:37 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 18:17:37 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36314: JavaFX API javadoc has wrong link to JDK docs Message-ID: <201403211817.s2LIHnIt018970@aojmv0008> Changeset: 8a9062f8c637 Author: kcr Date: 2014-03-21 11:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a9062f8c637 RT-36314: JavaFX API javadoc has wrong link to JDK docs ! build.gradle From kevin.rushforth at oracle.com Fri Mar 21 18:31:00 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 11:31:00 -0700 Subject: [8u20] post-commit review: RT-36314: JavaFX API javadoc has wrong link to JDK docs Message-ID: <532C8564.70605@oracle.com> I just pushed the fix for the following bug: JIRA: https://javafx-jira.kenai.com/browse/RT-36314 Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a9062f8c637 This will allow links to JDK classes to be generated in our API docs. -- Kevin From hang.vo at oracle.com Fri Mar 21 19:47:49 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 19:47:49 +0000 Subject: hg: openjfx/8u-dev/rt: [Accessibility] fix comment format Message-ID: <201403211948.s2LJm07r002121@aojmv0008> Changeset: 8c568afe762a Author: Felipe Heidrich Date: 2014-03-21 12:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8c568afe762a [Accessibility] fix comment format ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java From tom.schindl at bestsolution.at Fri Mar 21 19:53:49 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 21 Mar 2014 12:53:49 -0700 Subject: *PropertyBase vs Simple*Property In-Reply-To: <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> Message-ID: <532C98CD.4050300@bestsolution.at> Hi Richard, Coming back to this old thread and now that we are using lamdas all over I guess we could take one more look into that. I've prototyped an initial version by introducing a new internal type named InvalidatedSimpleObjectProperty (not the best name ever!) - see code pasted below. And now one can write code like this: > public final ObjectProperty viewportProperty() { > if (viewport == null) { > viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { > invalidateWidthHeight(); > impl_markDirty(DirtyBits.NODE_VIEWPORT); > impl_geomChanged(); > } ); > } > return viewport; > } instead of > public final ObjectProperty viewportProperty() { > if (viewport == null) { > viewport = new ObjectPropertyBase() { > > @Override > protected void invalidated() { > invalidateWidthHeight(); > impl_markDirty(DirtyBits.NODE_VIEWPORT); > impl_geomChanged(); > } > > @Override > public Object getBean() { > return ImageView.this; > } > > @Override > public String getName() { > return "viewport"; > } > }; > } > return viewport; > } Which allows us to get rid of most of the ObjectPropertyBase sublcasses. Tom > package com.sun.javafx.property; > > import java.util.function.Consumer; > > import javafx.beans.property.SimpleObjectProperty; > > public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { > private final Consumer> invalidationConsumer; > > /** > * The constructor of {@code ObjectProperty} > * > * @param initialValue > * the initial value of the wrapped value > * @param invalidationConsumer > * the consumer to be called when the bean is invalidated > */ > public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { > super(initialValue); > if( invalidationConsumer == null ) { > throw new IllegalArgumentException("Consumer can not be null"); > } > this.invalidationConsumer = invalidationConsumer; > } > > /** > * The constructor of {@code ObjectProperty} > * > * @param bean > * the bean of this {@code ObjectProperty} > * @param name > * the name of this {@code ObjectProperty} > * @param invalidationConsumer > * the consumer to be called when the bean is invalidated > */ > public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { > super(bean, name); > if( invalidationConsumer == null ) { > throw new IllegalArgumentException("Consumer can not be null"); > } > this.invalidationConsumer = invalidationConsumer; > } > > /** > * The constructor of {@code ObjectProperty} > * > * @param bean > * the bean of this {@code ObjectProperty} > * @param name > * the name of this {@code ObjectProperty} > * @param initialValue > * the initial value of the wrapped value > * @param invalidationConsumer > * the consumer to be called when the bean is invalidated > */ > public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { > super(bean,name,initialValue); > if( invalidationConsumer == null ) { > throw new IllegalArgumentException("Consumer can not be null"); > } > this.invalidationConsumer = invalidationConsumer; > } > > @Override > protected void invalidated() { > invalidationConsumer.accept(this); > } > } On 22.01.13 10:30, Richard Bair wrote: >> Is the Java8 plan still there if not should the current Simple*Property >> subclasses who overload invalidated be changed to PropertyBase? > > It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. > From richard.bair at oracle.com Fri Mar 21 20:11:37 2014 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 21 Mar 2014 13:11:37 -0700 Subject: *PropertyBase vs Simple*Property In-Reply-To: <532C98CD.4050300@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> Message-ID: Cool. What we then need to measure is the impact to dynamic footprint (i.e.: heap usage). Do the extra 3 fields per property object (bean, name, invalidated method) have any significant impact? Or are these property instances created so infrequently that it doesn?t make any real difference? Richard On Mar 21, 2014, at 12:53 PM, Tom Schindl wrote: > Hi Richard, > > Coming back to this old thread and now that we are using lamdas all over > I guess we could take one more look into that. > > I've prototyped an initial version by introducing a new internal type > named InvalidatedSimpleObjectProperty (not the best name ever!) - see > code pasted below. > > And now one can write code like this: > >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } ); >> } >> return viewport; >> } > > instead of > >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new ObjectPropertyBase() { >> >> @Override >> protected void invalidated() { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } >> >> @Override >> public Object getBean() { >> return ImageView.this; >> } >> >> @Override >> public String getName() { >> return "viewport"; >> } >> }; >> } >> return viewport; >> } > > Which allows us to get rid of most of the ObjectPropertyBase sublcasses. > > Tom > > >> package com.sun.javafx.property; >> >> import java.util.function.Consumer; >> >> import javafx.beans.property.SimpleObjectProperty; >> >> public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { >> private final Consumer> invalidationConsumer; >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param initialValue >> * the initial value of the wrapped value >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { >> super(initialValue); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param bean >> * the bean of this {@code ObjectProperty} >> * @param name >> * the name of this {@code ObjectProperty} >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { >> super(bean, name); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param bean >> * the bean of this {@code ObjectProperty} >> * @param name >> * the name of this {@code ObjectProperty} >> * @param initialValue >> * the initial value of the wrapped value >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { >> super(bean,name,initialValue); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> @Override >> protected void invalidated() { >> invalidationConsumer.accept(this); >> } >> } > > > On 22.01.13 10:30, Richard Bair wrote: >>> Is the Java8 plan still there if not should the current Simple*Property >>> subclasses who overload invalidated be changed to PropertyBase? >> >> It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. >> > From steve.x.northover at oracle.com Fri Mar 21 22:16:54 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Fri, 21 Mar 2014 15:16:54 -0700 Subject: *PropertyBase vs Simple*Property In-Reply-To: <532C98CD.4050300@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> Message-ID: <532CBA56.9060004@oracle.com> This looks good. I wonder if we should make this (massive) change before we lambda graphics and controls? Probably doesn't matter. We'll need a JIRA and someone assigned to it in order to track the work. Steve On 2014-03-21 12:53 PM, Tom Schindl wrote: > Hi Richard, > > Coming back to this old thread and now that we are using lamdas all over > I guess we could take one more look into that. > > I've prototyped an initial version by introducing a new internal type > named InvalidatedSimpleObjectProperty (not the best name ever!) - see > code pasted below. > > And now one can write code like this: > >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } ); >> } >> return viewport; >> } > instead of > >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new ObjectPropertyBase() { >> >> @Override >> protected void invalidated() { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } >> >> @Override >> public Object getBean() { >> return ImageView.this; >> } >> >> @Override >> public String getName() { >> return "viewport"; >> } >> }; >> } >> return viewport; >> } > Which allows us to get rid of most of the ObjectPropertyBase sublcasses. > > Tom > > >> package com.sun.javafx.property; >> >> import java.util.function.Consumer; >> >> import javafx.beans.property.SimpleObjectProperty; >> >> public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { >> private final Consumer> invalidationConsumer; >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param initialValue >> * the initial value of the wrapped value >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { >> super(initialValue); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param bean >> * the bean of this {@code ObjectProperty} >> * @param name >> * the name of this {@code ObjectProperty} >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { >> super(bean, name); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param bean >> * the bean of this {@code ObjectProperty} >> * @param name >> * the name of this {@code ObjectProperty} >> * @param initialValue >> * the initial value of the wrapped value >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { >> super(bean,name,initialValue); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> @Override >> protected void invalidated() { >> invalidationConsumer.accept(this); >> } >> } > > On 22.01.13 10:30, Richard Bair wrote: >>> Is the Java8 plan still there if not should the current Simple*Property >>> subclasses who overload invalidated be changed to PropertyBase? >> It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. >> From kevin.rushforth at oracle.com Fri Mar 21 22:26:10 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 15:26:10 -0700 Subject: *PropertyBase vs Simple*Property In-Reply-To: <532CBA56.9060004@oracle.com> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <532CBA56.9060004@oracle.com> Message-ID: <532CBC82.8060104@oracle.com> It does seem promising. We'll also need data to show the trade-offs to help inform whether it is worth making such a massive change. -- Kevin Stephen F Northover wrote: > This looks good. I wonder if we should make this (massive) change > before we lambda graphics and controls? Probably doesn't matter. > We'll need a JIRA and someone assigned to it in order to track the work. > > Steve > > On 2014-03-21 12:53 PM, Tom Schindl wrote: >> Hi Richard, >> >> Coming back to this old thread and now that we are using lamdas all over >> I guess we could take one more look into that. >> >> I've prototyped an initial version by introducing a new internal type >> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >> code pasted below. >> >> And now one can write code like this: >> >>> public final ObjectProperty viewportProperty() { >>> if (viewport == null) { >>> viewport = new InvalidatedSimpleObjectProperty<>(this, >>> "viewport", (o) -> { >>> invalidateWidthHeight(); >>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>> impl_geomChanged(); >>> } ); >>> } >>> return viewport; >>> } >> instead of >> >>> public final ObjectProperty viewportProperty() { >>> if (viewport == null) { >>> viewport = new ObjectPropertyBase() { >>> >>> @Override >>> protected void invalidated() { >>> invalidateWidthHeight(); >>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>> impl_geomChanged(); >>> } >>> >>> @Override >>> public Object getBean() { >>> return ImageView.this; >>> } >>> >>> @Override >>> public String getName() { >>> return "viewport"; >>> } >>> }; >>> } >>> return viewport; >>> } >> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >> >> Tom >> >> >>> package com.sun.javafx.property; >>> >>> import java.util.function.Consumer; >>> >>> import javafx.beans.property.SimpleObjectProperty; >>> >>> public final class InvalidatedSimpleObjectProperty extends >>> SimpleObjectProperty { >>> private final Consumer> >>> invalidationConsumer; >>> >>> /** >>> * The constructor of {@code ObjectProperty} >>> * >>> * @param initialValue >>> * the initial value of the wrapped value >>> * @param invalidationConsumer >>> * the consumer to be called when the bean is >>> invalidated >>> */ >>> public InvalidatedSimpleObjectProperty(T initialValue, final >>> Consumer> invalidationConsumer) { >>> super(initialValue); >>> if( invalidationConsumer == null ) { >>> throw new IllegalArgumentException("Consumer can not be >>> null"); >>> } >>> this.invalidationConsumer = invalidationConsumer; >>> } >>> >>> /** >>> * The constructor of {@code ObjectProperty} >>> * >>> * @param bean >>> * the bean of this {@code ObjectProperty} >>> * @param name >>> * the name of this {@code ObjectProperty} >>> * @param invalidationConsumer >>> * the consumer to be called when the bean is >>> invalidated >>> */ >>> public InvalidatedSimpleObjectProperty(Object bean, String >>> name, final Consumer> >>> invalidationConsumer) { >>> super(bean, name); >>> if( invalidationConsumer == null ) { >>> throw new IllegalArgumentException("Consumer can not be >>> null"); >>> } >>> this.invalidationConsumer = invalidationConsumer; >>> } >>> >>> /** >>> * The constructor of {@code ObjectProperty} >>> * >>> * @param bean >>> * the bean of this {@code ObjectProperty} >>> * @param name >>> * the name of this {@code ObjectProperty} >>> * @param initialValue >>> * the initial value of the wrapped value >>> * @param invalidationConsumer >>> * the consumer to be called when the bean is >>> invalidated >>> */ >>> public InvalidatedSimpleObjectProperty(Object bean, String >>> name, T initialValue, final >>> Consumer> invalidationConsumer) { >>> super(bean,name,initialValue); >>> if( invalidationConsumer == null ) { >>> throw new IllegalArgumentException("Consumer can not be >>> null"); >>> } >>> this.invalidationConsumer = invalidationConsumer; >>> } >>> @Override >>> protected void invalidated() { >>> invalidationConsumer.accept(this); >>> } >>> } >> >> On 22.01.13 10:30, Richard Bair wrote: >>>> Is the Java8 plan still there if not should the current >>>> Simple*Property >>>> subclasses who overload invalidated be changed to PropertyBase? >>> It is unlikely that we'll be able to do anything major here in Java >>> 8 just because we don't really have Lambda yet that we can play >>> with, and changing over every property is a big job. Unless we knew >>> it would be a major win. I would say, if you encounter a Simple* >>> property that has been subclassed, then we should fix it up as we go >>> to be a PropertyBase* guy instead. >>> > From hang.vo at oracle.com Fri Mar 21 22:47:45 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 22:47:45 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36264: SceneBuilder doesn't start since FX 8 u20 b04 [work around for In(Sanity) Testing] Message-ID: <201403212247.s2LMlvwl029469@aojmv0008> Changeset: 1e3c73548b16 Author: snorthov Date: 2014-03-21 15:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1e3c73548b16 RT-36264: SceneBuilder doesn't start since FX 8 u20 b04 [work around for In(Sanity) Testing] ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/AutoSuggestEditor.java From kevin.rushforth at oracle.com Fri Mar 21 23:15:53 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Mar 2014 16:15:53 -0700 Subject: Gradle 1.11 (and < 1.8) will now fail fast with a clear error [was: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'] In-Reply-To: <532C559C.1050302@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> <532C43CA.1070707@oracle.com> <532C50F0.30009@oracle.com> <532C559C.1050302@oracle.com> Message-ID: <532CC829.5010701@oracle.com> I just pushed a fix for https://javafx-jira.kenai.com/browse/RT-36330 Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf There is a bug in gradle 1.11 (already fixed in 1.12-rc1) which would be intrusive to workaround, so 1.11 is now blacklisted. The logic is this: if (gradleVersion != "1.8") { if (gradleVersion < "1.8") fail else if (gradleVersion == "1.11") fail else warn } You can turn the failures into warnings with "gradle -PGRADLE_VERSION_CHECK=false" -- Kevin Stephen F Northover wrote: > We fail on gradle 1.11. I have filed this bug: > https://javafx-jira.kenai.com/browse/RT-36330 > > I suggest that if we can't fix the bug quickly, we print out a message > that we require gradle 1.8 and exit. We should let people override > this choice in the properties file. > > Steve > > On 2014-03-21 7:47 AM, Kevin Rushforth wrote: >> This was a gradle 1.4 bug that is fixed in 1.8: >> http://issues.gradle.org/browse/GRADLE-2831 >> >> Leonid just happened to be running an older gradle. >> >> -- Kevin >> >> >> Stephen F Northover wrote: >>> Was this gradle 1.8 or a problem with an EA version of JDK8? In any >>> case, update both. If you can't, doing a clean every time should >>> work but that's not the long term answer. >>> >>> Steve >>> >>> On 2014-03-21 5:49 AM, Kevin Rushforth wrote: >>>> Are you using gradle 1.8? This looks like a bug we used to have >>>> with prior versions of gradle. >>>> >>>> -- Kevin >>>> >>>> >>>> Leonid Popov wrote: >>>>> Hi, I updated my workspace recently, tried to build it and have >>>>> got the following exception. Any suggestions? >>>>> >>>>> FAILURE: Build failed with an exception. >>>>> >>>>> * What went wrong: >>>>> Execution failed for task ':web:compileGeneratedWin'. >>>>> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >>>>> >>>>> * Exception is: >>>>> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>>>> task ':web:compileGeneratedWin'. >>>>> >>> > From hang.vo at oracle.com Fri Mar 21 23:17:34 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 21 Mar 2014 23:17:34 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36330: Gradle 1.11 fails to build JFX Message-ID: <201403212317.s2LNHkOS004835@aojmv0008> Changeset: 27390e79b4cf Author: kcr Date: 2014-03-21 16:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf RT-36330: Gradle 1.11 fails to build JFX ! build.gradle ! gradle.properties.template From steve.x.northover at oracle.com Fri Mar 21 23:18:41 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Fri, 21 Mar 2014 16:18:41 -0700 Subject: Gradle 1.11 (and < 1.8) will now fail fast with a clear error [was: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'] In-Reply-To: <532CC829.5010701@oracle.com> References: <532C313C.3040708@oracle.com> <532C356D.9020507@oracle.com> <532C43CA.1070707@oracle.com> <532C50F0.30009@oracle.com> <532C559C.1050302@oracle.com> <532CC829.5010701@oracle.com> Message-ID: <532CC8D1.8010900@oracle.com> Great! There were people getting burned by this at EclipseCon. Luckily, I remembered this bug and was able to help them but now we don't have to. Steve On 2014-03-21 4:15 PM, Kevin Rushforth wrote: > I just pushed a fix for https://javafx-jira.kenai.com/browse/RT-36330 > > Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf > > There is a bug in gradle 1.11 (already fixed in 1.12-rc1) which would > be intrusive to workaround, so 1.11 is now blacklisted. > > The logic is this: > > if (gradleVersion != "1.8") { > if (gradleVersion < "1.8") fail > else if (gradleVersion == "1.11") fail > else warn > } > > You can turn the failures into warnings with "gradle > -PGRADLE_VERSION_CHECK=false" > > -- Kevin > > > Stephen F Northover wrote: >> We fail on gradle 1.11. I have filed this bug: >> https://javafx-jira.kenai.com/browse/RT-36330 >> >> I suggest that if we can't fix the bug quickly, we print out a >> message that we require gradle 1.8 and exit. We should let people >> override this choice in the properties file. >> >> Steve >> >> On 2014-03-21 7:47 AM, Kevin Rushforth wrote: >>> This was a gradle 1.4 bug that is fixed in 1.8: >>> http://issues.gradle.org/browse/GRADLE-2831 >>> >>> Leonid just happened to be running an older gradle. >>> >>> -- Kevin >>> >>> >>> Stephen F Northover wrote: >>>> Was this gradle 1.8 or a problem with an EA version of JDK8? In >>>> any case, update both. If you can't, doing a clean every time >>>> should work but that's not the long term answer. >>>> >>>> Steve >>>> >>>> On 2014-03-21 5:49 AM, Kevin Rushforth wrote: >>>>> Are you using gradle 1.8? This looks like a bug we used to have >>>>> with prior versions of gradle. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Leonid Popov wrote: >>>>>> Hi, I updated my workspace recently, tried to build it and have >>>>>> got the following exception. Any suggestions? >>>>>> >>>>>> FAILURE: Build failed with an exception. >>>>>> >>>>>> * What went wrong: >>>>>> Execution failed for task ':web:compileGeneratedWin'. >>>>>> > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 >>>>>> >>>>>> * Exception is: >>>>>> org.gradle.api.tasks.TaskExecutionException: Execution failed >>>>>> for task ':web:compileGeneratedWin'. >>>>>> >>>> >> From hang.vo at oracle.com Sat Mar 22 00:32:33 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 22 Mar 2014 00:32:33 +0000 Subject: hg: openjfx/8u-dev/rt: Follow-on for RT-36330 to print the supported gradle version on failure Message-ID: <201403220032.s2M0WiAI016669@aojmv0008> Changeset: 6c7047fd93f0 Author: kcr Date: 2014-03-21 17:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6c7047fd93f0 Follow-on for RT-36330 to print the supported gradle version on failure ! build.gradle From mario at datenwort.at Sat Mar 22 05:57:14 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Sat, 22 Mar 2014 05:57:14 +0000 Subject: Ability to decorate ChangeListener Message-ID: Hi! In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) { a listener decoration can be smart enough to not only check against itself, but also against its delegate. What do you think? I could prepare a patch for the *ExpressionHelper classes. Best regards, Mario From tomas.mikula at gmail.com Sat Mar 22 13:07:27 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 14:07:27 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: References: Message-ID: The suspicious thing about your solution is that your smart implementation of equals() is not symmetric. In case the observable value is visible only within your project, you could do this: interface Subscription { void unsubscribe(); } class MyObservableValue implements ObservableValue { public Subscription subscribe(ChangeListener listener) { ChangeListener decorated = decorate(listener); addListener(decorated); return () -> removeListener(decorated); } } and use subscribe()/unsubscribe() instead of addListener()/removeListener(): Subscription sub = observableValue.subscribe(listener); // ... sub.unsubscribe(); Of course this is not possible if you need to pass the observable value to the outside world as ObservableValue. Regards, Tomas On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: > Hi! > > In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. > Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. > > We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) { > > a listener decoration can be smart enough to not only check against itself, but also against its delegate. > > What do you think? > > I could prepare a patch for the *ExpressionHelper classes. > > > Best regards, > Mario > > From si.siput.ngantuk at gmail.com Sun Mar 23 13:22:06 2014 From: si.siput.ngantuk at gmail.com (siput) Date: Sun, 23 Mar 2014 20:22:06 +0700 Subject: Error in tablevie ghost error Message-ID: <532EDFFE.3050306@gmail.com> Why when i clik in the area outside row contain a data and outside column area I get an error? red area of eror From tomas.mikula at gmail.com Sat Mar 22 13:22:46 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 14:22:46 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: References: Message-ID: A simpler and more universal solution is to also override removeListener: public void removeListener(ChangeListener listener) { super.removeListener(decorated(listener)); } And the equals() method on decorated listeners only compares the delegates (thus is symmetric). Regards, Tomas On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: > The suspicious thing about your solution is that your smart > implementation of equals() is not symmetric. > > In case the observable value is visible only within your project, you > could do this: > > interface Subscription { > void unsubscribe(); > } > > class MyObservableValue implements ObservableValue { > public Subscription subscribe(ChangeListener listener) { > ChangeListener decorated = decorate(listener); > addListener(decorated); > return () -> removeListener(decorated); > } > } > > and use subscribe()/unsubscribe() instead of addListener()/removeListener(): > > Subscription sub = observableValue.subscribe(listener); > // ... > sub.unsubscribe(); > > Of course this is not possible if you need to pass the observable > value to the outside world as ObservableValue. > > Regards, > Tomas > > On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >> Hi! >> >> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >> >> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >> >> if (listener.equals(changeListeners[index])) { >> >> If we flip this to >> >> if (changeListeners[index].equals(listener)) { >> >> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >> >> What do you think? >> >> I could prepare a patch for the *ExpressionHelper classes. >> >> >> Best regards, >> Mario >> >> From mjrb5 at kent.ac.uk Sat Mar 22 13:29:02 2014 From: mjrb5 at kent.ac.uk (Michael Berry) Date: Sat, 22 Mar 2014 13:29:02 +0000 Subject: LNK1123: failure during conversion to COFF when building under windows Message-ID: Hi, I'm currently trying to build OpenJFX from source on Windows - I've followed the instructions on the build page and have Visual Studio 2010, the June 2010 directx sdk, cygwin and its relevant modules installed. However, when building it fails at the buildJavaFXPackage task (output below.) I'm not sure if those warnings are normal or not, but they definitely look suspicious. It seems the actual error that's stopping things is the "fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt" line, though all I've found searching around for that error is that "incremental:off" should be set to avoid it, which it already is in the gradle task. Any ideas? Thanks, Michael :fxml:jar :fxml:assemble :fxpackager:buildJavaFXPackager javafxpackager.cpp C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258) : warning C4018: '<' : signed/unsigned mismatch C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269) : warning C4018: '<' : signed/unsigned mismatch C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286) : warning C4018: '<' : signed/unsigned mismatch C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426) : warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation,use _CRT_SECURE_NO_WARNINGS. See online help for details. C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt :fxpackager:buildJavaFXPackager FAILED FAILURE: Build failed with an exception. * Where: Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817 * What went wrong: Execution failed for task ':fxpackager:buildJavaFXPackager'. > Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123 From tomas.mikula at gmail.com Sat Mar 22 13:54:41 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 14:54:41 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: <532C98CD.4050300@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> Message-ID: On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl wrote: > Hi Richard, > > Coming back to this old thread and now that we are using lamdas all over > I guess we could take one more look into that. > > I've prototyped an initial version by introducing a new internal type > named InvalidatedSimpleObjectProperty (not the best name ever!) - see > code pasted below. > > And now one can write code like this: > >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } ); >> } >> return viewport; >> } > > instead of > >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new ObjectPropertyBase() { >> >> @Override >> protected void invalidated() { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } >> >> @Override >> public Object getBean() { >> return ImageView.this; >> } >> >> @Override >> public String getName() { >> return "viewport"; >> } >> }; >> } >> return viewport; >> } Nice idea. Just to get the comparison to status quo more fair, you don't need to override getBean() and getName() methods: public final ObjectProperty viewportProperty() { if (viewport == null) { viewport = new SimpleObjectProperty(this, "viewport") { @Override protected void invalidated() { invalidateWidthHeight(); impl_markDirty(DirtyBits.NODE_VIEWPORT); impl_geomChanged(); } }; } return viewport; } Regards, Tomas > > Which allows us to get rid of most of the ObjectPropertyBase sublcasses. > > Tom > > >> package com.sun.javafx.property; >> >> import java.util.function.Consumer; >> >> import javafx.beans.property.SimpleObjectProperty; >> >> public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { >> private final Consumer> invalidationConsumer; >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param initialValue >> * the initial value of the wrapped value >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { >> super(initialValue); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param bean >> * the bean of this {@code ObjectProperty} >> * @param name >> * the name of this {@code ObjectProperty} >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { >> super(bean, name); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> /** >> * The constructor of {@code ObjectProperty} >> * >> * @param bean >> * the bean of this {@code ObjectProperty} >> * @param name >> * the name of this {@code ObjectProperty} >> * @param initialValue >> * the initial value of the wrapped value >> * @param invalidationConsumer >> * the consumer to be called when the bean is invalidated >> */ >> public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { >> super(bean,name,initialValue); >> if( invalidationConsumer == null ) { >> throw new IllegalArgumentException("Consumer can not be null"); >> } >> this.invalidationConsumer = invalidationConsumer; >> } >> >> @Override >> protected void invalidated() { >> invalidationConsumer.accept(this); >> } >> } > > > On 22.01.13 10:30, Richard Bair wrote: >>> Is the Java8 plan still there if not should the current Simple*Property >>> subclasses who overload invalidated be changed to PropertyBase? >> >> It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. >> > From mario at datenwort.at Sat Mar 22 14:25:05 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Sat, 22 Mar 2014 14:25:05 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: References: Message-ID: Hi Thomas! Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. They should act like a transparent proxy. Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? @Override public boolean equals(Object obj) { return obj == delegate; // && this == obj } @Override public int hashCode() { return delegate.hashCode(); } Regards, Mario Am 22.03.2014 um 14:22 schrieb Tomas Mikula : > A simpler and more universal solution is to also override removeListener: > > public void removeListener(ChangeListener listener) { > super.removeListener(decorated(listener)); > } > > And the equals() method on decorated listeners only compares the > delegates (thus is symmetric). > > Regards, > Tomas > > > On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >> The suspicious thing about your solution is that your smart >> implementation of equals() is not symmetric. >> >> In case the observable value is visible only within your project, you >> could do this: >> >> interface Subscription { >> void unsubscribe(); >> } >> >> class MyObservableValue implements ObservableValue { >> public Subscription subscribe(ChangeListener listener) { >> ChangeListener decorated = decorate(listener); >> addListener(decorated); >> return () -> removeListener(decorated); >> } >> } >> >> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >> >> Subscription sub = observableValue.subscribe(listener); >> // ... >> sub.unsubscribe(); >> >> Of course this is not possible if you need to pass the observable >> value to the outside world as ObservableValue. >> >> Regards, >> Tomas >> >> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >>> Hi! >>> >>> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >>> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >>> >>> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >>> >>> if (listener.equals(changeListeners[index])) { >>> >>> If we flip this to >>> >>> if (changeListeners[index].equals(listener)) { >>> >>> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >>> >>> What do you think? >>> >>> I could prepare a patch for the *ExpressionHelper classes. >>> >>> >>> Best regards, >>> Mario >>> >>> From kevin.rushforth at oracle.com Sat Mar 22 14:42:43 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Mar 2014 07:42:43 -0700 Subject: Ability to decorate ChangeListener In-Reply-To: References: Message-ID: <532DA163.7040608@oracle.com> If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. -- Kevin Mario Ivankovits wrote: > Hi Thomas! > > Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. > Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. > > Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. > They should act like a transparent proxy. > > Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. > It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? > > @Override > public boolean equals(Object obj) > { > return obj == delegate; // && this == obj > } > > @Override > public int hashCode() > { > return delegate.hashCode(); > } > > > Regards, > Mario > > > Am 22.03.2014 um 14:22 schrieb Tomas Mikula : > > >> A simpler and more universal solution is to also override removeListener: >> >> public void removeListener(ChangeListener listener) { >> super.removeListener(decorated(listener)); >> } >> >> And the equals() method on decorated listeners only compares the >> delegates (thus is symmetric). >> >> Regards, >> Tomas >> >> >> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >> >>> The suspicious thing about your solution is that your smart >>> implementation of equals() is not symmetric. >>> >>> In case the observable value is visible only within your project, you >>> could do this: >>> >>> interface Subscription { >>> void unsubscribe(); >>> } >>> >>> class MyObservableValue implements ObservableValue { >>> public Subscription subscribe(ChangeListener listener) { >>> ChangeListener decorated = decorate(listener); >>> addListener(decorated); >>> return () -> removeListener(decorated); >>> } >>> } >>> >>> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >>> >>> Subscription sub = observableValue.subscribe(listener); >>> // ... >>> sub.unsubscribe(); >>> >>> Of course this is not possible if you need to pass the observable >>> value to the outside world as ObservableValue. >>> >>> Regards, >>> Tomas >>> >>> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >>> >>>> Hi! >>>> >>>> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >>>> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >>>> >>>> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >>>> >>>> if (listener.equals(changeListeners[index])) { >>>> >>>> If we flip this to >>>> >>>> if (changeListeners[index].equals(listener)) { >>>> >>>> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >>>> >>>> What do you think? >>>> >>>> I could prepare a patch for the *ExpressionHelper classes. >>>> >>>> >>>> Best regards, >>>> Mario >>>> >>>> >>>> > > From kevin.rushforth at oracle.com Sat Mar 22 14:46:27 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Mar 2014 07:46:27 -0700 Subject: LNK1123: failure during conversion to COFF when building under windows In-Reply-To: References: Message-ID: <532DA243.5000601@oracle.com> Do you have VS 2010 Service Pack 1? I've seen this failure on machines that don't have SP1 installed. -- Kevin Michael Berry wrote: > Hi, > > I'm currently trying to build OpenJFX from source on Windows - I've > followed the instructions on the build page and have Visual Studio 2010, > the June 2010 directx sdk, cygwin and its relevant modules installed. > However, when building it fails at the buildJavaFXPackage task (output > below.) > > I'm not sure if those warnings are normal or not, but they definitely look > suspicious. It seems the actual error that's stopping things is the "fatal > error LNK1123: failure during conversion to COFF: file invalid or corrupt" > line, though all I've found searching around for that error is that > "incremental:off" should be set to avoid it, which it already is in the > gradle task. > > Any ideas? > > Thanks, > > Michael > > :fxml:jar > :fxml:assemble > :fxpackager:buildJavaFXPackager > javafxpackager.cpp > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258) > : warning C4018: '<' : signed/unsigned mismatch > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269) > : warning C4018: '<' : signed/unsigned mismatch > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286) > : warning C4018: '<' : signed/unsigned mismatch > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426) > : warning C4996: 'getenv': This function or variable may be unsafe. > Consider using _dupenv_s instead. To disable deprecation,use > _CRT_SECURE_NO_WARNINGS. See online help for details. > C:/Program Files (x86)/Microsoft Visual Studio > 10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal > error LNK1123: failure during conversion to COFF: file invalid or corrupt > :fxpackager:buildJavaFXPackager FAILED > > FAILURE: Build failed with an exception. > > * Where: > Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817 > > * What went wrong: > Execution failed for task ':fxpackager:buildJavaFXPackager'. > >> Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio >> > 10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123 > From mario at datenwort.at Sat Mar 22 14:47:17 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Sat, 22 Mar 2014 14:47:17 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: <532DA163.7040608@oracle.com> References: <532DA163.7040608@oracle.com> Message-ID: <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: So, JavaFX does not break anything and it is up to the app developer to take the risk or not. if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. -- Kevin Mario Ivankovits wrote: Hi Thomas! Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. They should act like a transparent proxy. Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? @Override public boolean equals(Object obj) { return obj == delegate; // && this == obj } @Override public int hashCode() { return delegate.hashCode(); } Regards, Mario Am 22.03.2014 um 14:22 schrieb Tomas Mikula : A simpler and more universal solution is to also override removeListener: public void removeListener(ChangeListener listener) { super.removeListener(decorated(listener)); } And the equals() method on decorated listeners only compares the delegates (thus is symmetric). Regards, Tomas On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: The suspicious thing about your solution is that your smart implementation of equals() is not symmetric. In case the observable value is visible only within your project, you could do this: interface Subscription { void unsubscribe(); } class MyObservableValue implements ObservableValue { public Subscription subscribe(ChangeListener listener) { ChangeListener decorated = decorate(listener); addListener(decorated); return () -> removeListener(decorated); } } and use subscribe()/unsubscribe() instead of addListener()/removeListener(): Subscription sub = observableValue.subscribe(listener); // ... sub.unsubscribe(); Of course this is not possible if you need to pass the observable value to the outside world as ObservableValue. Regards, Tomas On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: Hi! In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) { a listener decoration can be smart enough to not only check against itself, but also against its delegate. What do you think? I could prepare a patch for the *ExpressionHelper classes. Best regards, Mario From kevin.rushforth at oracle.com Sat Mar 22 14:50:01 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Mar 2014 07:50:01 -0700 Subject: Ability to decorate ChangeListener In-Reply-To: <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> Message-ID: <532DA319.9000006@oracle.com> What if changeListeners[index] is null? Maybe this is already illegal.... Anyway, let's see what Martin has to say. In the mean time you file a JIRA enhancement request (issuetype=Tweak) if you like. -- Kevin Mario Ivankovits wrote: > The only thing which I ask for is to flip this ?if" in the > *ExpressionHelper classes: > So, JavaFX does not break anything and it is up to the app developer > to take the risk or not. > >>>>>> if (listener.equals(changeListeners[index])) { >>>>>> >>>>>> If we flip this to >>>>>> >>>>>> if (changeListeners[index].equals(listener)) > > > > Am 22.03.2014 um 15:42 schrieb Kevin Rushforth > >: > >> If you are talking about a change to the JavaFX API, we are not >> likely to accept such a change if it breaks the contract of equals() >> or hashcode(). In your own app it may not matter, but it is dangerous >> to assume it won't matter to anyone. Martin owns the core libraries >> and can comment further. >> >> -- Kevin >> >> >> Mario Ivankovits wrote: >>> Hi Thomas! >>> >>> Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. >>> Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. >>> >>> Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. >>> They should act like a transparent proxy. >>> >>> Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. >>> It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? >>> >>> @Override >>> public boolean equals(Object obj) >>> { >>> return obj == delegate; // && this == obj >>> } >>> >>> @Override >>> public int hashCode() >>> { >>> return delegate.hashCode(); >>> } >>> >>> >>> Regards, >>> Mario >>> >>> >>> Am 22.03.2014 um 14:22 schrieb Tomas Mikula : >>> >>> >>>> A simpler and more universal solution is to also override removeListener: >>>> >>>> public void removeListener(ChangeListener listener) { >>>> super.removeListener(decorated(listener)); >>>> } >>>> >>>> And the equals() method on decorated listeners only compares the >>>> delegates (thus is symmetric). >>>> >>>> Regards, >>>> Tomas >>>> >>>> >>>> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >>>> >>>>> The suspicious thing about your solution is that your smart >>>>> implementation of equals() is not symmetric. >>>>> >>>>> In case the observable value is visible only within your project, you >>>>> could do this: >>>>> >>>>> interface Subscription { >>>>> void unsubscribe(); >>>>> } >>>>> >>>>> class MyObservableValue implements ObservableValue { >>>>> public Subscription subscribe(ChangeListener listener) { >>>>> ChangeListener decorated = decorate(listener); >>>>> addListener(decorated); >>>>> return () -> removeListener(decorated); >>>>> } >>>>> } >>>>> >>>>> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >>>>> >>>>> Subscription sub = observableValue.subscribe(listener); >>>>> // ... >>>>> sub.unsubscribe(); >>>>> >>>>> Of course this is not possible if you need to pass the observable >>>>> value to the outside world as ObservableValue. >>>>> >>>>> Regards, >>>>> Tomas >>>>> >>>>> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >>>>>> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >>>>>> >>>>>> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >>>>>> >>>>>> if (listener.equals(changeListeners[index])) { >>>>>> >>>>>> If we flip this to >>>>>> >>>>>> if (changeListeners[index].equals(listener)) { >>>>>> >>>>>> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> I could prepare a patch for the *ExpressionHelper classes. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Mario >>>>>> >>>>>> >>>>>> >>> >>> > From mario at datenwort.at Sat Mar 22 14:54:33 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Sat, 22 Mar 2014 14:54:33 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: <532DA319.9000006@oracle.com> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532DA319.9000006@oracle.com> Message-ID: <37457597-F3B2-4D1C-9D14-652DAC2B2B62@datenwort.at> Yep, null throws a NullPointerException in addListener by design (also in removeListener) - the listener collection is safe. Am 22.03.2014 um 15:50 schrieb Kevin Rushforth >: What if changeListeners[index] is null? Maybe this is already illegal.... Anyway, let's see what Martin has to say. In the mean time you file a JIRA enhancement request (issuetype=Tweak) if you like. -- Kevin Mario Ivankovits wrote: The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: So, JavaFX does not break anything and it is up to the app developer to take the risk or not. if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. -- Kevin Mario Ivankovits wrote: Hi Thomas! Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. They should act like a transparent proxy. Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? @Override public boolean equals(Object obj) { return obj == delegate; // && this == obj } @Override public int hashCode() { return delegate.hashCode(); } Regards, Mario Am 22.03.2014 um 14:22 schrieb Tomas Mikula : A simpler and more universal solution is to also override removeListener: public void removeListener(ChangeListener listener) { super.removeListener(decorated(listener)); } And the equals() method on decorated listeners only compares the delegates (thus is symmetric). Regards, Tomas On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: The suspicious thing about your solution is that your smart implementation of equals() is not symmetric. In case the observable value is visible only within your project, you could do this: interface Subscription { void unsubscribe(); } class MyObservableValue implements ObservableValue { public Subscription subscribe(ChangeListener listener) { ChangeListener decorated = decorate(listener); addListener(decorated); return () -> removeListener(decorated); } } and use subscribe()/unsubscribe() instead of addListener()/removeListener(): Subscription sub = observableValue.subscribe(listener); // ... sub.unsubscribe(); Of course this is not possible if you need to pass the observable value to the outside world as ObservableValue. Regards, Tomas On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: Hi! In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) { a listener decoration can be smart enough to not only check against itself, but also against its delegate. What do you think? I could prepare a patch for the *ExpressionHelper classes. Best regards, Mario From tomas.mikula at gmail.com Sat Mar 22 14:55:17 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 15:55:17 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> Message-ID: Hi Mario, even if your proposal gets accepted, you would still depend on an implementation detail of JavaFX, which is always good to avoid. To sum up, my second proposal compared to your current solution: (+) your equals() stays symmetric; (+) no need for an extra Map of listeners. My second proposal compared to your desired solution if your proposal is accepted: (+) your equals() stays symmetric; (+) you don't depend on an implementation detail in JavaFX. Best, Tomas On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits wrote: > The only thing which I ask for is to flip this ?if" in the *ExpressionHelper > classes: > So, JavaFX does not break anything and it is up to the app developer to take > the risk or not. > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) > > > > > Am 22.03.2014 um 15:42 schrieb Kevin Rushforth : > > If you are talking about a change to the JavaFX API, we are not likely to > accept such a change if it breaks the contract of equals() or hashcode(). In > your own app it may not matter, but it is dangerous to assume it won't > matter to anyone. Martin owns the core libraries and can comment further. > > -- Kevin > > > Mario Ivankovits wrote: > > Hi Thomas! > > Thanks for your input. Because I want to decorated listeners added by JavaFX > core I can not use the sub/unsub pattern. > Your second proposal is almost what I do right now. In removeListener I > consult a map where the decorated listeners and their undecorated one lives. > > Regarding the symmetric doubts. Such listeners will always be removed by > passing in the undecorated object to removeListener. > They should act like a transparent proxy. > > Even if this breaks the equals paradigm, in this special case I can > perfectly live with an equals/hashCode implementation like this below. > It won?t break your app; as long as both objects do not live in the same > HashSet/Map ?. for sure - but why should they? > > @Override > public boolean equals(Object obj) > { > return obj == delegate; // && this == obj > } > > @Override > public int hashCode() > { > return delegate.hashCode(); > } > > > Regards, > Mario > > > Am 22.03.2014 um 14:22 schrieb Tomas Mikula : > > > > A simpler and more universal solution is to also override removeListener: > > public void removeListener(ChangeListener listener) { > super.removeListener(decorated(listener)); > } > > And the equals() method on decorated listeners only compares the > delegates (thus is symmetric). > > Regards, > Tomas > > > On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula > wrote: > > > The suspicious thing about your solution is that your smart > implementation of equals() is not symmetric. > > In case the observable value is visible only within your project, you > could do this: > > interface Subscription { > void unsubscribe(); > } > > class MyObservableValue implements ObservableValue { > public Subscription subscribe(ChangeListener listener) { > ChangeListener decorated = decorate(listener); > addListener(decorated); > return () -> removeListener(decorated); > } > } > > and use subscribe()/unsubscribe() instead of addListener()/removeListener(): > > Subscription sub = observableValue.subscribe(listener); > // ... > sub.unsubscribe(); > > Of course this is not possible if you need to pass the observable > value to the outside world as ObservableValue. > > Regards, > Tomas > > On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits > wrote: > > > Hi! > > In one of my ObservableValue implementations I do have the need to decorate > ChangeListener added to it. > Today this is somewhat complicated to implement, as I have to keep a map of > the original listener to the decorated one to being able to handle the > removal process of a listener. Because the outside World did not know that I > decorated the listener and the instance passed in to removeListener ist the > undecorated one. > > We can make things easier with a small change in > ExpressionHelper.removeListener. When iterating through the listener list, > the listener passed in as argument to removeListener is asked if it is equal > to the one stored > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) { > > a listener decoration can be smart enough to not only check against itself, > but also against its delegate. > > What do you think? > > I could prepare a patch for the *ExpressionHelper classes. > > > Best regards, > Mario > > > > > > > From mario at datenwort.at Sat Mar 22 15:11:13 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Sat, 22 Mar 2014 15:11:13 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> Message-ID: <5E668E89-EFCA-4149-82A4-B2054129A56D@datenwort.at> Probably you avoid the map, but it requires to decorate the listener again, right? If you think about the tons of observable values and add/removeListener operations in an tree view when scrolling it might get costly and put pressure on the GC. Anyway, I will be more than happy to assist with a cleaner solution by introduction an interface like DecoratedChangeListener which provides a special .equalsChangeListener(ChangeListener other) method. Am 22.03.2014 um 15:55 schrieb Tomas Mikula >: Hi Mario, even if your proposal gets accepted, you would still depend on an implementation detail of JavaFX, which is always good to avoid. To sum up, my second proposal compared to your current solution: (+) your equals() stays symmetric; (+) no need for an extra Map of listeners. My second proposal compared to your desired solution if your proposal is accepted: (+) your equals() stays symmetric; (+) you don't depend on an implementation detail in JavaFX. Best, Tomas On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits > wrote: The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: So, JavaFX does not break anything and it is up to the app developer to take the risk or not. if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. -- Kevin Mario Ivankovits wrote: Hi Thomas! Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. They should act like a transparent proxy. Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? @Override public boolean equals(Object obj) { return obj == delegate; // && this == obj } @Override public int hashCode() { return delegate.hashCode(); } Regards, Mario Am 22.03.2014 um 14:22 schrieb Tomas Mikula >: A simpler and more universal solution is to also override removeListener: public void removeListener(ChangeListener listener) { super.removeListener(decorated(listener)); } And the equals() method on decorated listeners only compares the delegates (thus is symmetric). Regards, Tomas On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula > wrote: The suspicious thing about your solution is that your smart implementation of equals() is not symmetric. In case the observable value is visible only within your project, you could do this: interface Subscription { void unsubscribe(); } class MyObservableValue implements ObservableValue { public Subscription subscribe(ChangeListener listener) { ChangeListener decorated = decorate(listener); addListener(decorated); return () -> removeListener(decorated); } } and use subscribe()/unsubscribe() instead of addListener()/removeListener(): Subscription sub = observableValue.subscribe(listener); // ... sub.unsubscribe(); Of course this is not possible if you need to pass the observable value to the outside world as ObservableValue. Regards, Tomas On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits > wrote: Hi! In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored if (listener.equals(changeListeners[index])) { If we flip this to if (changeListeners[index].equals(listener)) { a listener decoration can be smart enough to not only check against itself, but also against its delegate. What do you think? I could prepare a patch for the *ExpressionHelper classes. Best regards, Mario From tom.schindl at bestsolution.at Sat Mar 22 15:23:38 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 22 Mar 2014 16:23:38 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> Message-ID: Why not i expect the property to be fully initialize so this would be a breaking change in behavior. Tom Von meinem iPhone gesendet > Am 22.03.2014 um 14:54 schrieb Tomas Mikula : > > On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl > wrote: >> Hi Richard, >> >> Coming back to this old thread and now that we are using lamdas all over >> I guess we could take one more look into that. >> >> I've prototyped an initial version by introducing a new internal type >> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >> code pasted below. >> >> And now one can write code like this: >> >>> public final ObjectProperty viewportProperty() { >>> if (viewport == null) { >>> viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { >>> invalidateWidthHeight(); >>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>> impl_geomChanged(); >>> } ); >>> } >>> return viewport; >>> } >> >> instead of >> >>> public final ObjectProperty viewportProperty() { >>> if (viewport == null) { >>> viewport = new ObjectPropertyBase() { >>> >>> @Override >>> protected void invalidated() { >>> invalidateWidthHeight(); >>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>> impl_geomChanged(); >>> } >>> >>> @Override >>> public Object getBean() { >>> return ImageView.this; >>> } >>> >>> @Override >>> public String getName() { >>> return "viewport"; >>> } >>> }; >>> } >>> return viewport; >>> } > > Nice idea. Just to get the comparison to status quo more fair, you > don't need to override getBean() and getName() methods: > > public final ObjectProperty viewportProperty() { > if (viewport == null) { > viewport = new SimpleObjectProperty(this, "viewport") { > > @Override > protected void invalidated() { > invalidateWidthHeight(); > impl_markDirty(DirtyBits.NODE_VIEWPORT); > impl_geomChanged(); > } > }; > } > return viewport; > } > > Regards, > Tomas > >> >> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >> >> Tom >> >> >>> package com.sun.javafx.property; >>> >>> import java.util.function.Consumer; >>> >>> import javafx.beans.property.SimpleObjectProperty; >>> >>> public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { >>> private final Consumer> invalidationConsumer; >>> >>> /** >>> * The constructor of {@code ObjectProperty} >>> * >>> * @param initialValue >>> * the initial value of the wrapped value >>> * @param invalidationConsumer >>> * the consumer to be called when the bean is invalidated >>> */ >>> public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { >>> super(initialValue); >>> if( invalidationConsumer == null ) { >>> throw new IllegalArgumentException("Consumer can not be null"); >>> } >>> this.invalidationConsumer = invalidationConsumer; >>> } >>> >>> /** >>> * The constructor of {@code ObjectProperty} >>> * >>> * @param bean >>> * the bean of this {@code ObjectProperty} >>> * @param name >>> * the name of this {@code ObjectProperty} >>> * @param invalidationConsumer >>> * the consumer to be called when the bean is invalidated >>> */ >>> public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { >>> super(bean, name); >>> if( invalidationConsumer == null ) { >>> throw new IllegalArgumentException("Consumer can not be null"); >>> } >>> this.invalidationConsumer = invalidationConsumer; >>> } >>> >>> /** >>> * The constructor of {@code ObjectProperty} >>> * >>> * @param bean >>> * the bean of this {@code ObjectProperty} >>> * @param name >>> * the name of this {@code ObjectProperty} >>> * @param initialValue >>> * the initial value of the wrapped value >>> * @param invalidationConsumer >>> * the consumer to be called when the bean is invalidated >>> */ >>> public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { >>> super(bean,name,initialValue); >>> if( invalidationConsumer == null ) { >>> throw new IllegalArgumentException("Consumer can not be null"); >>> } >>> this.invalidationConsumer = invalidationConsumer; >>> } >>> >>> @Override >>> protected void invalidated() { >>> invalidationConsumer.accept(this); >>> } >>> } >> >> >> On 22.01.13 10:30, Richard Bair wrote: >>>> Is the Java8 plan still there if not should the current Simple*Property >>>> subclasses who overload invalidated be changed to PropertyBase? >>> >>> It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. >> From tom.schindl at bestsolution.at Sat Mar 22 15:41:05 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 22 Mar 2014 16:41:05 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> Message-ID: <6A8AEBD0-E49A-4ABE-932D-1AA6EC102F8B@bestsolution.at> Ah i missed you passing them to the constructor. Still i don't see this as much an improvement because we still create a vast amount of anon inner classes. Tom Von meinem iPhone gesendet > Am 22.03.2014 um 16:23 schrieb Tom Schindl : > > Why not i expect the property to be fully initialize so this would be a breaking change in behavior. > > Tom > > Von meinem iPhone gesendet > >> Am 22.03.2014 um 14:54 schrieb Tomas Mikula : >> >> On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl >> wrote: >>> Hi Richard, >>> >>> Coming back to this old thread and now that we are using lamdas all over >>> I guess we could take one more look into that. >>> >>> I've prototyped an initial version by introducing a new internal type >>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>> code pasted below. >>> >>> And now one can write code like this: >>> >>>> public final ObjectProperty viewportProperty() { >>>> if (viewport == null) { >>>> viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { >>>> invalidateWidthHeight(); >>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>> impl_geomChanged(); >>>> } ); >>>> } >>>> return viewport; >>>> } >>> >>> instead of >>> >>>> public final ObjectProperty viewportProperty() { >>>> if (viewport == null) { >>>> viewport = new ObjectPropertyBase() { >>>> >>>> @Override >>>> protected void invalidated() { >>>> invalidateWidthHeight(); >>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>> impl_geomChanged(); >>>> } >>>> >>>> @Override >>>> public Object getBean() { >>>> return ImageView.this; >>>> } >>>> >>>> @Override >>>> public String getName() { >>>> return "viewport"; >>>> } >>>> }; >>>> } >>>> return viewport; >>>> } >> >> Nice idea. Just to get the comparison to status quo more fair, you >> don't need to override getBean() and getName() methods: >> >> public final ObjectProperty viewportProperty() { >> if (viewport == null) { >> viewport = new SimpleObjectProperty(this, "viewport") { >> >> @Override >> protected void invalidated() { >> invalidateWidthHeight(); >> impl_markDirty(DirtyBits.NODE_VIEWPORT); >> impl_geomChanged(); >> } >> }; >> } >> return viewport; >> } >> >> Regards, >> Tomas >> >>> >>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>> >>> Tom >>> >>> >>>> package com.sun.javafx.property; >>>> >>>> import java.util.function.Consumer; >>>> >>>> import javafx.beans.property.SimpleObjectProperty; >>>> >>>> public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { >>>> private final Consumer> invalidationConsumer; >>>> >>>> /** >>>> * The constructor of {@code ObjectProperty} >>>> * >>>> * @param initialValue >>>> * the initial value of the wrapped value >>>> * @param invalidationConsumer >>>> * the consumer to be called when the bean is invalidated >>>> */ >>>> public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { >>>> super(initialValue); >>>> if( invalidationConsumer == null ) { >>>> throw new IllegalArgumentException("Consumer can not be null"); >>>> } >>>> this.invalidationConsumer = invalidationConsumer; >>>> } >>>> >>>> /** >>>> * The constructor of {@code ObjectProperty} >>>> * >>>> * @param bean >>>> * the bean of this {@code ObjectProperty} >>>> * @param name >>>> * the name of this {@code ObjectProperty} >>>> * @param invalidationConsumer >>>> * the consumer to be called when the bean is invalidated >>>> */ >>>> public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { >>>> super(bean, name); >>>> if( invalidationConsumer == null ) { >>>> throw new IllegalArgumentException("Consumer can not be null"); >>>> } >>>> this.invalidationConsumer = invalidationConsumer; >>>> } >>>> >>>> /** >>>> * The constructor of {@code ObjectProperty} >>>> * >>>> * @param bean >>>> * the bean of this {@code ObjectProperty} >>>> * @param name >>>> * the name of this {@code ObjectProperty} >>>> * @param initialValue >>>> * the initial value of the wrapped value >>>> * @param invalidationConsumer >>>> * the consumer to be called when the bean is invalidated >>>> */ >>>> public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { >>>> super(bean,name,initialValue); >>>> if( invalidationConsumer == null ) { >>>> throw new IllegalArgumentException("Consumer can not be null"); >>>> } >>>> this.invalidationConsumer = invalidationConsumer; >>>> } >>>> >>>> @Override >>>> protected void invalidated() { >>>> invalidationConsumer.accept(this); >>>> } >>>> } >>> >>> >>> On 22.01.13 10:30, Richard Bair wrote: >>>>> Is the Java8 plan still there if not should the current Simple*Property >>>>> subclasses who overload invalidated be changed to PropertyBase? >>>> >>>> It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. >>> From tomas.mikula at gmail.com Sat Mar 22 15:42:23 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 16:42:23 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: <5E668E89-EFCA-4149-82A4-B2054129A56D@datenwort.at> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <5E668E89-EFCA-4149-82A4-B2054129A56D@datenwort.at> Message-ID: On Sat, Mar 22, 2014 at 4:11 PM, Mario Ivankovits wrote: > Probably you avoid the map, but it requires to decorate the listener again, > right? Right. For a pair of addListener-removeListener calls, you have 2 decorations instead of 1. I usually think of the costs in asymptotic terms: if 1 decoration is cheap, then 2 decorations are cheap as well. Or, if we can afford n decorations, then we can probably afford 2n decorations. I know this is not quite true in real world (200ms is not the same as 100ms), but is a good way to think about complexity. > If you think about the tons of observable values and add/removeListener > operations in an tree view when scrolling it might get costly and put > pressure on the GC. removeListener creates one extra short-lived object. I don't know if it is still true for the current garbage collector in Hotspot, but a while ago I read that creating a lot of cheap short-lived objects is fine for the GC. Regards, Tomas > > Anyway, I will be more than happy to assist with a cleaner solution by > introduction an interface like DecoratedChangeListener which provides a > special .equalsChangeListener(ChangeListener other) method. > > > Am 22.03.2014 um 15:55 schrieb Tomas Mikula : > > Hi Mario, > > even if your proposal gets accepted, you would still depend on an > implementation detail of JavaFX, which is always good to avoid. > > To sum up, my second proposal compared to your current solution: > > (+) your equals() stays symmetric; > (+) no need for an extra Map of listeners. > > My second proposal compared to your desired solution if your proposal > is accepted: > > (+) your equals() stays symmetric; > (+) you don't depend on an implementation detail in JavaFX. > > Best, > Tomas > > On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits > wrote: > > The only thing which I ask for is to flip this ?if" in the *ExpressionHelper > classes: > So, JavaFX does not break anything and it is up to the app developer to take > the risk or not. > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) > > > > > Am 22.03.2014 um 15:42 schrieb Kevin Rushforth : > > If you are talking about a change to the JavaFX API, we are not likely to > accept such a change if it breaks the contract of equals() or hashcode(). In > your own app it may not matter, but it is dangerous to assume it won't > matter to anyone. Martin owns the core libraries and can comment further. > > -- Kevin > > > Mario Ivankovits wrote: > > Hi Thomas! > > Thanks for your input. Because I want to decorated listeners added by JavaFX > core I can not use the sub/unsub pattern. > Your second proposal is almost what I do right now. In removeListener I > consult a map where the decorated listeners and their undecorated one lives. > > Regarding the symmetric doubts. Such listeners will always be removed by > passing in the undecorated object to removeListener. > They should act like a transparent proxy. > > Even if this breaks the equals paradigm, in this special case I can > perfectly live with an equals/hashCode implementation like this below. > It won?t break your app; as long as both objects do not live in the same > HashSet/Map ?. for sure - but why should they? > > @Override > public boolean equals(Object obj) > { > return obj == delegate; // && this == obj > } > > @Override > public int hashCode() > { > return delegate.hashCode(); > } > > > Regards, > Mario > > > Am 22.03.2014 um 14:22 schrieb Tomas Mikula : > > > > A simpler and more universal solution is to also override removeListener: > > public void removeListener(ChangeListener listener) { > super.removeListener(decorated(listener)); > } > > And the equals() method on decorated listeners only compares the > delegates (thus is symmetric). > > Regards, > Tomas > > > On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula > wrote: > > > The suspicious thing about your solution is that your smart > implementation of equals() is not symmetric. > > In case the observable value is visible only within your project, you > could do this: > > interface Subscription { > void unsubscribe(); > } > > class MyObservableValue implements ObservableValue { > public Subscription subscribe(ChangeListener listener) { > ChangeListener decorated = decorate(listener); > addListener(decorated); > return () -> removeListener(decorated); > } > } > > and use subscribe()/unsubscribe() instead of addListener()/removeListener(): > > Subscription sub = observableValue.subscribe(listener); > // ... > sub.unsubscribe(); > > Of course this is not possible if you need to pass the observable > value to the outside world as ObservableValue. > > Regards, > Tomas > > On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits > wrote: > > > Hi! > > In one of my ObservableValue implementations I do have the need to decorate > ChangeListener added to it. > Today this is somewhat complicated to implement, as I have to keep a map of > the original listener to the decorated one to being able to handle the > removal process of a listener. Because the outside World did not know that I > decorated the listener and the instance passed in to removeListener ist the > undecorated one. > > We can make things easier with a small change in > ExpressionHelper.removeListener. When iterating through the listener list, > the listener passed in as argument to removeListener is asked if it is equal > to the one stored > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) { > > a listener decoration can be smart enough to not only check against itself, > but also against its delegate. > > What do you think? > > I could prepare a patch for the *ExpressionHelper classes. > > > Best regards, > Mario > > From tomas.mikula at gmail.com Sat Mar 22 15:47:15 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 16:47:15 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: <6A8AEBD0-E49A-4ABE-932D-1AA6EC102F8B@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <6A8AEBD0-E49A-4ABE-932D-1AA6EC102F8B@bestsolution.at> Message-ID: On Sat, Mar 22, 2014 at 4:41 PM, Tom Schindl wrote: > Ah i missed you passing them to the constructor. > > Still i don't see this as much an improvement because we still create a vast amount of anon inner classes. Sure, I just wanted to get the baseline for comparison right. Tomas > > Tom > > Von meinem iPhone gesendet > >> Am 22.03.2014 um 16:23 schrieb Tom Schindl : >> >> Why not i expect the property to be fully initialize so this would be a breaking change in behavior. >> >> Tom >> >> Von meinem iPhone gesendet >> >>> Am 22.03.2014 um 14:54 schrieb Tomas Mikula : >>> >>> On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl >>> wrote: >>>> Hi Richard, >>>> >>>> Coming back to this old thread and now that we are using lamdas all over >>>> I guess we could take one more look into that. >>>> >>>> I've prototyped an initial version by introducing a new internal type >>>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>>> code pasted below. >>>> >>>> And now one can write code like this: >>>> >>>>> public final ObjectProperty viewportProperty() { >>>>> if (viewport == null) { >>>>> viewport = new InvalidatedSimpleObjectProperty<>(this, "viewport", (o) -> { >>>>> invalidateWidthHeight(); >>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>> impl_geomChanged(); >>>>> } ); >>>>> } >>>>> return viewport; >>>>> } >>>> >>>> instead of >>>> >>>>> public final ObjectProperty viewportProperty() { >>>>> if (viewport == null) { >>>>> viewport = new ObjectPropertyBase() { >>>>> >>>>> @Override >>>>> protected void invalidated() { >>>>> invalidateWidthHeight(); >>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>> impl_geomChanged(); >>>>> } >>>>> >>>>> @Override >>>>> public Object getBean() { >>>>> return ImageView.this; >>>>> } >>>>> >>>>> @Override >>>>> public String getName() { >>>>> return "viewport"; >>>>> } >>>>> }; >>>>> } >>>>> return viewport; >>>>> } >>> >>> Nice idea. Just to get the comparison to status quo more fair, you >>> don't need to override getBean() and getName() methods: >>> >>> public final ObjectProperty viewportProperty() { >>> if (viewport == null) { >>> viewport = new SimpleObjectProperty(this, "viewport") { >>> >>> @Override >>> protected void invalidated() { >>> invalidateWidthHeight(); >>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>> impl_geomChanged(); >>> } >>> }; >>> } >>> return viewport; >>> } >>> >>> Regards, >>> Tomas >>> >>>> >>>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>>> >>>> Tom >>>> >>>> >>>>> package com.sun.javafx.property; >>>>> >>>>> import java.util.function.Consumer; >>>>> >>>>> import javafx.beans.property.SimpleObjectProperty; >>>>> >>>>> public final class InvalidatedSimpleObjectProperty extends SimpleObjectProperty { >>>>> private final Consumer> invalidationConsumer; >>>>> >>>>> /** >>>>> * The constructor of {@code ObjectProperty} >>>>> * >>>>> * @param initialValue >>>>> * the initial value of the wrapped value >>>>> * @param invalidationConsumer >>>>> * the consumer to be called when the bean is invalidated >>>>> */ >>>>> public InvalidatedSimpleObjectProperty(T initialValue, final Consumer> invalidationConsumer) { >>>>> super(initialValue); >>>>> if( invalidationConsumer == null ) { >>>>> throw new IllegalArgumentException("Consumer can not be null"); >>>>> } >>>>> this.invalidationConsumer = invalidationConsumer; >>>>> } >>>>> >>>>> /** >>>>> * The constructor of {@code ObjectProperty} >>>>> * >>>>> * @param bean >>>>> * the bean of this {@code ObjectProperty} >>>>> * @param name >>>>> * the name of this {@code ObjectProperty} >>>>> * @param invalidationConsumer >>>>> * the consumer to be called when the bean is invalidated >>>>> */ >>>>> public InvalidatedSimpleObjectProperty(Object bean, String name, final Consumer> invalidationConsumer) { >>>>> super(bean, name); >>>>> if( invalidationConsumer == null ) { >>>>> throw new IllegalArgumentException("Consumer can not be null"); >>>>> } >>>>> this.invalidationConsumer = invalidationConsumer; >>>>> } >>>>> >>>>> /** >>>>> * The constructor of {@code ObjectProperty} >>>>> * >>>>> * @param bean >>>>> * the bean of this {@code ObjectProperty} >>>>> * @param name >>>>> * the name of this {@code ObjectProperty} >>>>> * @param initialValue >>>>> * the initial value of the wrapped value >>>>> * @param invalidationConsumer >>>>> * the consumer to be called when the bean is invalidated >>>>> */ >>>>> public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final Consumer> invalidationConsumer) { >>>>> super(bean,name,initialValue); >>>>> if( invalidationConsumer == null ) { >>>>> throw new IllegalArgumentException("Consumer can not be null"); >>>>> } >>>>> this.invalidationConsumer = invalidationConsumer; >>>>> } >>>>> >>>>> @Override >>>>> protected void invalidated() { >>>>> invalidationConsumer.accept(this); >>>>> } >>>>> } >>>> >>>> >>>> On 22.01.13 10:30, Richard Bair wrote: >>>>>> Is the Java8 plan still there if not should the current Simple*Property >>>>>> subclasses who overload invalidated be changed to PropertyBase? >>>>> >>>>> It is unlikely that we'll be able to do anything major here in Java 8 just because we don't really have Lambda yet that we can play with, and changing over every property is a big job. Unless we knew it would be a major win. I would say, if you encounter a Simple* property that has been subclassed, then we should fix it up as we go to be a PropertyBase* guy instead. >>>> From mjrb5 at kent.ac.uk Sat Mar 22 15:48:26 2014 From: mjrb5 at kent.ac.uk (Michael Berry) Date: Sat, 22 Mar 2014 15:48:26 +0000 Subject: LNK1123: failure during conversion to COFF when building under windows In-Reply-To: <532DA243.5000601@oracle.com> References: <532DA243.5000601@oracle.com> Message-ID: Hi Kevin, Many thanks for that - that has solved the problem! Perhaps the wiki pageshould be updated to note that SP1 should be installed as well as vanilla VS2010? I would do it myself, but don't have the privileges. Thanks, Michael On 22 March 2014 14:46, Kevin Rushforth wrote: > Do you have VS 2010 Service Pack 1? I've seen this failure on machines > that don't have SP1 installed. > > -- Kevin > > > > Michael Berry wrote: > > Hi, > > I'm currently trying to build OpenJFX from source on Windows - I've > followed the instructions on the build page and have Visual Studio 2010, > the June 2010 directx sdk, cygwin and its relevant modules installed. > However, when building it fails at the buildJavaFXPackage task (output > below.) > > I'm not sure if those warnings are normal or not, but they definitely look > suspicious. It seems the actual error that's stopping things is the "fatal > error LNK1123: failure during conversion to COFF: file invalid or corrupt" > line, though all I've found searching around for that error is that > "incremental:off" should be set to avoid it, which it already is in the > gradle task. > > Any ideas? > > Thanks, > > Michael > > :fxml:jar > :fxml:assemble > :fxpackager:buildJavaFXPackager > javafxpackager.cpp > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258) > : warning C4018: '<' : signed/unsigned mismatch > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269) > : warning C4018: '<' : signed/unsigned mismatch > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286) > : warning C4018: '<' : signed/unsigned mismatch > C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426) > : warning C4996: 'getenv': This function or variable may be unsafe. > Consider using _dupenv_s instead. To disable deprecation,use > _CRT_SECURE_NO_WARNINGS. See online help for details. > C:/Program Files (x86)/Microsoft Visual Studio > 10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal > error LNK1123: failure during conversion to COFF: file invalid or corrupt > :fxpackager:buildJavaFXPackager FAILED > > FAILURE: Build failed with an exception. > > * Where: > Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817 > > * What went wrong: > Execution failed for task ':fxpackager:buildJavaFXPackager'. > > > Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio > > > 10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123 > > > From kevin.rushforth at oracle.com Sat Mar 22 16:01:10 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Mar 2014 09:01:10 -0700 Subject: LNK1123: failure during conversion to COFF when building under windows In-Reply-To: References: <532DA243.5000601@oracle.com> Message-ID: <532DB3C6.8010002@oracle.com> Glad this solved your problem. I added "SP1" to the Wiki page. -- Kevin Michael Berry wrote: > Hi Kevin, > > Many thanks for that - that has solved the problem! Perhaps the wiki > page > should be updated to note that SP1 should be installed as well as > vanilla VS2010? I would do it myself, but don't have the privileges. > > Thanks, > > Michael > > > On 22 March 2014 14:46, Kevin Rushforth > wrote: > > Do you have VS 2010 Service Pack 1? I've seen this failure on > machines that don't have SP1 installed. > > -- Kevin > > > > Michael Berry wrote: >> Hi, >> >> I'm currently trying to build OpenJFX from source on Windows - I've >> followed the instructions on the build page and have Visual Studio 2010, >> the June 2010 directx sdk, cygwin and its relevant modules installed. >> However, when building it fails at the buildJavaFXPackage task (output >> below.) >> >> I'm not sure if those warnings are normal or not, but they definitely look >> suspicious. It seems the actual error that's stopping things is the "fatal >> error LNK1123: failure during conversion to COFF: file invalid or corrupt" >> line, though all I've found searching around for that error is that >> "incremental:off" should be set to avoid it, which it already is in the >> gradle task. >> >> Any ideas? >> >> Thanks, >> >> Michael >> >> :fxml:jar >> :fxml:assemble >> :fxpackager:buildJavaFXPackager >> javafxpackager.cpp >> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258) >> : warning C4018: '<' : signed/unsigned mismatch >> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269) >> : warning C4018: '<' : signed/unsigned mismatch >> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286) >> : warning C4018: '<' : signed/unsigned mismatch >> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426) >> : warning C4996: 'getenv': This function or variable may be unsafe. >> Consider using _dupenv_s instead. To disable deprecation,use >> _CRT_SECURE_NO_WARNINGS. See online help for details. >> C:/Program Files (x86)/Microsoft Visual Studio >> 10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal >> error LNK1123: failure during conversion to COFF: file invalid or corrupt >> :fxpackager:buildJavaFXPackager FAILED >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817 >> >> * What went wrong: >> Execution failed for task ':fxpackager:buildJavaFXPackager'. >> >>> Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio >>> >> 10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123 >> > > From tomas.mikula at gmail.com Sat Mar 22 20:40:30 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sat, 22 Mar 2014 21:40:30 +0100 Subject: Blog post: Trigger processing after a period of inactivity Message-ID: Hi all, I just want to quickly inform that I have a post on how to defer processing of user input until the user has been inactive for a certain amount of time. http://tomasmikula.github.io/blog/2014/03/22/trigger-processing-after-a-period-of-inactivity.html Best regards, Tomas From berry120 at gmail.com Sun Mar 23 01:26:22 2014 From: berry120 at gmail.com (Michael Berry) Date: Sun, 23 Mar 2014 01:26:22 +0000 Subject: Adding GStreamer plugins Message-ID: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. However, I'm not sure if I'm going about including the matroska plugin in the right way - I've currently done the following: - Downloaded the latest version of the plugins from here ( http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the matroska one to the modules/media/src/main/native/gstreamer/plugins/ folder, as well as the modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ folder (I'm unsure of this - should I add it to both these folders?). - Added all the C files from the first folder mentioned above to the plugins.vcxproj file - Added the relevant files and directory to Makefile.gstplugins - Called the additional relevant plugin_init() function in gstplugins-lite.c However, after the above I still get the same result having touched none of the native code, that being that GSTMediaPlayer throws a MediaException with flag 257, which seems to mean it couldn't create the required media from the given location. So at this point I'm a bit stuck really - of course, the whole task may be much more complicated than I'm assuming it should be. I'm not even sure if the default "gradle sdk" task is actually reflecting the changes I've made - certainly gstreamer-lite.dll seems to be exactly the same size as before, though I'm unsure if the additional plugin is meant to be embedded in this file or not. I'm experienced with Java but much less so with C++, and completely new to gradle (as of yesterday.) Is there anything obvious I'm not doing correctly, and if so would someone be kind enough to give me a bit of a nudge in the right direction? Many thanks, Michael From daniel.blaukopf at oracle.com Sun Mar 23 07:55:19 2014 From: daniel.blaukopf at oracle.com (Daniel Blaukopf) Date: Sun, 23 Mar 2014 09:55:19 +0200 Subject: Glass Robot and getSCreenCapture In-Reply-To: <532C7140.7080702@oracle.com> References: <532C6E7E.4000401@Oracle.com> <532C7140.7080702@oracle.com> Message-ID: We should be consistent about what we return, although I agree that that the actual value doesn?t seem to matter. 0 for imaginary pixels seems reasonable. On Mar 21, 2014, at 7:05 PM, Anthony Petrov wrote: > Hi David, > > I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing. > > In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen). > > So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff000000 - both look good. However, I agree that a stricter specification and a check might be the best solution. > > -- > best regards, > Anthony > > On 3/21/2014 8:53 PM, David Hill wrote: >> >> I have been working on a problem with Robot.getScreenCapture() on a 565 >> ARM device, and while doing so, encountered a couple of questions which >> I will bring up: >> >> Pixxls getScreenCapture(int x, int y, int width, int height, boolean >> isHiDPI) >> >> I don't seem any real documentation that says how x,y + width,height >> should be treated when compared to the reality of the Screen. >> What values of x,y + width,height are reasonable ? I can picture any >> number of scenarios with them that would result in a box that does not >> fit within the Screen dimensions. The only implementing code I have seen >> checks to that the width & height are >= 1. Can I/Should I handle -x >> values ? What if the requested bounds exceed the screen ? >> >> If we are making assumptions that the requested box is inside the >> screen.... then why don't we document that fact and add a check in the >> Robot class (instead of relying on the native impls). >> >> If we are assuming the requested box does not have to lie within the >> screen bounds - what should the returned values be for the pixels >> outside the screen ? Pixel Black ? (Currently I think Lens would return >> 0x instead of 0xff000000) >> >> My recommendation would be modify the JavaDoc contract to specify that >> the x,y and x+width, y+height must be within the screen bounds, with an >> IllegalArgumentException if out of bounds. This would be checked in >> Robot, prior to calling the native impls. >> >> This code is "internal" API, so I expect the real impact would be on SQE. >> From swpalmer at gmail.com Sun Mar 23 14:03:36 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 23 Mar 2014 10:03:36 -0400 Subject: Adding GStreamer plugins In-Reply-To: References: Message-ID: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: > Hi all, > > I've managed to clone and build OpenJFX successfully, and am now in the > process of trying to see how feasible it would be to add support for other > media formats. As a first port of call I'm attempting to see if I can get > the framework accepting the Matroska plugin, but seem to be coming a bit > unstuck on the native side of things (including the plugin with GStreamer.) > I've made the relevant modifications on the Java side of things to persuade > the platform to accept MKV files and pass them down to the GStreamer layer, > and that compiles and runs without any issues. > > However, I'm not sure if I'm going about including the matroska plugin in > the right way - I've currently done the following: > > - Downloaded the latest version of the plugins from here ( > http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the > matroska one to the modules/media/src/main/native/gstreamer/plugins/ > folder, as well as the > modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ > folder (I'm unsure of this - should I add it to both these folders?). > > - Added all the C files from the first folder mentioned above to the > plugins.vcxproj file > > - Added the relevant files and directory to Makefile.gstplugins > > - Called the additional relevant plugin_init() function in > gstplugins-lite.c > > However, after the above I still get the same result having touched none of > the native code, that being that GSTMediaPlayer throws a MediaException > with flag 257, which seems to mean it couldn't create the required media > from the given location. > > So at this point I'm a bit stuck really - of course, the whole task may be > much more complicated than I'm assuming it should be. I'm not even sure if > the default "gradle sdk" task is actually reflecting the changes I've made > - certainly gstreamer-lite.dll seems to be exactly the same size as before, > though I'm unsure if the additional plugin is meant to be embedded in this > file or not. I'm experienced with Java but much less so with C++, and > completely new to gradle (as of yesterday.) > > Is there anything obvious I'm not doing correctly, and if so would someone > be kind enough to give me a bit of a nudge in the right direction? > > Many thanks, > > Michael From berry120 at gmail.com Sun Mar 23 15:32:12 2014 From: berry120 at gmail.com (Michael Berry) Date: Sun, 23 Mar 2014 15:32:12 +0000 Subject: Adding GStreamer plugins In-Reply-To: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> Message-ID: Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer wrote: > I applaud your effort, but please consider while you are doing this: > Addressing RT-18009 is good > Addressing RT-2684 is way better. > https://javafx-jira.kenai.com/browse/RT-2684 > > If there is a mechanism to write a stub plugin that hooks into the > GStreamer plugin mechanism such that end users of JavaFX can write a module > (in Java, with the option of using JNI) that supplies the uncompressed > frames via a NativeByteBuffer, that would be a great start. > > Scott > > > On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: > > > Hi all, > > > > I've managed to clone and build OpenJFX successfully, and am now in the > > process of trying to see how feasible it would be to add support for > other > > media formats. As a first port of call I'm attempting to see if I can get > > the framework accepting the Matroska plugin, but seem to be coming a bit > > unstuck on the native side of things (including the plugin with > GStreamer.) > > I've made the relevant modifications on the Java side of things to > persuade > > the platform to accept MKV files and pass them down to the GStreamer > layer, > > and that compiles and runs without any issues. > > > > However, I'm not sure if I'm going about including the matroska plugin in > > the right way - I've currently done the following: > > > > - Downloaded the latest version of the plugins from here ( > > http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the > > matroska one to the modules/media/src/main/native/gstreamer/plugins/ > > folder, as well as the > > > modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ > > folder (I'm unsure of this - should I add it to both these folders?). > > > > - Added all the C files from the first folder mentioned above to the > > plugins.vcxproj file > > > > - Added the relevant files and directory to Makefile.gstplugins > > > > - Called the additional relevant plugin_init() function in > > gstplugins-lite.c > > > > However, after the above I still get the same result having touched none > of > > the native code, that being that GSTMediaPlayer throws a MediaException > > with flag 257, which seems to mean it couldn't create the required media > > from the given location. > > > > So at this point I'm a bit stuck really - of course, the whole task may > be > > much more complicated than I'm assuming it should be. I'm not even sure > if > > the default "gradle sdk" task is actually reflecting the changes I've > made > > - certainly gstreamer-lite.dll seems to be exactly the same size as > before, > > though I'm unsure if the additional plugin is meant to be embedded in > this > > file or not. I'm experienced with Java but much less so with C++, and > > completely new to gradle (as of yesterday.) > > > > Is there anything obvious I'm not doing correctly, and if so would > someone > > be kind enough to give me a bit of a nudge in the right direction? > > > > Many thanks, > > > > Michael > > -- Thanks, Michael From jonathan.giles at oracle.com Sun Mar 23 20:06:08 2014 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 24 Mar 2014 09:06:08 +1300 Subject: Error in tablevie ghost error In-Reply-To: <532EDFFE.3050306@gmail.com> References: <532EDFFE.3050306@gmail.com> Message-ID: <532F3EB0.6020506@oracle.com> It would be useful to get a more complete description of the issue and the error you are receiving. Also, this is probably better filed in the Jira issue tracker at http://javafx-jira.kenai.com In any case, if I were to guess the problem you're mentioning, it might be: https://javafx-jira.kenai.com/browse/RT-35338 This has been fixed in JavaFX 8u20. -- Jonathan On 24/03/2014 2:22 a.m., siput wrote: > Why when i clik in the area outside row contain a data and outside > column area I get an error? > > red area of eror > From adanecito at yahoo.com Sun Mar 23 22:51:40 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Sun, 23 Mar 2014 15:51:40 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... Message-ID: <1395615100.45585.YahooMailNeo@web121805.mail.ne1.yahoo.com> Hi, ? I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. ? Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. ? My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. ? Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. ? I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. ? I would really like to see how this is all done with the ensemble app from the JavaFX group. ? Regards, -Tony From tobi at ultramixer.com Sun Mar 23 23:10:30 2014 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 24 Mar 2014 00:10:30 +0100 Subject: JavaFX on iOS and Android: any real world app? Message-ID: <66EB26A9-BCC1-409D-98F7-907C555F9FF3@ultramixer.com> After showing some demos concerning JavaFX on iOS and Android we would like to see any real world JFX app for iOS or Android. Is there anybody in the mailing list who developed a real world app? What are your experiences? What about performance? Best regards, Tobi From berry120 at gmail.com Mon Mar 24 00:31:14 2014 From: berry120 at gmail.com (Michael Berry) Date: Mon, 24 Mar 2014 00:31:14 +0000 Subject: Adding GStreamer plugins In-Reply-To: References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> Message-ID: Hi all, I'm now a bit further along with this, though struggling to get the matroska plugin to compile (getting a bunch of unresolved external symbol errors for functions it uses in glib - not entirely sure why at the moment, as I said C is not my strong point.) I've also noticed the plugins currently bundled have quite a few changes to the gstreamer version, and I can't quite work out the logic behind why things have been changed the way they have - so even after the compilation issue is resolved I'm now less confident that it will just drop in and work! Again, if someone knowledgeable in this area that's lurking in the shadows could shed any light on any of this, it would be hugely appreciated. However, putting the current problems aside for a bit, the snags I hit up until this point could I think be relatively easily addressed in the documentation. With that in mind could I suggest a few additional points for the wiki? These may be obvious to the majority reading here, but as someone completely new to building JFX they had me stumped for a while! - It turns out that the Gstreamer stuff doesn't compile at all by default, which is why I wasn't seeing any changes on the native level. To ensure GStreamer is actually compiled, you need to copy the gradle.properties.template file to gradle.properties, and uncomment the "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist for any webkit alterations as per the line above.) - As well as the requirements listed, I needed the Windows SDK ( http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for GStreamer to compile successfully under Windows (7) - without it cygpath just threw a rather confusing error. - The DirectX SDK failed to install for me, Googling found the fix relatively easily ( http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023), but perhaps this could be included just for reference. - The developer workflow page ( https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" instead? I'm happy to make the above changes myself but unsure of if / where you can sign up for an account, so I'm just throwing them here for now - if anyone could point me to the right place then that'd be great! If I do ever manage to get this working (ha-ha) I'd also like to throw up a wiki page just detailing how to grab a gstreamer plugin and make the necessary changes to it to compile it into openjfx as a stop gap to then perhaps working on one or both of the above JIRA issues and seeing where I get - does this sound reasonable? Many thanks, Michael On 23 March 2014 15:32, Michael Berry wrote: > Hi Scott, > > Sure, that's in fact my eventual goal - but in order to successfully get > that far I need to work out how to compile OpenJFX with other GStreamer > plugins first, and unfortunately at the moment I seem to be getting stuck > at that hurdle! > > Time permitting, I do indeed plan to look at addressing 2684 if I can get > that far. > > Thanks, > > Michael > > > On 23 March 2014 14:03, Scott Palmer wrote: > >> I applaud your effort, but please consider while you are doing this: >> Addressing RT-18009 is good >> Addressing RT-2684 is way better. >> https://javafx-jira.kenai.com/browse/RT-2684 >> >> If there is a mechanism to write a stub plugin that hooks into the >> GStreamer plugin mechanism such that end users of JavaFX can write a module >> (in Java, with the option of using JNI) that supplies the uncompressed >> frames via a NativeByteBuffer, that would be a great start. >> >> Scott >> >> >> On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >> >> > Hi all, >> > >> > I've managed to clone and build OpenJFX successfully, and am now in the >> > process of trying to see how feasible it would be to add support for >> other >> > media formats. As a first port of call I'm attempting to see if I can >> get >> > the framework accepting the Matroska plugin, but seem to be coming a bit >> > unstuck on the native side of things (including the plugin with >> GStreamer.) >> > I've made the relevant modifications on the Java side of things to >> persuade >> > the platform to accept MKV files and pass them down to the GStreamer >> layer, >> > and that compiles and runs without any issues. >> > >> > However, I'm not sure if I'm going about including the matroska plugin >> in >> > the right way - I've currently done the following: >> > >> > - Downloaded the latest version of the plugins from here ( >> > http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the >> > matroska one to the modules/media/src/main/native/gstreamer/plugins/ >> > folder, as well as the >> > >> modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ >> > folder (I'm unsure of this - should I add it to both these folders?). >> > >> > - Added all the C files from the first folder mentioned above to the >> > plugins.vcxproj file >> > >> > - Added the relevant files and directory to Makefile.gstplugins >> > >> > - Called the additional relevant plugin_init() function in >> > gstplugins-lite.c >> > >> > However, after the above I still get the same result having touched >> none of >> > the native code, that being that GSTMediaPlayer throws a MediaException >> > with flag 257, which seems to mean it couldn't create the required media >> > from the given location. >> > >> > So at this point I'm a bit stuck really - of course, the whole task may >> be >> > much more complicated than I'm assuming it should be. I'm not even sure >> if >> > the default "gradle sdk" task is actually reflecting the changes I've >> made >> > - certainly gstreamer-lite.dll seems to be exactly the same size as >> before, >> > though I'm unsure if the additional plugin is meant to be embedded in >> this >> > file or not. I'm experienced with Java but much less so with C++, and >> > completely new to gradle (as of yesterday.) >> > >> > Is there anything obvious I'm not doing correctly, and if so would >> someone >> > be kind enough to give me a bit of a nudge in the right direction? >> > >> > Many thanks, >> > >> > Michael >> >> > > > -- > Thanks, > > Michael > -- Thanks, Michael From martin.sladecek at oracle.com Mon Mar 24 06:31:23 2014 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 24 Mar 2014 07:31:23 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> Message-ID: <532FD13B.8030001@oracle.com> Mario, thanks for your suggestion, but I think your specific case will not justify the change. First of all, as it was already said, equals should be symmetric. Knowing the implementation, you could rely on the fact that either the equals is called on the provided listener or on the listeners already in the list. Might be that somebody else would need the asymmetry to be implemented in the "listener" provided to removeListener() method and the current situation suits him, so why do the change for your case? Anyway, relying on some implementation-specific behaviour is generally a sign of bad code practice, so it should give you a hint that you should find a different solution (like the one you discussed with Tomas already). It might happen that the code would be changed / re-factored in the future or some bug would be fixed there and behaviour will change again, breaking your application in some future JFX version. Regards, -Martin On 22.3.2014 15:47, Mario Ivankovits wrote: > The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: > So, JavaFX does not break anything and it is up to the app developer to take the risk or not. > > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) > > > > Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: > > If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. > > -- Kevin > > > Mario Ivankovits wrote: > > Hi Thomas! > > Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. > Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. > > Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. > They should act like a transparent proxy. > > Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. > It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? > > @Override > public boolean equals(Object obj) > { > return obj == delegate; // && this == obj > } > > @Override > public int hashCode() > { > return delegate.hashCode(); > } > > > Regards, > Mario > > > Am 22.03.2014 um 14:22 schrieb Tomas Mikula : > > > > A simpler and more universal solution is to also override removeListener: > > public void removeListener(ChangeListener listener) { > super.removeListener(decorated(listener)); > } > > And the equals() method on decorated listeners only compares the > delegates (thus is symmetric). > > Regards, > Tomas > > > On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: > > > The suspicious thing about your solution is that your smart > implementation of equals() is not symmetric. > > In case the observable value is visible only within your project, you > could do this: > > interface Subscription { > void unsubscribe(); > } > > class MyObservableValue implements ObservableValue { > public Subscription subscribe(ChangeListener listener) { > ChangeListener decorated = decorate(listener); > addListener(decorated); > return () -> removeListener(decorated); > } > } > > and use subscribe()/unsubscribe() instead of addListener()/removeListener(): > > Subscription sub = observableValue.subscribe(listener); > // ... > sub.unsubscribe(); > > Of course this is not possible if you need to pass the observable > value to the outside world as ObservableValue. > > Regards, > Tomas > > On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: > > > Hi! > > In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. > Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. > > We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) { > > a listener decoration can be smart enough to not only check against itself, but also against its delegate. > > What do you think? > > I could prepare a patch for the *ExpressionHelper classes. > > > Best regards, > Mario > > > > > > > From hang.vo at oracle.com Mon Mar 24 07:42:36 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 24 Mar 2014 07:42:36 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36139 [TableColumn] Inconsistent behaviour when resizing the last nested column on the right Message-ID: <201403240742.s2O7gmCo027627@aojmv0008> Changeset: da21a84618ee Author: Martin Sladecek Date: 2014-03-24 08:32 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/da21a84618ee RT-36139 [TableColumn] Inconsistent behaviour when resizing the last nested column on the right Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java From mario at datenwort.at Mon Mar 24 07:46:51 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Mon, 24 Mar 2014 07:46:51 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: <532FD13B.8030001@oracle.com> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532FD13B.8030001@oracle.com> Message-ID: <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> Thanks for your answer! One thing, I think, we can agree on, is that it is overly complex for an OO language to decorate things like these listeners. What about introducing another interface like ChangeListenerDecoration with a special named ?boolean decorates(ChangeListener)) method and call this if the listeners hold by *ExpressionHelp class implements that interface? BTW: If we care about symmetry, why not change the listener.equals(otherListener) to listener == otherListener at all? Then, there are not implementation details one can make use of. I even might argue that it is a security risk to use the .equals() the way it is now, as an evil listener implementation is able to remove all listeners from the list by simply returning true from equals() It should be the responsibility of the listener in the list to know if the passed in listener justify the removal of itself, right? ? from a security standpoint! :-) Regards, Mario Am 24.03.2014 um 07:31 schrieb Martin Sladecek : > Mario, > thanks for your suggestion, but I think your specific case will not justify the change. First of all, as it was already said, equals should be symmetric. Knowing the implementation, you could rely on the fact that either the equals is called on the provided listener or on the listeners already in the list. Might be that somebody else would need the asymmetry to be implemented in the "listener" provided to removeListener() method and the current situation suits him, so why do the change for your case? > > Anyway, relying on some implementation-specific behaviour is generally a sign of bad code practice, so it should give you a hint that you should find a different solution (like the one you discussed with Tomas already). It might happen that the code would be changed / re-factored in the future or some bug would be fixed there and behaviour will change again, breaking your application in some future JFX version. > > Regards, > -Martin > > > On 22.3.2014 15:47, Mario Ivankovits wrote: >> The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: >> So, JavaFX does not break anything and it is up to the app developer to take the risk or not. >> >> >> if (listener.equals(changeListeners[index])) { >> >> If we flip this to >> >> if (changeListeners[index].equals(listener)) >> >> >> >> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: >> >> If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. >> >> -- Kevin >> >> >> Mario Ivankovits wrote: >> >> Hi Thomas! >> >> Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. >> Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. >> >> Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. >> They should act like a transparent proxy. >> >> Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. >> It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? >> >> @Override >> public boolean equals(Object obj) >> { >> return obj == delegate; // && this == obj >> } >> >> @Override >> public int hashCode() >> { >> return delegate.hashCode(); >> } >> >> >> Regards, >> Mario >> >> >> Am 22.03.2014 um 14:22 schrieb Tomas Mikula : >> >> >> >> A simpler and more universal solution is to also override removeListener: >> >> public void removeListener(ChangeListener listener) { >> super.removeListener(decorated(listener)); >> } >> >> And the equals() method on decorated listeners only compares the >> delegates (thus is symmetric). >> >> Regards, >> Tomas >> >> >> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >> >> >> The suspicious thing about your solution is that your smart >> implementation of equals() is not symmetric. >> >> In case the observable value is visible only within your project, you >> could do this: >> >> interface Subscription { >> void unsubscribe(); >> } >> >> class MyObservableValue implements ObservableValue { >> public Subscription subscribe(ChangeListener listener) { >> ChangeListener decorated = decorate(listener); >> addListener(decorated); >> return () -> removeListener(decorated); >> } >> } >> >> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >> >> Subscription sub = observableValue.subscribe(listener); >> // ... >> sub.unsubscribe(); >> >> Of course this is not possible if you need to pass the observable >> value to the outside world as ObservableValue. >> >> Regards, >> Tomas >> >> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >> >> >> Hi! >> >> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >> >> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >> >> if (listener.equals(changeListeners[index])) { >> >> If we flip this to >> >> if (changeListeners[index].equals(listener)) { >> >> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >> >> What do you think? >> >> I could prepare a patch for the *ExpressionHelper classes. >> >> >> Best regards, >> Mario >> >> >> >> >> >> >> > From hang.vo at oracle.com Mon Mar 24 07:47:44 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 24 Mar 2014 07:47:44 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36255 Selecting TreeItem programatically expands collapsed Items Message-ID: <201403240747.s2O7lspx028273@aojmv0008> Changeset: 12c8e820eb46 Author: Martin Sladecek Date: 2014-03-24 08:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/12c8e820eb46 RT-36255 Selecting TreeItem programatically expands collapsed Items Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TreeView.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java From hang.vo at oracle.com Mon Mar 24 11:03:20 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 24 Mar 2014 11:03:20 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36294 FXML binding on custom property in javafx8 not working, if that property created thrue constructor with no arguments Message-ID: <201403241103.s2OB3XJc026806@aojmv0008> Changeset: eee373287ad8 Author: Martin Sladecek Date: 2014-03-24 11:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/eee373287ad8 RT-36294 FXML binding on custom property in javafx8 not working, if that property created thrue constructor with no arguments ! modules/fxml/src/main/java/com/sun/javafx/fxml/expression/ExpressionValue.java + modules/fxml/src/test/java/javafx/fxml/ExpressionBindingController.java + modules/fxml/src/test/java/javafx/fxml/FXMLLoader_ExpressionTest.java + modules/fxml/src/test/java/javafx/fxml/IncompletePropertyContainer.java - modules/fxml/src/test/java/javafx/fxml/RT_14880Controller.java - modules/fxml/src/test/java/javafx/fxml/RT_14880Test.java - modules/fxml/src/test/java/javafx/fxml/RT_17646Controller.java - modules/fxml/src/test/java/javafx/fxml/RT_17646Test.java - modules/fxml/src/test/java/javafx/fxml/RT_18680Test.java - modules/fxml/src/test/java/javafx/fxml/RT_24465.java + modules/fxml/src/test/resources/javafx/fxml/expression_binding.fxml + modules/fxml/src/test/resources/javafx/fxml/expression_escapechars.fxml + modules/fxml/src/test/resources/javafx/fxml/expression_incomplete_property.fxml - modules/fxml/src/test/resources/javafx/fxml/rt_14880.fxml - modules/fxml/src/test/resources/javafx/fxml/rt_17646.fxml - modules/fxml/src/test/resources/javafx/fxml/rt_18680.fxml From tomas.mikula at gmail.com Mon Mar 24 13:04:15 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 24 Mar 2014 14:04:15 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532FD13B.8030001@oracle.com> <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> Message-ID: Hi Mario, On Mon, Mar 24, 2014 at 8:46 AM, Mario Ivankovits wrote: > Thanks for your answer! > > One thing, I think, we can agree on, is that it is overly complex for an OO language to decorate things like these listeners. I'm curious why you need to decorate the listeners in the first place. > What about introducing another interface like ChangeListenerDecoration with a special named ?boolean decorates(ChangeListener)) method and call this if the listeners hold by *ExpressionHelp class implements that interface? If you are writing your own ObservableValue implementation, you can as well implement your own ExpressionHelper that does whatever you want (just that you don't forget this option ;-)). > BTW: If we care about symmetry, why not change the listener.equals(otherListener) to listener == otherListener at all? Then, there are not implementation details one can make use of. > I even might argue that it is a security risk to use the .equals() the way it is now, as an evil listener implementation is able to remove all listeners from the list by simply returning true from equals() > It should be the responsibility of the listener in the list to know if the passed in listener justify the removal of itself, right? ? from a security standpoint! :-) You cannot secure your application at this level. An "evil" listener might as well introduce memory leaks, cause stack overflow, or wipe out your hard disk. Tomas > > Regards, > Mario > > > Am 24.03.2014 um 07:31 schrieb Martin Sladecek : > >> Mario, >> thanks for your suggestion, but I think your specific case will not justify the change. First of all, as it was already said, equals should be symmetric. Knowing the implementation, you could rely on the fact that either the equals is called on the provided listener or on the listeners already in the list. Might be that somebody else would need the asymmetry to be implemented in the "listener" provided to removeListener() method and the current situation suits him, so why do the change for your case? >> >> Anyway, relying on some implementation-specific behaviour is generally a sign of bad code practice, so it should give you a hint that you should find a different solution (like the one you discussed with Tomas already). It might happen that the code would be changed / re-factored in the future or some bug would be fixed there and behaviour will change again, breaking your application in some future JFX version. >> >> Regards, >> -Martin >> >> >> On 22.3.2014 15:47, Mario Ivankovits wrote: >>> The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: >>> So, JavaFX does not break anything and it is up to the app developer to take the risk or not. >>> >>> >>> if (listener.equals(changeListeners[index])) { >>> >>> If we flip this to >>> >>> if (changeListeners[index].equals(listener)) >>> >>> >>> >>> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: >>> >>> If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. >>> >>> -- Kevin >>> >>> >>> Mario Ivankovits wrote: >>> >>> Hi Thomas! >>> >>> Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. >>> Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. >>> >>> Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. >>> They should act like a transparent proxy. >>> >>> Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. >>> It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? >>> >>> @Override >>> public boolean equals(Object obj) >>> { >>> return obj == delegate; // && this == obj >>> } >>> >>> @Override >>> public int hashCode() >>> { >>> return delegate.hashCode(); >>> } >>> >>> >>> Regards, >>> Mario >>> >>> >>> Am 22.03.2014 um 14:22 schrieb Tomas Mikula : >>> >>> >>> >>> A simpler and more universal solution is to also override removeListener: >>> >>> public void removeListener(ChangeListener listener) { >>> super.removeListener(decorated(listener)); >>> } >>> >>> And the equals() method on decorated listeners only compares the >>> delegates (thus is symmetric). >>> >>> Regards, >>> Tomas >>> >>> >>> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >>> >>> >>> The suspicious thing about your solution is that your smart >>> implementation of equals() is not symmetric. >>> >>> In case the observable value is visible only within your project, you >>> could do this: >>> >>> interface Subscription { >>> void unsubscribe(); >>> } >>> >>> class MyObservableValue implements ObservableValue { >>> public Subscription subscribe(ChangeListener listener) { >>> ChangeListener decorated = decorate(listener); >>> addListener(decorated); >>> return () -> removeListener(decorated); >>> } >>> } >>> >>> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >>> >>> Subscription sub = observableValue.subscribe(listener); >>> // ... >>> sub.unsubscribe(); >>> >>> Of course this is not possible if you need to pass the observable >>> value to the outside world as ObservableValue. >>> >>> Regards, >>> Tomas >>> >>> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >>> >>> >>> Hi! >>> >>> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >>> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >>> >>> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >>> >>> if (listener.equals(changeListeners[index])) { >>> >>> If we flip this to >>> >>> if (changeListeners[index].equals(listener)) { >>> >>> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >>> >>> What do you think? >>> >>> I could prepare a patch for the *ExpressionHelper classes. >>> >>> >>> Best regards, >>> Mario >>> >>> >>> >>> >>> >>> >>> >> > From mario at datenwort.at Mon Mar 24 14:24:15 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Mon, 24 Mar 2014 14:24:15 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532FD13B.8030001@oracle.com> <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> Message-ID: Hi Tomas! No worries, I?ll go the way on my own there then. But, after this discussion I do not see why one ever used .equals() at all. Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. BTW: There are always implementation details one has to assume. For example, I have to assume that the internals will always use the add/removeListener methods and not modifying the list (or whatever) directly. There is something which we need to hold on - even if there is no documentation for things like this. Any yay, if you patch some JavaFX core stuff, you will get deeper insights and do not need to assume anymore, you KNOW how it works. Sometimes it is not easy to misuse things then to get your job done! ;-) Also, if there is a risk in there current implementation it does not help killing the discussion with the argument that there are other risks too. I am pretty well aware about stuff like that. PS: I would love to explain in detail why I decorate change listener, but this is out of scope of this thread. Regards, Mario Am 24.03.2014 um 14:04 schrieb Tomas Mikula : > Hi Mario, > > On Mon, Mar 24, 2014 at 8:46 AM, Mario Ivankovits wrote: >> Thanks for your answer! >> >> One thing, I think, we can agree on, is that it is overly complex for an OO language to decorate things like these listeners. > > I'm curious why you need to decorate the listeners in the first place. > >> What about introducing another interface like ChangeListenerDecoration with a special named ?boolean decorates(ChangeListener)) method and call this if the listeners hold by *ExpressionHelp class implements that interface? > > If you are writing your own ObservableValue implementation, you can as > well implement your own ExpressionHelper that does whatever you want > (just that you don't forget this option ;-)). > >> BTW: If we care about symmetry, why not change the listener.equals(otherListener) to listener == otherListener at all? Then, there are not implementation details one can make use of. >> I even might argue that it is a security risk to use the .equals() the way it is now, as an evil listener implementation is able to remove all listeners from the list by simply returning true from equals() >> It should be the responsibility of the listener in the list to know if the passed in listener justify the removal of itself, right? ? from a security standpoint! :-) > > You cannot secure your application at this level. An "evil" listener > might as well introduce memory leaks, cause stack overflow, or wipe > out your hard disk. > > Tomas > >> >> Regards, >> Mario >> >> >> Am 24.03.2014 um 07:31 schrieb Martin Sladecek : >> >>> Mario, >>> thanks for your suggestion, but I think your specific case will not justify the change. First of all, as it was already said, equals should be symmetric. Knowing the implementation, you could rely on the fact that either the equals is called on the provided listener or on the listeners already in the list. Might be that somebody else would need the asymmetry to be implemented in the "listener" provided to removeListener() method and the current situation suits him, so why do the change for your case? >>> >>> Anyway, relying on some implementation-specific behaviour is generally a sign of bad code practice, so it should give you a hint that you should find a different solution (like the one you discussed with Tomas already). It might happen that the code would be changed / re-factored in the future or some bug would be fixed there and behaviour will change again, breaking your application in some future JFX version. >>> >>> Regards, >>> -Martin >>> >>> >>> On 22.3.2014 15:47, Mario Ivankovits wrote: >>>> The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: >>>> So, JavaFX does not break anything and it is up to the app developer to take the risk or not. >>>> >>>> >>>> if (listener.equals(changeListeners[index])) { >>>> >>>> If we flip this to >>>> >>>> if (changeListeners[index].equals(listener)) >>>> >>>> >>>> >>>> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: >>>> >>>> If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. >>>> >>>> -- Kevin >>>> >>>> >>>> Mario Ivankovits wrote: >>>> >>>> Hi Thomas! >>>> >>>> Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. >>>> Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. >>>> >>>> Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. >>>> They should act like a transparent proxy. >>>> >>>> Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. >>>> It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? >>>> >>>> @Override >>>> public boolean equals(Object obj) >>>> { >>>> return obj == delegate; // && this == obj >>>> } >>>> >>>> @Override >>>> public int hashCode() >>>> { >>>> return delegate.hashCode(); >>>> } >>>> >>>> >>>> Regards, >>>> Mario >>>> >>>> >>>> Am 22.03.2014 um 14:22 schrieb Tomas Mikula : >>>> >>>> >>>> >>>> A simpler and more universal solution is to also override removeListener: >>>> >>>> public void removeListener(ChangeListener listener) { >>>> super.removeListener(decorated(listener)); >>>> } >>>> >>>> And the equals() method on decorated listeners only compares the >>>> delegates (thus is symmetric). >>>> >>>> Regards, >>>> Tomas >>>> >>>> >>>> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >>>> >>>> >>>> The suspicious thing about your solution is that your smart >>>> implementation of equals() is not symmetric. >>>> >>>> In case the observable value is visible only within your project, you >>>> could do this: >>>> >>>> interface Subscription { >>>> void unsubscribe(); >>>> } >>>> >>>> class MyObservableValue implements ObservableValue { >>>> public Subscription subscribe(ChangeListener listener) { >>>> ChangeListener decorated = decorate(listener); >>>> addListener(decorated); >>>> return () -> removeListener(decorated); >>>> } >>>> } >>>> >>>> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >>>> >>>> Subscription sub = observableValue.subscribe(listener); >>>> // ... >>>> sub.unsubscribe(); >>>> >>>> Of course this is not possible if you need to pass the observable >>>> value to the outside world as ObservableValue. >>>> >>>> Regards, >>>> Tomas >>>> >>>> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >>>> >>>> >>>> Hi! >>>> >>>> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >>>> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >>>> >>>> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >>>> >>>> if (listener.equals(changeListeners[index])) { >>>> >>>> If we flip this to >>>> >>>> if (changeListeners[index].equals(listener)) { >>>> >>>> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >>>> >>>> What do you think? >>>> >>>> I could prepare a patch for the *ExpressionHelper classes. >>>> >>>> >>>> Best regards, >>>> Mario >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> From martin.sladecek at oracle.com Mon Mar 24 14:36:36 2014 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 24 Mar 2014 15:36:36 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532FD13B.8030001@oracle.com> <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> Message-ID: <533042F4.30802@oracle.com> On 24.3.2014 15:24, Mario Ivankovits wrote: > But, after this discussion I do not see why one ever used .equals() at all. > > Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. > This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. > For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. One example might be in bidirectional binding. There's a special listener that takes the 2 properties that are bound together and it's equals returns true if the other listener is of the same class and it's two properties (no matter in what order) are identical. This way, you can just write Bindings.unbindBidirectional() and the internal implementation does not need to remember the listener instance anywhere. The equals() is symmetric in this case, but == would not work here. -Martin From anthony.petrov at oracle.com Mon Mar 24 14:55:25 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 24 Mar 2014 18:55:25 +0400 Subject: How to build 64-bit FX ? In-Reply-To: <532C6822.2050009@oracle.com> References: <532C48E3.80506@oracle.com> <532C50CD.6060703@oracle.com> <532C6822.2050009@oracle.com> Message-ID: <5330475D.2050306@oracle.com> Previously I simply did `rm -rf caches`, but this didn't seem to do the right job. After a completely fresh clone of a new repo and performing a build using 64-bit JDK, I finally got it working. -- best regards, Anthony On 3/21/2014 8:26 PM, Anthony Petrov wrote: > Thanks, Kevin. The build went fine. However, when starting an app, I get > the infamous "NoSuchMethodError: notifyInitAccessibility" exception (I'm > building a fresh 8u20 repo). I tried to specify > -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that > the x64 JDK I'm using to run the app has its jfxrt.jar removed. > > But(!), I can actually run the app using the (supposed to be) 64-bit FX > binaries with a 32-bit JDK. And it runs fine in this case. But how this > could possibly work? And most importantly, how do I get it work with a > 64-bit JDK? > > -- > best regards, > Anthony > > On 3/21/2014 6:46 PM, Kevin Rushforth wrote: >> If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX >> build. No additional options are needed. You need to do a "gradle clean" >> as part of your build if you previously built a 32-build in the same >> repo. Also, if not building webkit or media, make sure you update your >> stub_runtime to point to 64-bit FX binaries (your "caches" dir if doing >> a closed build). >> >> -- Kevin >> >> >> Anthony Petrov wrote: >>> Hello, >>> >>> I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a >>> 32-bit JDK, and when building FX by executing the `gradle` command, I >>> get a 32-bit FX build. >>> >>> How do I get a 64-bit FX build on the same system? What additional >>> software do I need? I suppose I need a 64-bit JDK, right? >>> >>> I have VS2010 Professional installed. Do I need to install any >>> additional development tools/compilers? >>> >>> What options/environment variables do I specify on the command line to >>> run gradle and get a 64-bit FX build? >>> >>> -- >>> best regards, >>> Anthony From anton.nashatyrev at oracle.com Mon Mar 24 14:55:58 2014 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Mon, 24 Mar 2014 18:55:58 +0400 Subject: Adding GStreamer plugins In-Reply-To: References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> Message-ID: <5330477E.9060200@oracle.com> Hi Michael, On 24.03.2014 4:31, Michael Berry wrote: > Hi all, > > I'm now a bit further along with this, though struggling to get the > matroska plugin to compile (getting a bunch of unresolved external symbol > errors for functions it uses in glib - not entirely sure why at the moment, > as I said C is not my strong point.) I've also noticed the plugins > currently bundled have quite a few changes to the gstreamer version, and I > can't quite work out the logic behind why things have been changed the way > they have - so even after the compilation issue is resolved I'm now less > confident that it will just drop in and work! Again, if someone > knowledgeable in this area that's lurking in the shadows could shed any > light on any of this, it would be hugely appreciated. > > However, putting the current problems aside for a bit, the snags I hit up > until this point could I think be relatively easily addressed in the > documentation. With that in mind could I suggest a few additional points > for the wiki? These may be obvious to the majority reading here, but as > someone completely new to building JFX they had me stumped for a while! > > - It turns out that the Gstreamer stuff doesn't compile at all by default, > which is why I wasn't seeing any changes on the native level. To ensure > GStreamer is actually compiled, you need to copy the > gradle.properties.template file to gradle.properties, and uncomment the > "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist for > any webkit alterations as per the line above.) You may just add -PCOMPILE_MEDIA=true as a gradle argument. You may also want to add -PCONF=DebugNative to build debug version (in case if you didn't find that option yet) Regards, Anton. > - As well as the requirements listed, I needed the Windows SDK ( > http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for > GStreamer to compile successfully under Windows (7) - without it cygpath > just threw a rather confusing error. > > - The DirectX SDK failed to install for me, Googling found the fix > relatively easily ( > http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023), > but perhaps this could be included just for reference. > > - The developer workflow page ( > https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers > to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" instead? > > I'm happy to make the above changes myself but unsure of if / where you can > sign up for an account, so I'm just throwing them here for now - if anyone > could point me to the right place then that'd be great! > > If I do ever manage to get this working (ha-ha) I'd also like to throw up a > wiki page just detailing how to grab a gstreamer plugin and make the > necessary changes to it to compile it into openjfx as a stop gap to then > perhaps working on one or both of the above JIRA issues and seeing where I > get - does this sound reasonable? > > Many thanks, > > Michael > > > > > On 23 March 2014 15:32, Michael Berry wrote: > >> Hi Scott, >> >> Sure, that's in fact my eventual goal - but in order to successfully get >> that far I need to work out how to compile OpenJFX with other GStreamer >> plugins first, and unfortunately at the moment I seem to be getting stuck >> at that hurdle! >> >> Time permitting, I do indeed plan to look at addressing 2684 if I can get >> that far. >> >> Thanks, >> >> Michael >> >> >> On 23 March 2014 14:03, Scott Palmer wrote: >> >>> I applaud your effort, but please consider while you are doing this: >>> Addressing RT-18009 is good >>> Addressing RT-2684 is way better. >>> https://javafx-jira.kenai.com/browse/RT-2684 >>> >>> If there is a mechanism to write a stub plugin that hooks into the >>> GStreamer plugin mechanism such that end users of JavaFX can write a module >>> (in Java, with the option of using JNI) that supplies the uncompressed >>> frames via a NativeByteBuffer, that would be a great start. >>> >>> Scott >>> >>> >>> On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >>> >>>> Hi all, >>>> >>>> I've managed to clone and build OpenJFX successfully, and am now in the >>>> process of trying to see how feasible it would be to add support for >>> other >>>> media formats. As a first port of call I'm attempting to see if I can >>> get >>>> the framework accepting the Matroska plugin, but seem to be coming a bit >>>> unstuck on the native side of things (including the plugin with >>> GStreamer.) >>>> I've made the relevant modifications on the Java side of things to >>> persuade >>>> the platform to accept MKV files and pass them down to the GStreamer >>> layer, >>>> and that compiles and runs without any issues. >>>> >>>> However, I'm not sure if I'm going about including the matroska plugin >>> in >>>> the right way - I've currently done the following: >>>> >>>> - Downloaded the latest version of the plugins from here ( >>>> http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the >>>> matroska one to the modules/media/src/main/native/gstreamer/plugins/ >>>> folder, as well as the >>>> >>> modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ >>>> folder (I'm unsure of this - should I add it to both these folders?). >>>> >>>> - Added all the C files from the first folder mentioned above to the >>>> plugins.vcxproj file >>>> >>>> - Added the relevant files and directory to Makefile.gstplugins >>>> >>>> - Called the additional relevant plugin_init() function in >>>> gstplugins-lite.c >>>> >>>> However, after the above I still get the same result having touched >>> none of >>>> the native code, that being that GSTMediaPlayer throws a MediaException >>>> with flag 257, which seems to mean it couldn't create the required media >>>> from the given location. >>>> >>>> So at this point I'm a bit stuck really - of course, the whole task may >>> be >>>> much more complicated than I'm assuming it should be. I'm not even sure >>> if >>>> the default "gradle sdk" task is actually reflecting the changes I've >>> made >>>> - certainly gstreamer-lite.dll seems to be exactly the same size as >>> before, >>>> though I'm unsure if the additional plugin is meant to be embedded in >>> this >>>> file or not. I'm experienced with Java but much less so with C++, and >>>> completely new to gradle (as of yesterday.) >>>> >>>> Is there anything obvious I'm not doing correctly, and if so would >>> someone >>>> be kind enough to give me a bit of a nudge in the right direction? >>>> >>>> Many thanks, >>>> >>>> Michael >>> >> >> -- >> Thanks, >> >> Michael >> > > From mario at datenwort.at Mon Mar 24 15:01:02 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Mon, 24 Mar 2014 15:01:02 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: <533042F4.30802@oracle.com> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532FD13B.8030001@oracle.com> <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> <533042F4.30802@oracle.com> Message-ID: Am 24.03.2014 um 15:36 schrieb Martin Sladecek : > On 24.3.2014 15:24, Mario Ivankovits wrote: >> But, after this discussion I do not see why one ever used .equals() at all. >> >> Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. >> This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. >> For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. > > One example might be in bidirectional binding. There's a special listener that takes the 2 properties that are bound together and it's equals returns true if the other listener is of the same class and it's two properties (no matter in what order) are identical. This way, you can just write Bindings.unbindBidirectional() and the internal implementation does not need to remember the listener instance anywhere. The equals() is symmetric in this case, but == would not work here. > > -Martin Ah - Thanks for this lesson! :-) OMG ? just looked up the code. The implementation of BidirectionalBinding uses weak references and it might happen that you ExpressionHelperBase.trim() them out of the listener list if either side of the bound property got garbage collected. This means, if I decorated them, they will stay in my map because there is add/removeListener asymmetry. (just to use the word symmetry again ;-) ) So, it is even more complicated to decorate that stuff. How much I?d love to see a DecoratedListener interface like you have for WeakListener ? but yay ? :-( Thanks for listening anyway! :-) Regards, Mario From tomas.mikula at gmail.com Mon Mar 24 15:03:05 2014 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 24 Mar 2014 16:03:05 +0100 Subject: Ability to decorate ChangeListener In-Reply-To: References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <532FD13B.8030001@oracle.com> <2A65FB44-98A1-4FD7-97AC-A6FF8A55F744@datenwort.at> Message-ID: On Mon, Mar 24, 2014 at 3:24 PM, Mario Ivankovits wrote: > Hi Tomas! > > No worries, I?ll go the way on my own there then. > > > But, after this discussion I do not see why one ever used .equals() at all. > > Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. As Martin pointed out, sometimes == doesn't work for you and you need (symmetric) equals(). Another example is my proposed solution #2 to your problem. Also, using equals instead of identity comparison is consistent with how Collection.remove() determines equality. > This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. > For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. > > > BTW: There are always implementation details one has to assume. For example, I have to assume that the internals will always use the add/removeListener methods and not modifying the list (or whatever) directly. > There is something which we need to hold on - even if there is no documentation for things like this. > Any yay, if you patch some JavaFX core stuff, you will get deeper insights and do not need to assume anymore, you KNOW how it works. Sometimes it is not easy to misuse things then to get your job done! ;-) > > > Also, if there is a risk in there current implementation it does not help killing the discussion with the argument that there are other risks too. > I am pretty well aware about stuff like that. > > > PS: I would love to explain in detail why I decorate change listener, but this is out of scope of this thread. > > Regards, > Mario > > > Am 24.03.2014 um 14:04 schrieb Tomas Mikula : > >> Hi Mario, >> >> On Mon, Mar 24, 2014 at 8:46 AM, Mario Ivankovits wrote: >>> Thanks for your answer! >>> >>> One thing, I think, we can agree on, is that it is overly complex for an OO language to decorate things like these listeners. >> >> I'm curious why you need to decorate the listeners in the first place. >> >>> What about introducing another interface like ChangeListenerDecoration with a special named ?boolean decorates(ChangeListener)) method and call this if the listeners hold by *ExpressionHelp class implements that interface? >> >> If you are writing your own ObservableValue implementation, you can as >> well implement your own ExpressionHelper that does whatever you want >> (just that you don't forget this option ;-)). >> >>> BTW: If we care about symmetry, why not change the listener.equals(otherListener) to listener == otherListener at all? Then, there are not implementation details one can make use of. >>> I even might argue that it is a security risk to use the .equals() the way it is now, as an evil listener implementation is able to remove all listeners from the list by simply returning true from equals() >>> It should be the responsibility of the listener in the list to know if the passed in listener justify the removal of itself, right? ? from a security standpoint! :-) >> >> You cannot secure your application at this level. An "evil" listener >> might as well introduce memory leaks, cause stack overflow, or wipe >> out your hard disk. >> >> Tomas >> >>> >>> Regards, >>> Mario >>> >>> >>> Am 24.03.2014 um 07:31 schrieb Martin Sladecek : >>> >>>> Mario, >>>> thanks for your suggestion, but I think your specific case will not justify the change. First of all, as it was already said, equals should be symmetric. Knowing the implementation, you could rely on the fact that either the equals is called on the provided listener or on the listeners already in the list. Might be that somebody else would need the asymmetry to be implemented in the "listener" provided to removeListener() method and the current situation suits him, so why do the change for your case? >>>> >>>> Anyway, relying on some implementation-specific behaviour is generally a sign of bad code practice, so it should give you a hint that you should find a different solution (like the one you discussed with Tomas already). It might happen that the code would be changed / re-factored in the future or some bug would be fixed there and behaviour will change again, breaking your application in some future JFX version. >>>> >>>> Regards, >>>> -Martin >>>> >>>> >>>> On 22.3.2014 15:47, Mario Ivankovits wrote: >>>>> The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: >>>>> So, JavaFX does not break anything and it is up to the app developer to take the risk or not. >>>>> >>>>> >>>>> if (listener.equals(changeListeners[index])) { >>>>> >>>>> If we flip this to >>>>> >>>>> if (changeListeners[index].equals(listener)) >>>>> >>>>> >>>>> >>>>> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: >>>>> >>>>> If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Mario Ivankovits wrote: >>>>> >>>>> Hi Thomas! >>>>> >>>>> Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. >>>>> Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. >>>>> >>>>> Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. >>>>> They should act like a transparent proxy. >>>>> >>>>> Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. >>>>> It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? >>>>> >>>>> @Override >>>>> public boolean equals(Object obj) >>>>> { >>>>> return obj == delegate; // && this == obj >>>>> } >>>>> >>>>> @Override >>>>> public int hashCode() >>>>> { >>>>> return delegate.hashCode(); >>>>> } >>>>> >>>>> >>>>> Regards, >>>>> Mario >>>>> >>>>> >>>>> Am 22.03.2014 um 14:22 schrieb Tomas Mikula : >>>>> >>>>> >>>>> >>>>> A simpler and more universal solution is to also override removeListener: >>>>> >>>>> public void removeListener(ChangeListener listener) { >>>>> super.removeListener(decorated(listener)); >>>>> } >>>>> >>>>> And the equals() method on decorated listeners only compares the >>>>> delegates (thus is symmetric). >>>>> >>>>> Regards, >>>>> Tomas >>>>> >>>>> >>>>> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >>>>> >>>>> >>>>> The suspicious thing about your solution is that your smart >>>>> implementation of equals() is not symmetric. >>>>> >>>>> In case the observable value is visible only within your project, you >>>>> could do this: >>>>> >>>>> interface Subscription { >>>>> void unsubscribe(); >>>>> } >>>>> >>>>> class MyObservableValue implements ObservableValue { >>>>> public Subscription subscribe(ChangeListener listener) { >>>>> ChangeListener decorated = decorate(listener); >>>>> addListener(decorated); >>>>> return () -> removeListener(decorated); >>>>> } >>>>> } >>>>> >>>>> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >>>>> >>>>> Subscription sub = observableValue.subscribe(listener); >>>>> // ... >>>>> sub.unsubscribe(); >>>>> >>>>> Of course this is not possible if you need to pass the observable >>>>> value to the outside world as ObservableValue. >>>>> >>>>> Regards, >>>>> Tomas >>>>> >>>>> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >>>>> >>>>> >>>>> Hi! >>>>> >>>>> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >>>>> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >>>>> >>>>> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >>>>> >>>>> if (listener.equals(changeListeners[index])) { >>>>> >>>>> If we flip this to >>>>> >>>>> if (changeListeners[index].equals(listener)) { >>>>> >>>>> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >>>>> >>>>> What do you think? >>>>> >>>>> I could prepare a patch for the *ExpressionHelper classes. >>>>> >>>>> >>>>> Best regards, >>>>> Mario >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> > From kevin.rushforth at oracle.com Mon Mar 24 15:04:09 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Mar 2014 08:04:09 -0700 Subject: How to build 64-bit FX ? In-Reply-To: <5330475D.2050306@oracle.com> References: <532C48E3.80506@oracle.com> <532C50CD.6060703@oracle.com> <532C6822.2050009@oracle.com> <5330475D.2050306@oracle.com> Message-ID: <53304969.3000209@oracle.com> Good to hear that you can build OK now. -- Kevin Anthony Petrov wrote: > Previously I simply did `rm -rf caches`, but this didn't seem to do > the right job. After a completely fresh clone of a new repo and > performing a build using 64-bit JDK, I finally got it working. > > -- > best regards, > Anthony > > On 3/21/2014 8:26 PM, Anthony Petrov wrote: >> Thanks, Kevin. The build went fine. However, when starting an app, I get >> the infamous "NoSuchMethodError: notifyInitAccessibility" exception (I'm >> building a fresh 8u20 repo). I tried to specify >> -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that >> the x64 JDK I'm using to run the app has its jfxrt.jar removed. >> >> But(!), I can actually run the app using the (supposed to be) 64-bit FX >> binaries with a 32-bit JDK. And it runs fine in this case. But how this >> could possibly work? And most importantly, how do I get it work with a >> 64-bit JDK? >> >> -- >> best regards, >> Anthony >> >> On 3/21/2014 6:46 PM, Kevin Rushforth wrote: >>> If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX >>> build. No additional options are needed. You need to do a "gradle >>> clean" >>> as part of your build if you previously built a 32-build in the same >>> repo. Also, if not building webkit or media, make sure you update your >>> stub_runtime to point to 64-bit FX binaries (your "caches" dir if doing >>> a closed build). >>> >>> -- Kevin >>> >>> >>> Anthony Petrov wrote: >>>> Hello, >>>> >>>> I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a >>>> 32-bit JDK, and when building FX by executing the `gradle` command, I >>>> get a 32-bit FX build. >>>> >>>> How do I get a 64-bit FX build on the same system? What additional >>>> software do I need? I suppose I need a 64-bit JDK, right? >>>> >>>> I have VS2010 Professional installed. Do I need to install any >>>> additional development tools/compilers? >>>> >>>> What options/environment variables do I specify on the command line to >>>> run gradle and get a 64-bit FX build? >>>> >>>> -- >>>> best regards, >>>> Anthony From steve.x.northover at oracle.com Mon Mar 24 15:19:43 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 24 Mar 2014 11:19:43 -0400 Subject: Ability to decorate ChangeListener In-Reply-To: <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> Message-ID: <53304D0F.2060708@oracle.com> I'm pretty sure this discussion has solidified around not flipping the equals() but this is a good example of something that we wouldn't change. If you write code that relies on this, it will break in the future when new code is added in FX that does not follow the pattern. Steve On 2014-03-22 10:47 AM, Mario Ivankovits wrote: > The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: > So, JavaFX does not break anything and it is up to the app developer to take the risk or not. > > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) > > > > Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: > > If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. > > -- Kevin > > > Mario Ivankovits wrote: > > Hi Thomas! > > Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. > Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. > > Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. > They should act like a transparent proxy. > > Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. > It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? > > @Override > public boolean equals(Object obj) > { > return obj == delegate; // && this == obj > } > > @Override > public int hashCode() > { > return delegate.hashCode(); > } > > > Regards, > Mario > > > Am 22.03.2014 um 14:22 schrieb Tomas Mikula : > > > > A simpler and more universal solution is to also override removeListener: > > public void removeListener(ChangeListener listener) { > super.removeListener(decorated(listener)); > } > > And the equals() method on decorated listeners only compares the > delegates (thus is symmetric). > > Regards, > Tomas > > > On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: > > > The suspicious thing about your solution is that your smart > implementation of equals() is not symmetric. > > In case the observable value is visible only within your project, you > could do this: > > interface Subscription { > void unsubscribe(); > } > > class MyObservableValue implements ObservableValue { > public Subscription subscribe(ChangeListener listener) { > ChangeListener decorated = decorate(listener); > addListener(decorated); > return () -> removeListener(decorated); > } > } > > and use subscribe()/unsubscribe() instead of addListener()/removeListener(): > > Subscription sub = observableValue.subscribe(listener); > // ... > sub.unsubscribe(); > > Of course this is not possible if you need to pass the observable > value to the outside world as ObservableValue. > > Regards, > Tomas > > On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: > > > Hi! > > In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. > Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. > > We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored > > if (listener.equals(changeListeners[index])) { > > If we flip this to > > if (changeListeners[index].equals(listener)) { > > a listener decoration can be smart enough to not only check against itself, but also against its delegate. > > What do you think? > > I could prepare a patch for the *ExpressionHelper classes. > > > Best regards, > Mario > > > > > > > From mario at datenwort.at Mon Mar 24 15:43:04 2014 From: mario at datenwort.at (Mario Ivankovits) Date: Mon, 24 Mar 2014 15:43:04 +0000 Subject: Ability to decorate ChangeListener In-Reply-To: <53304D0F.2060708@oracle.com> References: <532DA163.7040608@oracle.com> <953078E8-668E-4DD2-A1CD-80210EBD836E@datenwort.at> <53304D0F.2060708@oracle.com> Message-ID: Well, the topic of this thread was "Ability to decorate ChangeListener? So, any solution, provided by JavaFX core, would have been fine ? I still think this would be nice, proposing the if flip was a fault for this discussion ... Unhappily :-( Am 24.03.2014 um 16:19 schrieb Stephen F Northover : > I'm pretty sure this discussion has solidified around not flipping the equals() but this is a good example of something that we wouldn't change. If you write code that relies on this, it will break in the future when new code is added in FX that does not follow the pattern. > > Steve > > On 2014-03-22 10:47 AM, Mario Ivankovits wrote: >> The only thing which I ask for is to flip this ?if" in the *ExpressionHelper classes: >> So, JavaFX does not break anything and it is up to the app developer to take the risk or not. >> >> >> if (listener.equals(changeListeners[index])) { >> >> If we flip this to >> >> if (changeListeners[index].equals(listener)) >> >> >> >> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth >: >> >> If you are talking about a change to the JavaFX API, we are not likely to accept such a change if it breaks the contract of equals() or hashcode(). In your own app it may not matter, but it is dangerous to assume it won't matter to anyone. Martin owns the core libraries and can comment further. >> >> -- Kevin >> >> >> Mario Ivankovits wrote: >> >> Hi Thomas! >> >> Thanks for your input. Because I want to decorated listeners added by JavaFX core I can not use the sub/unsub pattern. >> Your second proposal is almost what I do right now. In removeListener I consult a map where the decorated listeners and their undecorated one lives. >> >> Regarding the symmetric doubts. Such listeners will always be removed by passing in the undecorated object to removeListener. >> They should act like a transparent proxy. >> >> Even if this breaks the equals paradigm, in this special case I can perfectly live with an equals/hashCode implementation like this below. >> It won?t break your app; as long as both objects do not live in the same HashSet/Map ?. for sure - but why should they? >> >> @Override >> public boolean equals(Object obj) >> { >> return obj == delegate; // && this == obj >> } >> >> @Override >> public int hashCode() >> { >> return delegate.hashCode(); >> } >> >> >> Regards, >> Mario >> >> >> Am 22.03.2014 um 14:22 schrieb Tomas Mikula : >> >> >> >> A simpler and more universal solution is to also override removeListener: >> >> public void removeListener(ChangeListener listener) { >> super.removeListener(decorated(listener)); >> } >> >> And the equals() method on decorated listeners only compares the >> delegates (thus is symmetric). >> >> Regards, >> Tomas >> >> >> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula wrote: >> >> >> The suspicious thing about your solution is that your smart >> implementation of equals() is not symmetric. >> >> In case the observable value is visible only within your project, you >> could do this: >> >> interface Subscription { >> void unsubscribe(); >> } >> >> class MyObservableValue implements ObservableValue { >> public Subscription subscribe(ChangeListener listener) { >> ChangeListener decorated = decorate(listener); >> addListener(decorated); >> return () -> removeListener(decorated); >> } >> } >> >> and use subscribe()/unsubscribe() instead of addListener()/removeListener(): >> >> Subscription sub = observableValue.subscribe(listener); >> // ... >> sub.unsubscribe(); >> >> Of course this is not possible if you need to pass the observable >> value to the outside world as ObservableValue. >> >> Regards, >> Tomas >> >> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits wrote: >> >> >> Hi! >> >> In one of my ObservableValue implementations I do have the need to decorate ChangeListener added to it. >> Today this is somewhat complicated to implement, as I have to keep a map of the original listener to the decorated one to being able to handle the removal process of a listener. Because the outside World did not know that I decorated the listener and the instance passed in to removeListener ist the undecorated one. >> >> We can make things easier with a small change in ExpressionHelper.removeListener. When iterating through the listener list, the listener passed in as argument to removeListener is asked if it is equal to the one stored >> >> if (listener.equals(changeListeners[index])) { >> >> If we flip this to >> >> if (changeListeners[index].equals(listener)) { >> >> a listener decoration can be smart enough to not only check against itself, but also against its delegate. >> >> What do you think? >> >> I could prepare a patch for the *ExpressionHelper classes. >> >> >> Best regards, >> Mario >> >> >> >> >> >> >> > From adanecito at yahoo.com Mon Mar 24 16:26:14 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Mon, 24 Mar 2014 09:26:14 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... In-Reply-To: <1395615100.45585.YahooMailNeo@web121805.mail.ne1.yahoo.com> References: <1395615100.45585.YahooMailNeo@web121805.mail.ne1.yahoo.com> Message-ID: <1395678374.38929.YahooMailNeo@web121802.mail.ne1.yahoo.com> Does anyone know how to codesign the jdk in the bundle created by JavaFX deploy ant task properly? I tried: codesign -f -s "3rd Party Mac Developer Application: "? name.app/Contents/Plugins/jdk1.8.0.jdk ? I get the error: name.app/Contents/Plugins/jdk1.8.0.jdk bundle format unrecognized, invalid, or unsuitable ? I am wondering what was done with Ensemble to get past this issue. ? Thanks, -Tony On Sunday, March 23, 2014 4:52 PM, Tony Anecito wrote: Hi, ? I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. ? Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. ? My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. ? Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. ? I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. ? I would really like to see how this is all done with the ensemble app from the JavaFX group. ? Regards, -Tony From jeff at reportmill.com Mon Mar 24 16:36:40 2014 From: jeff at reportmill.com (Jeff Martin) Date: Mon, 24 Mar 2014 11:36:40 -0500 Subject: Using JavaFX deploy and having signing issues... In-Reply-To: <1395678374.38929.YahooMailNeo@web121802.mail.ne1.yahoo.com> References: <1395615100.45585.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395678374.38929.YahooMailNeo@web121802.mail.ne1.yahoo.com> Message-ID: <87B0439D-147D-4D23-BC5B-A6CDE762703A@reportmill.com> I do this with my app, which works (though I don't submit it to the Mac App Store): codesign -s "Developer ID Application" RMStudio14.app jeff On Mar 24, 2014, at 11:26 AM, Tony Anecito wrote: > Does anyone know how to codesign the jdk in the bundle created by JavaFX deploy ant task properly? > I tried: > codesign -f -s "3rd Party Mac Developer Application: " name.app/Contents/Plugins/jdk1.8.0.jdk > > I get the error: name.app/Contents/Plugins/jdk1.8.0.jdk bundle format unrecognized, invalid, or unsuitable > > I am wondering what was done with Ensemble to get past this issue. > > Thanks, > -Tony > > > > On Sunday, March 23, 2014 4:52 PM, Tony Anecito wrote: > > Hi, > > I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. > > Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. > > My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. > > Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. > > I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. > > I would really like to see how this is all done with the ensemble app from the JavaFX group. > > Regards, > -Tony From danno.ferrin at oracle.com Mon Mar 24 16:52:49 2014 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 24 Mar 2014 09:52:49 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... Message-ID: Mac app store signing is a bit more cranky. The line Jeff gives is fine for Gatekeeper. Here's what we do (in order) for the app store bundler coming in 8u20 - http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/eee373287ad8/modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacAppStoreBundler.java First, we sign all the dylibs and jars in the .app bundle. We search recursively. Second, we sign all contained executables in the .app. There are at least two for packager: the launcher we provide and a file "jspawnhelper" that the jdk uses for Runtime.exec. Third, we sign everything in Contents/PlugIns and Contents/Frameworks. Frameworks is usually empty but it's there for completeness. Finally we can actually sign the app itself. All of these signatures can be done with your 3rd party signing key (3rd Party Mac Developer Application: ). Did I say finally? Silly me. We're not done. Now we package it all up with the `productbuild` tool, and pass in the installer key to the --sign argument (3rd Party Mac Developer Installer: ). One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. With all of this I've been able to get past the static analysis guards Apple has set up for their app store submission. --Danno ----- Original Message ----- From: jeff at reportmill.com To: adanecito at yahoo.com Cc: openjfx-dev at openjdk.java.net Sent: Monday, March 24, 2014 9:38:05 AM GMT -08:00 US/Canada Pacific Subject: Re: Using JavaFX deploy and having signing issues... I do this with my app, which works (though I don't submit it to the Mac App Store): codesign -s "Developer ID Application" RMStudio14.app jeff On Mar 24, 2014, at 11:26 AM, Tony Anecito wrote: > Does anyone know how to codesign the jdk in the bundle created by JavaFX deploy ant task properly? > I tried: > codesign -f -s "3rd Party Mac Developer Application: " name.app/Contents/Plugins/jdk1.8.0.jdk > > I get the error: name.app/Contents/Plugins/jdk1.8.0.jdk bundle format unrecognized, invalid, or unsuitable > > I am wondering what was done with Ensemble to get past this issue. > > Thanks, > -Tony > > > > On Sunday, March 23, 2014 4:52 PM, Tony Anecito wrote: > > Hi, > > I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. > > Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. > > My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. > > Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. > > I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. > > I would really like to see how this is all done with the ensemble app from the JavaFX group. > > Regards, > -Tony From richard.bair at oracle.com Mon Mar 24 16:57:32 2014 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 24 Mar 2014 09:57:32 -0700 Subject: Using JavaFX deploy and having signing issues... In-Reply-To: References: Message-ID: <9AC64D00-AAB9-4BAC-8743-BF068905395C@oracle.com> > One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard From lisa.selle at oracle.com Mon Mar 24 17:10:03 2014 From: lisa.selle at oracle.com (Lisa Selle) Date: Mon, 24 Mar 2014 13:10:03 -0400 Subject: [8u] Review request: RT-36360 [Monocle] Slight refactor; cache native display in java instead of native code Message-ID: <533066EB.8000809@oracle.com> Hi Daniel, Please review the following minor refactoring to the IMX monocle implementation: https://javafx-jira.kenai.com/browse/RT-36360 http://cr.openjdk.java.net/~kselle/webrev-20140324-1306-RT-36360/webrev/ Thanks, Lisa From adanecito at yahoo.com Mon Mar 24 17:24:29 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Mon, 24 Mar 2014 10:24:29 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... In-Reply-To: <9AC64D00-AAB9-4BAC-8743-BF068905395C@oracle.com> References: <9AC64D00-AAB9-4BAC-8743-BF068905395C@oracle.com> Message-ID: <1395681869.90402.YahooMailNeo@web121806.mail.ne1.yahoo.com> Thanks Richard, ? I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. ? I may have to downgrade my Mac OS X to 10.8 to?create?Apple Store distributable?JavaFX apps for the Mac. ? -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair wrote: > One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK.? It uses QuickTime and that is being disowned by apple.? This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard From danno.ferrin at oracle.com Mon Mar 24 17:46:46 2014 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 24 Mar 2014 10:46:46 -0700 Subject: Using JavaFX deploy and having signing issues... Message-ID: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito wrote: >Thanks Richard, > >? > >I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. > >So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. > >? > >I may have to downgrade my Mac OS X to 10.8 to?create?Apple Store distributable?JavaFX apps for the Mac. > >? > >-Tony > > > >On Monday, March 24, 2014 10:57 AM, Richard Bair wrote: > >> One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK.? It uses QuickTime and that is being disowned by apple.? This may be fixed in a later 8u update, but not in 8.0.0_b132. > > > >Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? > >Richard > From adanecito at yahoo.com Mon Mar 24 17:58:59 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Mon, 24 Mar 2014 10:58:59 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... In-Reply-To: References: Message-ID: <1395683939.13459.YahooMailNeo@web121802.mail.ne1.yahoo.com> So you have tried?codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image?but I am looking for the correct way get the?jdk codesigned else the app codesign fails also. ? Do you have a working example of codesign the jdk in the bundle? ? Thanks, -Tony? On Monday, March 24, 2014 11:48 AM, Danno Ferrin wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito wrote: Thanks Richard, ? I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. ? I may have to downgrade my Mac OS X to 10.8 to?create?Apple Store distributable?JavaFX apps for the Mac. ? -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair wrote: > One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK.? It uses QuickTime and that is being disowned by apple.? This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard From adanecito at yahoo.com Mon Mar 24 18:13:27 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Mon, 24 Mar 2014 11:13:27 -0700 (PDT) Subject: How to build 64-bit FX ? In-Reply-To: <53304969.3000209@oracle.com> References: <532C48E3.80506@oracle.com> <532C50CD.6060703@oracle.com> <532C6822.2050009@oracle.com> <5330475D.2050306@oracle.com> <53304969.3000209@oracle.com> Message-ID: <1395684807.34961.YahooMailNeo@web121804.mail.ne1.yahoo.com> Hi Kevin, ? I am doing a swing-javafx app and have been able to run on 64-bit OpenJDK and Windows Java. The only thing to watch out for is any native libraries. Those of course have to be 64-bit. ? Regards, -Tony On Monday, March 24, 2014 9:04 AM, Kevin Rushforth wrote: Good to hear that you can build OK now. -- Kevin Anthony Petrov wrote: > Previously I simply did `rm -rf caches`, but this didn't seem to do > the right job. After a completely fresh clone of a new repo and > performing a build using 64-bit JDK, I finally got it working. > > -- > best regards, > Anthony > > On 3/21/2014 8:26 PM, Anthony Petrov wrote: >> Thanks, Kevin. The build went fine. However, when starting an app, I get >> the infamous "NoSuchMethodError: notifyInitAccessibility" exception (I'm >> building a fresh 8u20 repo). I tried to specify >> -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that >> the x64 JDK I'm using to run the app has its jfxrt.jar removed. >> >> But(!), I can actually run the app using the (supposed to be) 64-bit FX >> binaries with a 32-bit JDK. And it runs fine in this case. But how this >> could possibly work? And most importantly, how do I get it work with a >> 64-bit JDK? >> >> -- >> best regards, >> Anthony >> >> On 3/21/2014 6:46 PM, Kevin Rushforth wrote: >>> If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX >>> build. No additional options are needed. You need to do a "gradle >>> clean" >>> as part of your build if you previously built a 32-build in the same >>> repo. Also, if not building webkit or media, make sure you update your >>> stub_runtime to point to 64-bit FX binaries (your "caches" dir if doing >>> a closed build). >>> >>> -- Kevin >>> >>> >>> Anthony Petrov wrote: >>>> Hello, >>>> >>>> I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a >>>> 32-bit JDK, and when building FX by executing the `gradle` command, I >>>> get a 32-bit FX build. >>>> >>>> How do I get a 64-bit FX build on the same system? What additional >>>> software do I need? I suppose I need a 64-bit JDK, right? >>>> >>>> I have VS2010 Professional installed. Do I need to install any >>>> additional development tools/compilers? >>>> >>>> What options/environment variables do I specify on the command line to >>>> run gradle and get a 64-bit FX build? >>>> >>>> -- >>>> best regards, >>>> Anthony From kevin.rushforth at oracle.com Mon Mar 24 20:22:18 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Mar 2014 13:22:18 -0700 Subject: How to build 64-bit FX ? In-Reply-To: <1395684807.34961.YahooMailNeo@web121804.mail.ne1.yahoo.com> References: <532C48E3.80506@oracle.com> <532C50CD.6060703@oracle.com> <532C6822.2050009@oracle.com> <5330475D.2050306@oracle.com> <53304969.3000209@oracle.com> <1395684807.34961.YahooMailNeo@web121804.mail.ne1.yahoo.com> Message-ID: <533093FA.4060404@oracle.com> Good to know. Thanks. -- Kevin Tony Anecito wrote: > Hi Kevin, > > I am doing a swing-javafx app and have been able to run on 64-bit > OpenJDK and Windows Java. The only thing to watch out for is any > native libraries. Those of course have to be 64-bit. > > Regards, > -Tony > > > On Monday, March 24, 2014 9:04 AM, Kevin Rushforth > wrote: > Good to hear that you can build OK now. > > -- Kevin > > > Anthony Petrov wrote: > > Previously I simply did `rm -rf caches`, but this didn't seem to do > > the right job. After a completely fresh clone of a new repo and > > performing a build using 64-bit JDK, I finally got it working. > > > > -- > > best regards, > > Anthony > > > > On 3/21/2014 8:26 PM, Anthony Petrov wrote: > >> Thanks, Kevin. The build went fine. However, when starting an app, > I get > >> the infamous "NoSuchMethodError: notifyInitAccessibility" exception > (I'm > >> building a fresh 8u20 repo). I tried to specify > >> -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note > that > >> the x64 JDK I'm using to run the app has its jfxrt.jar removed. > >> > >> But(!), I can actually run the app using the (supposed to be) 64-bit FX > >> binaries with a 32-bit JDK. And it runs fine in this case. But how this > >> could possibly work? And most importantly, how do I get it work with a > >> 64-bit JDK? > >> > >> -- > >> best regards, > >> Anthony > >> > >> On 3/21/2014 6:46 PM, Kevin Rushforth wrote: > >>> If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX > >>> build. No additional options are needed. You need to do a "gradle > >>> clean" > >>> as part of your build if you previously built a 32-build in the same > >>> repo. Also, if not building webkit or media, make sure you update your > >>> stub_runtime to point to 64-bit FX binaries (your "caches" dir if > doing > >>> a closed build). > >>> > >>> -- Kevin > >>> > >>> > >>> Anthony Petrov wrote: > >>>> Hello, > >>>> > >>>> I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a > >>>> 32-bit JDK, and when building FX by executing the `gradle` command, I > >>>> get a 32-bit FX build. > >>>> > >>>> How do I get a 64-bit FX build on the same system? What additional > >>>> software do I need? I suppose I need a 64-bit JDK, right? > >>>> > >>>> I have VS2010 Professional installed. Do I need to install any > >>>> additional development tools/compilers? > >>>> > >>>> What options/environment variables do I specify on the command > line to > >>>> run gradle and get a 64-bit FX build? > >>>> > >>>> -- > >>>> best regards, > >>>> Anthony > > From hang.vo at oracle.com Mon Mar 24 21:17:54 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 24 Mar 2014 21:17:54 +0000 Subject: hg: openjfx/8u-dev/rt: 5 new changesets Message-ID: <201403242118.s2OLIZhB005916@aojmv0008> Changeset: 16300af5f9f5 Author: jgiles Date: 2014-03-18 14:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/16300af5f9f5 RT0-35880: HelloSanity: Menu does not handle accelerator keys correctly Bug was in HelloSanity, not the mnemonic / accelerator code. ! apps/toys/Hello/src/main/java/hello/TestBuilder.java Changeset: 20efa4fd3487 Author: jgiles Date: 2014-03-20 16:40 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/20efa4fd3487 RT-22842: [Accessibility] ColorPicker keyboard accessibility ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPalette.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/InputFieldSkin.java Changeset: 372a4994afcd Author: jgiles Date: 2014-03-20 16:46 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/372a4994afcd Fix pagination a11y issue spotted by dgrieve. ! modules/controls/src/main/java/javafx/scene/control/Pagination.java Changeset: 3ae761425325 Author: jgiles Date: 2014-03-25 10:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3ae761425325 RT-36266: [Accessibility] Implement scrolling ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Action.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Role.java ! modules/graphics/src/main/native-glass/win/GlassAccessible.cpp ! modules/graphics/src/main/native-glass/win/GlassAccessible.h Changeset: 35858482e928 Author: jgiles Date: 2014-03-25 10:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/35858482e928 RT0-35880: HelloSanity: Menu does not handle accelerator keys correctly Bug was in HelloSanity, not the mnemonic / accelerator code. From tom.schindl at bestsolution.at Mon Mar 24 22:10:44 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Mar 2014 23:10:44 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: <532CBC82.8060104@oracle.com> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <532CBA56.9060004@oracle.com> <532CBC82.8060104@oracle.com> Message-ID: <5330AD64.4080701@bestsolution.at> Hi, I've written a small sample to see what it gets me to check: * creation overhead * memory overhead * call overhead I'm not very good at this kind of thing so someone who knows to write benchmarks might know a lot better - need to check out JMH most likely. Anyways here are the numbers: Topic Lambda Subclass -------------------------------------------------------------- Create10M 372ms (0.00003723) 220ms (0.00002205) Mem 108byte / instance 84byte / instance Call-1M*10 42ms (0.0000042) 35ms (0.0000035) Call-1*1M 11ms (0.0000011) 10ms (0.0000010) So Lamda is considerable slower 40% and takes 20% more space, call behavior is fairly the same. I'll try to learn about JMH. Tom > package hello; > > import java.util.ArrayList; > import java.util.List; > import java.util.concurrent.atomic.AtomicInteger; > import java.util.function.Consumer; > > import javafx.beans.property.ObjectProperty; > import javafx.beans.property.ObjectPropertyBase; > import javafx.beans.property.SimpleObjectProperty; > > public class TestMemory { > private static int oneIteration = 1_000_000; > private static int iterationCount = 10; > private static int invokationOverheadCallCount = 1_000_000; > > private static boolean testLambda = false; > > private static void testLambda(int iterations, List storage) { > for( int i = 0; i < iterations; i++ ) { > storage.add(new SimpleLambdaBean()); > } > } > > private static void testSubclass(int iterations, List storage) { > for( int i = 0; i < iterations; i++ ) { > storage.add(new SimpleSubclassBean()); > } > } > > public static void main(String[] args) { > System.err.println("Test Creation time"); > System.err.println("=================="); > > { > long timeDiffTotal = 0; > for( int i = 0; i < iterationCount; i++ ) { > System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); > System.err.println(" ---------------------------------"); > long s = System.currentTimeMillis(); > if( testLambda ) { > testLambda(oneIteration, new ArrayList<>()); > } else { > testSubclass(oneIteration, new ArrayList<>()); > } > long e = System.currentTimeMillis(); > long diff = e - s; > > timeDiffTotal+=diff; > System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); > > System.err.println(" ---------------------------------"); > } > > System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); > } > > List target = new ArrayList(iterationCount * oneIteration); > > { > System.err.println(""); > System.err.println("Test Creation memory"); > System.err.println("=================="); > > for( int i = 0; i < iterationCount; i++ ) { > System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); > System.err.println(" ---------------------------------"); > if( testLambda ) { > testLambda(oneIteration, target); > } else { > testSubclass(oneIteration, target); > } > > long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); > System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); > System.err.println(" ---------------------------------"); > } > > System.err.println(" Total objects created: " + target.size()); > } > > { > System.err.println(""); > System.err.println("Test invokation overhead (all then times)"); > System.err.println("========================================="); > > long s = System.currentTimeMillis(); > for( int i = 0; i < oneIteration; i++ ) { > target.get(i).invalidate(); > } > long e = System.currentTimeMillis(); > long diff = e - s; > System.err.println(" Total time calls: " + diff); > System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); > } > > { > System.err.println(""); > System.err.println("Test invokation multiple times"); > System.err.println("==============================="); > long s = System.currentTimeMillis(); > > for( int i = 0; i < invokationOverheadCallCount; i++ ) { > > } > long e = System.currentTimeMillis(); > long diff = e - s; > System.err.println(" Total time calls: " + diff); > System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); > } > > } > > public static class LamdaInvalidationProperty extends SimpleObjectProperty { > private Consumer> c; > > public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { > super(bean, name); > this.c = c; > } > > @Override > protected void invalidated() { > c.accept(this); > } > } > > public interface TestObject { > public void invalidate(); > } > > public static class SimpleLambdaBean implements TestObject { > private AtomicInteger i = new AtomicInteger(); > > private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { > i.incrementAndGet(); > }); > > public void invalidate() { > sample.setValue(new Object()); > } > } > > public static class SimpleSubclassBean implements TestObject { > private AtomicInteger i = new AtomicInteger(); > > private ObjectProperty sample = new ObjectPropertyBase() { > @Override > public Object getBean() { > return SimpleSubclassBean.this; > } > > public String getName() { > return "sample"; > } > > public Object getValue() { > return null; > } > > protected void invalidated() { > i.incrementAndGet(); > } > }; > > public void invalidate() { > sample.setValue(new Object()); > } > } > > } On 21.03.14 23:26, Kevin Rushforth wrote: > It does seem promising. We'll also need data to show the trade-offs to > help inform whether it is worth making such a massive change. > > -- Kevin > > > Stephen F Northover wrote: >> This looks good. I wonder if we should make this (massive) change >> before we lambda graphics and controls? Probably doesn't matter. >> We'll need a JIRA and someone assigned to it in order to track the work. >> >> Steve >> >> On 2014-03-21 12:53 PM, Tom Schindl wrote: >>> Hi Richard, >>> >>> Coming back to this old thread and now that we are using lamdas all over >>> I guess we could take one more look into that. >>> >>> I've prototyped an initial version by introducing a new internal type >>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>> code pasted below. >>> >>> And now one can write code like this: >>> >>>> public final ObjectProperty viewportProperty() { >>>> if (viewport == null) { >>>> viewport = new InvalidatedSimpleObjectProperty<>(this, >>>> "viewport", (o) -> { >>>> invalidateWidthHeight(); >>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>> impl_geomChanged(); >>>> } ); >>>> } >>>> return viewport; >>>> } >>> instead of >>> >>>> public final ObjectProperty viewportProperty() { >>>> if (viewport == null) { >>>> viewport = new ObjectPropertyBase() { >>>> >>>> @Override >>>> protected void invalidated() { >>>> invalidateWidthHeight(); >>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>> impl_geomChanged(); >>>> } >>>> >>>> @Override >>>> public Object getBean() { >>>> return ImageView.this; >>>> } >>>> >>>> @Override >>>> public String getName() { >>>> return "viewport"; >>>> } >>>> }; >>>> } >>>> return viewport; >>>> } >>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>> >>> Tom >>> >>> >>>> package com.sun.javafx.property; >>>> >>>> import java.util.function.Consumer; >>>> >>>> import javafx.beans.property.SimpleObjectProperty; >>>> >>>> public final class InvalidatedSimpleObjectProperty extends >>>> SimpleObjectProperty { >>>> private final Consumer> >>>> invalidationConsumer; >>>> /** >>>> * The constructor of {@code ObjectProperty} >>>> * >>>> * @param initialValue >>>> * the initial value of the wrapped value >>>> * @param invalidationConsumer >>>> * the consumer to be called when the bean is >>>> invalidated >>>> */ >>>> public InvalidatedSimpleObjectProperty(T initialValue, final >>>> Consumer> invalidationConsumer) { >>>> super(initialValue); >>>> if( invalidationConsumer == null ) { >>>> throw new IllegalArgumentException("Consumer can not be >>>> null"); >>>> } >>>> this.invalidationConsumer = invalidationConsumer; >>>> } >>>> >>>> /** >>>> * The constructor of {@code ObjectProperty} >>>> * >>>> * @param bean >>>> * the bean of this {@code ObjectProperty} >>>> * @param name >>>> * the name of this {@code ObjectProperty} >>>> * @param invalidationConsumer >>>> * the consumer to be called when the bean is >>>> invalidated >>>> */ >>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>> name, final Consumer> >>>> invalidationConsumer) { >>>> super(bean, name); >>>> if( invalidationConsumer == null ) { >>>> throw new IllegalArgumentException("Consumer can not be >>>> null"); >>>> } >>>> this.invalidationConsumer = invalidationConsumer; >>>> } >>>> >>>> /** >>>> * The constructor of {@code ObjectProperty} >>>> * >>>> * @param bean >>>> * the bean of this {@code ObjectProperty} >>>> * @param name >>>> * the name of this {@code ObjectProperty} >>>> * @param initialValue >>>> * the initial value of the wrapped value >>>> * @param invalidationConsumer >>>> * the consumer to be called when the bean is >>>> invalidated >>>> */ >>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>> name, T initialValue, final >>>> Consumer> invalidationConsumer) { >>>> super(bean,name,initialValue); >>>> if( invalidationConsumer == null ) { >>>> throw new IllegalArgumentException("Consumer can not be >>>> null"); >>>> } >>>> this.invalidationConsumer = invalidationConsumer; >>>> } >>>> @Override >>>> protected void invalidated() { >>>> invalidationConsumer.accept(this); >>>> } >>>> } >>> >>> On 22.01.13 10:30, Richard Bair wrote: >>>>> Is the Java8 plan still there if not should the current >>>>> Simple*Property >>>>> subclasses who overload invalidated be changed to PropertyBase? >>>> It is unlikely that we'll be able to do anything major here in Java >>>> 8 just because we don't really have Lambda yet that we can play >>>> with, and changing over every property is a big job. Unless we knew >>>> it would be a major win. I would say, if you encounter a Simple* >>>> property that has been subclassed, then we should fix it up as we go >>>> to be a PropertyBase* guy instead. >>>> >> From adanecito at yahoo.com Mon Mar 24 22:30:12 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Mon, 24 Mar 2014 15:30:12 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... In-Reply-To: <1395683939.13459.YahooMailNeo@web121802.mail.ne1.yahoo.com> References: <1395683939.13459.YahooMailNeo@web121802.mail.ne1.yahoo.com> Message-ID: <1395700212.98750.YahooMailNeo@web121801.mail.ne1.yahoo.com> Ok I was able to codesign and submit. The JavaFX deploy task is not creating a info.plist when the jdk is added to the bundle for the jdk. ? After submission there were some issues related to signing and it now requires a entitlements file for some things in the jre. ? Regards, -Tony On Monday, March 24, 2014 12:01 PM, Tony Anecito wrote: So you have tried?codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image?but I am looking for the correct way get the?jdk codesigned else the app codesign fails also. ? Do you have a working example of codesign the jdk in the bundle? ? Thanks, -Tony? On Monday, March 24, 2014 11:48 AM, Danno Ferrin wrote: ? You can still deploy apps to the app store using JavaFX.? You just cannot use the media library at the moment.? You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in.? And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito wrote: Thanks Richard, ? I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. ? I may have to downgrade my Mac OS X to 10.8 to?create?Apple Store distributable?JavaFX apps for the Mac. ? -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair wrote: ? > One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK.? It uses QuickTime and that is being disowned by apple.? This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard From kevin.rushforth at oracle.com Mon Mar 24 22:31:42 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Mar 2014 15:31:42 -0700 Subject: *PropertyBase vs Simple*Property In-Reply-To: <5330AD64.4080701@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <532CBA56.9060004@oracle.com> <532CBC82.8060104@oracle.com> <5330AD64.4080701@bestsolution.at> Message-ID: <5330B24E.1010205@oracle.com> Those results are surprising. Is this an apples-to-apples comparison with the only difference being a Lambda versus an equivalent anonymous inner class? -- Kevin Tom Schindl wrote: > Hi, > > I've written a small sample to see what it gets me to check: > * creation overhead > * memory overhead > * call overhead > > I'm not very good at this kind of thing so someone who knows to write > benchmarks might know a lot better - need to check out JMH most likely. > > Anyways here are the numbers: > > Topic Lambda Subclass > -------------------------------------------------------------- > Create10M 372ms (0.00003723) 220ms (0.00002205) > Mem 108byte / instance 84byte / instance > Call-1M*10 42ms (0.0000042) 35ms (0.0000035) > Call-1*1M 11ms (0.0000011) 10ms (0.0000010) > > So Lamda is considerable slower 40% and takes 20% more space, call > behavior is fairly the same. I'll try to learn about JMH. > > Tom > > > >> package hello; >> >> import java.util.ArrayList; >> import java.util.List; >> import java.util.concurrent.atomic.AtomicInteger; >> import java.util.function.Consumer; >> >> import javafx.beans.property.ObjectProperty; >> import javafx.beans.property.ObjectPropertyBase; >> import javafx.beans.property.SimpleObjectProperty; >> >> public class TestMemory { >> private static int oneIteration = 1_000_000; >> private static int iterationCount = 10; >> private static int invokationOverheadCallCount = 1_000_000; >> >> private static boolean testLambda = false; >> >> private static void testLambda(int iterations, List storage) { >> for( int i = 0; i < iterations; i++ ) { >> storage.add(new SimpleLambdaBean()); >> } >> } >> >> private static void testSubclass(int iterations, List storage) { >> for( int i = 0; i < iterations; i++ ) { >> storage.add(new SimpleSubclassBean()); >> } >> } >> >> public static void main(String[] args) { >> System.err.println("Test Creation time"); >> System.err.println("=================="); >> >> { >> long timeDiffTotal = 0; >> for( int i = 0; i < iterationCount; i++ ) { >> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >> System.err.println(" ---------------------------------"); >> long s = System.currentTimeMillis(); >> if( testLambda ) { >> testLambda(oneIteration, new ArrayList<>()); >> } else { >> testSubclass(oneIteration, new ArrayList<>()); >> } >> long e = System.currentTimeMillis(); >> long diff = e - s; >> >> timeDiffTotal+=diff; >> System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); >> >> System.err.println(" ---------------------------------"); >> } >> >> System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); >> } >> >> List target = new ArrayList(iterationCount * oneIteration); >> >> { >> System.err.println(""); >> System.err.println("Test Creation memory"); >> System.err.println("=================="); >> >> for( int i = 0; i < iterationCount; i++ ) { >> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >> System.err.println(" ---------------------------------"); >> if( testLambda ) { >> testLambda(oneIteration, target); >> } else { >> testSubclass(oneIteration, target); >> } >> >> long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); >> System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); >> System.err.println(" ---------------------------------"); >> } >> >> System.err.println(" Total objects created: " + target.size()); >> } >> >> { >> System.err.println(""); >> System.err.println("Test invokation overhead (all then times)"); >> System.err.println("========================================="); >> >> long s = System.currentTimeMillis(); >> for( int i = 0; i < oneIteration; i++ ) { >> target.get(i).invalidate(); >> } >> long e = System.currentTimeMillis(); >> long diff = e - s; >> System.err.println(" Total time calls: " + diff); >> System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); >> } >> >> { >> System.err.println(""); >> System.err.println("Test invokation multiple times"); >> System.err.println("==============================="); >> long s = System.currentTimeMillis(); >> >> for( int i = 0; i < invokationOverheadCallCount; i++ ) { >> >> } >> long e = System.currentTimeMillis(); >> long diff = e - s; >> System.err.println(" Total time calls: " + diff); >> System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); >> } >> >> } >> >> public static class LamdaInvalidationProperty extends SimpleObjectProperty { >> private Consumer> c; >> >> public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { >> super(bean, name); >> this.c = c; >> } >> >> @Override >> protected void invalidated() { >> c.accept(this); >> } >> } >> >> public interface TestObject { >> public void invalidate(); >> } >> >> public static class SimpleLambdaBean implements TestObject { >> private AtomicInteger i = new AtomicInteger(); >> >> private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { >> i.incrementAndGet(); >> }); >> >> public void invalidate() { >> sample.setValue(new Object()); >> } >> } >> >> public static class SimpleSubclassBean implements TestObject { >> private AtomicInteger i = new AtomicInteger(); >> >> private ObjectProperty sample = new ObjectPropertyBase() { >> @Override >> public Object getBean() { >> return SimpleSubclassBean.this; >> } >> >> public String getName() { >> return "sample"; >> } >> >> public Object getValue() { >> return null; >> } >> >> protected void invalidated() { >> i.incrementAndGet(); >> } >> }; >> >> public void invalidate() { >> sample.setValue(new Object()); >> } >> } >> >> } >> > > > On 21.03.14 23:26, Kevin Rushforth wrote: > >> It does seem promising. We'll also need data to show the trade-offs to >> help inform whether it is worth making such a massive change. >> >> -- Kevin >> >> >> Stephen F Northover wrote: >> >>> This looks good. I wonder if we should make this (massive) change >>> before we lambda graphics and controls? Probably doesn't matter. >>> We'll need a JIRA and someone assigned to it in order to track the work. >>> >>> Steve >>> >>> On 2014-03-21 12:53 PM, Tom Schindl wrote: >>> >>>> Hi Richard, >>>> >>>> Coming back to this old thread and now that we are using lamdas all over >>>> I guess we could take one more look into that. >>>> >>>> I've prototyped an initial version by introducing a new internal type >>>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>>> code pasted below. >>>> >>>> And now one can write code like this: >>>> >>>> >>>>> public final ObjectProperty viewportProperty() { >>>>> if (viewport == null) { >>>>> viewport = new InvalidatedSimpleObjectProperty<>(this, >>>>> "viewport", (o) -> { >>>>> invalidateWidthHeight(); >>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>> impl_geomChanged(); >>>>> } ); >>>>> } >>>>> return viewport; >>>>> } >>>>> >>>> instead of >>>> >>>> >>>>> public final ObjectProperty viewportProperty() { >>>>> if (viewport == null) { >>>>> viewport = new ObjectPropertyBase() { >>>>> >>>>> @Override >>>>> protected void invalidated() { >>>>> invalidateWidthHeight(); >>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>> impl_geomChanged(); >>>>> } >>>>> >>>>> @Override >>>>> public Object getBean() { >>>>> return ImageView.this; >>>>> } >>>>> >>>>> @Override >>>>> public String getName() { >>>>> return "viewport"; >>>>> } >>>>> }; >>>>> } >>>>> return viewport; >>>>> } >>>>> >>>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>>> >>>> Tom >>>> >>>> >>>> >>>>> package com.sun.javafx.property; >>>>> >>>>> import java.util.function.Consumer; >>>>> >>>>> import javafx.beans.property.SimpleObjectProperty; >>>>> >>>>> public final class InvalidatedSimpleObjectProperty extends >>>>> SimpleObjectProperty { >>>>> private final Consumer> >>>>> invalidationConsumer; >>>>> /** >>>>> * The constructor of {@code ObjectProperty} >>>>> * >>>>> * @param initialValue >>>>> * the initial value of the wrapped value >>>>> * @param invalidationConsumer >>>>> * the consumer to be called when the bean is >>>>> invalidated >>>>> */ >>>>> public InvalidatedSimpleObjectProperty(T initialValue, final >>>>> Consumer> invalidationConsumer) { >>>>> super(initialValue); >>>>> if( invalidationConsumer == null ) { >>>>> throw new IllegalArgumentException("Consumer can not be >>>>> null"); >>>>> } >>>>> this.invalidationConsumer = invalidationConsumer; >>>>> } >>>>> >>>>> /** >>>>> * The constructor of {@code ObjectProperty} >>>>> * >>>>> * @param bean >>>>> * the bean of this {@code ObjectProperty} >>>>> * @param name >>>>> * the name of this {@code ObjectProperty} >>>>> * @param invalidationConsumer >>>>> * the consumer to be called when the bean is >>>>> invalidated >>>>> */ >>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>> name, final Consumer> >>>>> invalidationConsumer) { >>>>> super(bean, name); >>>>> if( invalidationConsumer == null ) { >>>>> throw new IllegalArgumentException("Consumer can not be >>>>> null"); >>>>> } >>>>> this.invalidationConsumer = invalidationConsumer; >>>>> } >>>>> >>>>> /** >>>>> * The constructor of {@code ObjectProperty} >>>>> * >>>>> * @param bean >>>>> * the bean of this {@code ObjectProperty} >>>>> * @param name >>>>> * the name of this {@code ObjectProperty} >>>>> * @param initialValue >>>>> * the initial value of the wrapped value >>>>> * @param invalidationConsumer >>>>> * the consumer to be called when the bean is >>>>> invalidated >>>>> */ >>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>> name, T initialValue, final >>>>> Consumer> invalidationConsumer) { >>>>> super(bean,name,initialValue); >>>>> if( invalidationConsumer == null ) { >>>>> throw new IllegalArgumentException("Consumer can not be >>>>> null"); >>>>> } >>>>> this.invalidationConsumer = invalidationConsumer; >>>>> } >>>>> @Override >>>>> protected void invalidated() { >>>>> invalidationConsumer.accept(this); >>>>> } >>>>> } >>>>> >>>> On 22.01.13 10:30, Richard Bair wrote: >>>> >>>>>> Is the Java8 plan still there if not should the current >>>>>> Simple*Property >>>>>> subclasses who overload invalidated be changed to PropertyBase? >>>>>> >>>>> It is unlikely that we'll be able to do anything major here in Java >>>>> 8 just because we don't really have Lambda yet that we can play >>>>> with, and changing over every property is a big job. Unless we knew >>>>> it would be a major win. I would say, if you encounter a Simple* >>>>> property that has been subclassed, then we should fix it up as we go >>>>> to be a PropertyBase* guy instead. >>>>> >>>>> > > From tom.schindl at bestsolution.at Mon Mar 24 22:36:03 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Mar 2014 23:36:03 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: <5330B24E.1010205@oracle.com> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <532CBA56.9060004@oracle.com> <532CBC82.8060104@oracle.com> <5330AD64.4080701@bestsolution.at> <5330B24E.1010205@oracle.com> Message-ID: <5330B353.5090302@bestsolution.at> The code I run is attached in the mail copy it to your env and run it and flip the testLambda from true to false. I might have been something dumb wrong but this is what I came up with. Tom On 24.03.14 23:31, Kevin Rushforth wrote: > Those results are surprising. Is this an apples-to-apples comparison > with the only difference being a Lambda versus an equivalent anonymous > inner class? > > -- Kevin > > > Tom Schindl wrote: >> Hi, >> >> I've written a small sample to see what it gets me to check: >> * creation overhead >> * memory overhead >> * call overhead >> >> I'm not very good at this kind of thing so someone who knows to write >> benchmarks might know a lot better - need to check out JMH most likely. >> >> Anyways here are the numbers: >> >> Topic Lambda Subclass >> -------------------------------------------------------------- >> Create10M 372ms (0.00003723) 220ms (0.00002205) >> Mem 108byte / instance 84byte / instance >> Call-1M*10 42ms (0.0000042) 35ms (0.0000035) >> Call-1*1M 11ms (0.0000011) 10ms (0.0000010) >> >> So Lamda is considerable slower 40% and takes 20% more space, call >> behavior is fairly the same. I'll try to learn about JMH. >> >> Tom >> >> >> >>> package hello; >>> >>> import java.util.ArrayList; >>> import java.util.List; >>> import java.util.concurrent.atomic.AtomicInteger; >>> import java.util.function.Consumer; >>> >>> import javafx.beans.property.ObjectProperty; >>> import javafx.beans.property.ObjectPropertyBase; >>> import javafx.beans.property.SimpleObjectProperty; >>> >>> public class TestMemory { >>> private static int oneIteration = 1_000_000; >>> private static int iterationCount = 10; >>> private static int invokationOverheadCallCount = 1_000_000; >>> >>> private static boolean testLambda = false; >>> >>> private static void testLambda(int iterations, List storage) { >>> for( int i = 0; i < iterations; i++ ) { >>> storage.add(new SimpleLambdaBean()); >>> } >>> } >>> >>> private static void testSubclass(int iterations, List storage) { >>> for( int i = 0; i < iterations; i++ ) { >>> storage.add(new SimpleSubclassBean()); >>> } >>> } >>> >>> public static void main(String[] args) { >>> System.err.println("Test Creation time"); >>> System.err.println("=================="); >>> >>> { >>> long timeDiffTotal = 0; >>> for( int i = 0; i < iterationCount; i++ ) { >>> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >>> System.err.println(" ---------------------------------"); >>> long s = System.currentTimeMillis(); >>> if( testLambda ) { >>> testLambda(oneIteration, new ArrayList<>()); >>> } else { >>> testSubclass(oneIteration, new ArrayList<>()); >>> } >>> long e = System.currentTimeMillis(); >>> long diff = e - s; >>> >>> timeDiffTotal+=diff; >>> System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); >>> >>> System.err.println(" ---------------------------------"); >>> } >>> >>> System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); >>> } >>> >>> List target = new ArrayList(iterationCount * oneIteration); >>> >>> { >>> System.err.println(""); >>> System.err.println("Test Creation memory"); >>> System.err.println("=================="); >>> >>> for( int i = 0; i < iterationCount; i++ ) { >>> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >>> System.err.println(" ---------------------------------"); >>> if( testLambda ) { >>> testLambda(oneIteration, target); >>> } else { >>> testSubclass(oneIteration, target); >>> } >>> >>> long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); >>> System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); >>> System.err.println(" ---------------------------------"); >>> } >>> >>> System.err.println(" Total objects created: " + target.size()); >>> } >>> >>> { >>> System.err.println(""); >>> System.err.println("Test invokation overhead (all then times)"); >>> System.err.println("========================================="); >>> >>> long s = System.currentTimeMillis(); >>> for( int i = 0; i < oneIteration; i++ ) { >>> target.get(i).invalidate(); >>> } >>> long e = System.currentTimeMillis(); >>> long diff = e - s; >>> System.err.println(" Total time calls: " + diff); >>> System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); >>> } >>> >>> { >>> System.err.println(""); >>> System.err.println("Test invokation multiple times"); >>> System.err.println("==============================="); >>> long s = System.currentTimeMillis(); >>> >>> for( int i = 0; i < invokationOverheadCallCount; i++ ) { >>> >>> } >>> long e = System.currentTimeMillis(); >>> long diff = e - s; >>> System.err.println(" Total time calls: " + diff); >>> System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); >>> } >>> >>> } >>> >>> public static class LamdaInvalidationProperty extends SimpleObjectProperty { >>> private Consumer> c; >>> >>> public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { >>> super(bean, name); >>> this.c = c; >>> } >>> >>> @Override >>> protected void invalidated() { >>> c.accept(this); >>> } >>> } >>> >>> public interface TestObject { >>> public void invalidate(); >>> } >>> >>> public static class SimpleLambdaBean implements TestObject { >>> private AtomicInteger i = new AtomicInteger(); >>> >>> private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { >>> i.incrementAndGet(); >>> }); >>> >>> public void invalidate() { >>> sample.setValue(new Object()); >>> } >>> } >>> >>> public static class SimpleSubclassBean implements TestObject { >>> private AtomicInteger i = new AtomicInteger(); >>> >>> private ObjectProperty sample = new ObjectPropertyBase() { >>> @Override >>> public Object getBean() { >>> return SimpleSubclassBean.this; >>> } >>> >>> public String getName() { >>> return "sample"; >>> } >>> >>> public Object getValue() { >>> return null; >>> } >>> >>> protected void invalidated() { >>> i.incrementAndGet(); >>> } >>> }; >>> >>> public void invalidate() { >>> sample.setValue(new Object()); >>> } >>> } >>> >>> } >>> >> >> >> On 21.03.14 23:26, Kevin Rushforth wrote: >> >>> It does seem promising. We'll also need data to show the trade-offs to >>> help inform whether it is worth making such a massive change. >>> >>> -- Kevin >>> >>> >>> Stephen F Northover wrote: >>> >>>> This looks good. I wonder if we should make this (massive) change >>>> before we lambda graphics and controls? Probably doesn't matter. >>>> We'll need a JIRA and someone assigned to it in order to track the work. >>>> >>>> Steve >>>> >>>> On 2014-03-21 12:53 PM, Tom Schindl wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> Coming back to this old thread and now that we are using lamdas all over >>>>> I guess we could take one more look into that. >>>>> >>>>> I've prototyped an initial version by introducing a new internal type >>>>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>>>> code pasted below. >>>>> >>>>> And now one can write code like this: >>>>> >>>>> >>>>>> public final ObjectProperty viewportProperty() { >>>>>> if (viewport == null) { >>>>>> viewport = new InvalidatedSimpleObjectProperty<>(this, >>>>>> "viewport", (o) -> { >>>>>> invalidateWidthHeight(); >>>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>>> impl_geomChanged(); >>>>>> } ); >>>>>> } >>>>>> return viewport; >>>>>> } >>>>>> >>>>> instead of >>>>> >>>>> >>>>>> public final ObjectProperty viewportProperty() { >>>>>> if (viewport == null) { >>>>>> viewport = new ObjectPropertyBase() { >>>>>> >>>>>> @Override >>>>>> protected void invalidated() { >>>>>> invalidateWidthHeight(); >>>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>>> impl_geomChanged(); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public Object getBean() { >>>>>> return ImageView.this; >>>>>> } >>>>>> >>>>>> @Override >>>>>> public String getName() { >>>>>> return "viewport"; >>>>>> } >>>>>> }; >>>>>> } >>>>>> return viewport; >>>>>> } >>>>>> >>>>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>>> package com.sun.javafx.property; >>>>>> >>>>>> import java.util.function.Consumer; >>>>>> >>>>>> import javafx.beans.property.SimpleObjectProperty; >>>>>> >>>>>> public final class InvalidatedSimpleObjectProperty extends >>>>>> SimpleObjectProperty { >>>>>> private final Consumer> >>>>>> invalidationConsumer; >>>>>> /** >>>>>> * The constructor of {@code ObjectProperty} >>>>>> * >>>>>> * @param initialValue >>>>>> * the initial value of the wrapped value >>>>>> * @param invalidationConsumer >>>>>> * the consumer to be called when the bean is >>>>>> invalidated >>>>>> */ >>>>>> public InvalidatedSimpleObjectProperty(T initialValue, final >>>>>> Consumer> invalidationConsumer) { >>>>>> super(initialValue); >>>>>> if( invalidationConsumer == null ) { >>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>> null"); >>>>>> } >>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>> } >>>>>> >>>>>> /** >>>>>> * The constructor of {@code ObjectProperty} >>>>>> * >>>>>> * @param bean >>>>>> * the bean of this {@code ObjectProperty} >>>>>> * @param name >>>>>> * the name of this {@code ObjectProperty} >>>>>> * @param invalidationConsumer >>>>>> * the consumer to be called when the bean is >>>>>> invalidated >>>>>> */ >>>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>>> name, final Consumer> >>>>>> invalidationConsumer) { >>>>>> super(bean, name); >>>>>> if( invalidationConsumer == null ) { >>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>> null"); >>>>>> } >>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>> } >>>>>> >>>>>> /** >>>>>> * The constructor of {@code ObjectProperty} >>>>>> * >>>>>> * @param bean >>>>>> * the bean of this {@code ObjectProperty} >>>>>> * @param name >>>>>> * the name of this {@code ObjectProperty} >>>>>> * @param initialValue >>>>>> * the initial value of the wrapped value >>>>>> * @param invalidationConsumer >>>>>> * the consumer to be called when the bean is >>>>>> invalidated >>>>>> */ >>>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>>> name, T initialValue, final >>>>>> Consumer> invalidationConsumer) { >>>>>> super(bean,name,initialValue); >>>>>> if( invalidationConsumer == null ) { >>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>> null"); >>>>>> } >>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>> } >>>>>> @Override >>>>>> protected void invalidated() { >>>>>> invalidationConsumer.accept(this); >>>>>> } >>>>>> } >>>>>> >>>>> On 22.01.13 10:30, Richard Bair wrote: >>>>> >>>>>>> Is the Java8 plan still there if not should the current >>>>>>> Simple*Property >>>>>>> subclasses who overload invalidated be changed to PropertyBase? >>>>>>> >>>>>> It is unlikely that we'll be able to do anything major here in Java >>>>>> 8 just because we don't really have Lambda yet that we can play >>>>>> with, and changing over every property is a big job. Unless we knew >>>>>> it would be a major win. I would say, if you encounter a Simple* >>>>>> property that has been subclassed, then we should fix it up as we go >>>>>> to be a PropertyBase* guy instead. >>>>>> >>>>>> >> >> From phidias51 at gmail.com Mon Mar 24 22:39:12 2014 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 24 Mar 2014 15:39:12 -0700 Subject: Using JavaFX deploy and having signing issues... In-Reply-To: <1395700212.98750.YahooMailNeo@web121801.mail.ne1.yahoo.com> References: <1395683939.13459.YahooMailNeo@web121802.mail.ne1.yahoo.com> <1395700212.98750.YahooMailNeo@web121801.mail.ne1.yahoo.com> Message-ID: Tony and/or Danno, Would you mind documenting the steps that you had to go through to make a Mac application that was submittable to the Apple Store? I'm sure everyone who's struggling to create applications would appreciate the information. Cheers, Mark On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito wrote: > Ok I was able to codesign and submit. The JavaFX deploy task is not > creating a info.plist when the jdk is added to the bundle for the jdk. > > After submission there were some issues related to signing and it now > requires a entitlements file for some things in the jre. > > Regards, > -Tony > > > > On Monday, March 24, 2014 12:01 PM, Tony Anecito > wrote: > > So you have tried codesign with Mavericks OS X? I am getting invalid > bundle when the jdk is bundled as required by the Apple Store. You have to > codesign the jdk plugin seprately. > Yes you can create a pkg or dmg image but I am looking for the correct way > get the jdk codesigned else the app codesign fails also. > > Do you have a working example of codesign the jdk in the bundle? > > Thanks, > -Tony > > > > > On Monday, March 24, 2014 11:48 AM, Danno Ferrin > wrote: > > You can still deploy apps to the app store using JavaFX. You just cannot > use the media library at the moment. You can do it also via non app store > distribution and sign it via gatekeeper as well and keep the media > libraries in. And it shouldn't matter what version of Mac OSX you use to > build it. > > Tony Anecito wrote: > > > Thanks Richard, > > I know some more now. It seems with Mavericks 10.9 codesign and the bundle > format that JavaFX deploy creates is no longer valid. There are starting to > appear to be more references to this issue on the internet. > So JavaFX apps can no longer be created and work on the Mac at least as > far as the Apple Store is concerned. > > I may have to downgrade my Mac OS X to 10.8 to create Apple Store > distributable JavaFX apps for the Mac. > > -Tony > > > > On Monday, March 24, 2014 10:57 AM, Richard Bair > wrote: > > > One last hurdle, you need to remove the media library for JavaFX > (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that > is being disowned by apple. This may be fixed in a later 8u update, but > not in 8.0.0_b132. > > Oh good grief, Apple! So what should we be using instead? This means I > cannot make use of fx media in any app submitted to the app store? > > Richard > From tom.schindl at bestsolution.at Mon Mar 24 22:40:15 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Mar 2014 23:40:15 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: <5330B353.5090302@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <532CBA56.9060004@oracle.com> <532CBC82.8060104@oracle.com> <5330AD64.4080701@bestsolution.at> <5330B24E.1010205@oracle.com> <5330B353.5090302@bestsolution.at> Message-ID: <5330B44F.8060704@bestsolution.at> Ups there was an error in my test for the last Call line so the numbers there are: 38 (lambda) vs 32 (subclass) > package hello; > > import java.util.ArrayList; > import java.util.List; > import java.util.concurrent.atomic.AtomicInteger; > import java.util.function.Consumer; > > import javafx.beans.property.ObjectProperty; > import javafx.beans.property.ObjectPropertyBase; > import javafx.beans.property.SimpleObjectProperty; > > public class TestMemory { > private static int oneIteration = 1_000_000; > private static int iterationCount = 10; > private static int invokationOverheadCallCount = 1_000_000; > > private static boolean testLambda = false; > > private static void testLambda(int iterations, List storage) { > for( int i = 0; i < iterations; i++ ) { > storage.add(new SimpleLambdaBean()); > } > } > > private static void testSubclass(int iterations, List storage) { > for( int i = 0; i < iterations; i++ ) { > storage.add(new SimpleSubclassBean()); > } > } > > public static void main(String[] args) { > System.err.println("Test Creation time"); > System.err.println("=================="); > > { > long timeDiffTotal = 0; > for( int i = 0; i < iterationCount; i++ ) { > System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); > System.err.println(" ---------------------------------"); > long s = System.currentTimeMillis(); > if( testLambda ) { > testLambda(oneIteration, new ArrayList<>()); > } else { > testSubclass(oneIteration, new ArrayList<>()); > } > long e = System.currentTimeMillis(); > long diff = e - s; > > timeDiffTotal+=diff; > System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); > > System.err.println(" ---------------------------------"); > } > > System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); > } > > List target = new ArrayList(iterationCount * oneIteration); > > { > System.err.println(""); > System.err.println("Test Creation memory"); > System.err.println("=================="); > > for( int i = 0; i < iterationCount; i++ ) { > System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); > System.err.println(" ---------------------------------"); > if( testLambda ) { > testLambda(oneIteration, target); > } else { > testSubclass(oneIteration, target); > } > > long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); > System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); > System.err.println(" ---------------------------------"); > } > > System.err.println(" Total objects created: " + target.size()); > } > > { > System.err.println(""); > System.err.println("Test invokation overhead (all then times)"); > System.err.println("========================================="); > > long s = System.currentTimeMillis(); > for( int i = 0; i < oneIteration; i++ ) { > target.get(i).invalidate(); > } > long e = System.currentTimeMillis(); > long diff = e - s; > System.err.println(" Total time calls: " + diff); > System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); > } > > { > System.err.println(""); > System.err.println("Test invokation multiple times"); > System.err.println("==============================="); > long s = System.currentTimeMillis(); > TestObject o = target.get(0); > for( int i = 0; i < invokationOverheadCallCount; i++ ) { > o.invalidate(); > } > long e = System.currentTimeMillis(); > long diff = e - s; > System.err.println(" Total time calls: " + diff); > System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); > } > > } > > public static class LamdaInvalidationProperty extends SimpleObjectProperty { > private Consumer> c; > > public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { > super(bean, name); > this.c = c; > } > > @Override > protected void invalidated() { > c.accept(this); > } > } > > public interface TestObject { > public void invalidate(); > } > > public static class SimpleLambdaBean implements TestObject { > private AtomicInteger i = new AtomicInteger(); > > private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { > i.incrementAndGet(); > }); > > public void invalidate() { > sample.setValue(new Object()); > } > } > > public static class SimpleSubclassBean implements TestObject { > private AtomicInteger i = new AtomicInteger(); > > private ObjectProperty sample = new ObjectPropertyBase() { > @Override > public Object getBean() { > return SimpleSubclassBean.this; > } > > public String getName() { > return "sample"; > } > > public Object getValue() { > return null; > } > > protected void invalidated() { > i.incrementAndGet(); > } > }; > > public void invalidate() { > sample.setValue(new Object()); > } > } > > } On 24.03.14 23:36, Tom Schindl wrote: > The code I run is attached in the mail copy it to your env and run it > and flip the testLambda from true to false. > > I might have been something dumb wrong but this is what I came up with. > > Tom > > On 24.03.14 23:31, Kevin Rushforth wrote: >> Those results are surprising. Is this an apples-to-apples comparison >> with the only difference being a Lambda versus an equivalent anonymous >> inner class? >> >> -- Kevin >> >> >> Tom Schindl wrote: >>> Hi, >>> >>> I've written a small sample to see what it gets me to check: >>> * creation overhead >>> * memory overhead >>> * call overhead >>> >>> I'm not very good at this kind of thing so someone who knows to write >>> benchmarks might know a lot better - need to check out JMH most likely. >>> >>> Anyways here are the numbers: >>> >>> Topic Lambda Subclass >>> -------------------------------------------------------------- >>> Create10M 372ms (0.00003723) 220ms (0.00002205) >>> Mem 108byte / instance 84byte / instance >>> Call-1M*10 42ms (0.0000042) 35ms (0.0000035) >>> Call-1*1M 11ms (0.0000011) 10ms (0.0000010) >>> >>> So Lamda is considerable slower 40% and takes 20% more space, call >>> behavior is fairly the same. I'll try to learn about JMH. >>> >>> Tom >>> >>> >>> >>>> package hello; >>>> >>>> import java.util.ArrayList; >>>> import java.util.List; >>>> import java.util.concurrent.atomic.AtomicInteger; >>>> import java.util.function.Consumer; >>>> >>>> import javafx.beans.property.ObjectProperty; >>>> import javafx.beans.property.ObjectPropertyBase; >>>> import javafx.beans.property.SimpleObjectProperty; >>>> >>>> public class TestMemory { >>>> private static int oneIteration = 1_000_000; >>>> private static int iterationCount = 10; >>>> private static int invokationOverheadCallCount = 1_000_000; >>>> >>>> private static boolean testLambda = false; >>>> >>>> private static void testLambda(int iterations, List storage) { >>>> for( int i = 0; i < iterations; i++ ) { >>>> storage.add(new SimpleLambdaBean()); >>>> } >>>> } >>>> >>>> private static void testSubclass(int iterations, List storage) { >>>> for( int i = 0; i < iterations; i++ ) { >>>> storage.add(new SimpleSubclassBean()); >>>> } >>>> } >>>> >>>> public static void main(String[] args) { >>>> System.err.println("Test Creation time"); >>>> System.err.println("=================="); >>>> >>>> { >>>> long timeDiffTotal = 0; >>>> for( int i = 0; i < iterationCount; i++ ) { >>>> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >>>> System.err.println(" ---------------------------------"); >>>> long s = System.currentTimeMillis(); >>>> if( testLambda ) { >>>> testLambda(oneIteration, new ArrayList<>()); >>>> } else { >>>> testSubclass(oneIteration, new ArrayList<>()); >>>> } >>>> long e = System.currentTimeMillis(); >>>> long diff = e - s; >>>> >>>> timeDiffTotal+=diff; >>>> System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); >>>> >>>> System.err.println(" ---------------------------------"); >>>> } >>>> >>>> System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); >>>> } >>>> >>>> List target = new ArrayList(iterationCount * oneIteration); >>>> >>>> { >>>> System.err.println(""); >>>> System.err.println("Test Creation memory"); >>>> System.err.println("=================="); >>>> >>>> for( int i = 0; i < iterationCount; i++ ) { >>>> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >>>> System.err.println(" ---------------------------------"); >>>> if( testLambda ) { >>>> testLambda(oneIteration, target); >>>> } else { >>>> testSubclass(oneIteration, target); >>>> } >>>> >>>> long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); >>>> System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); >>>> System.err.println(" ---------------------------------"); >>>> } >>>> >>>> System.err.println(" Total objects created: " + target.size()); >>>> } >>>> >>>> { >>>> System.err.println(""); >>>> System.err.println("Test invokation overhead (all then times)"); >>>> System.err.println("========================================="); >>>> >>>> long s = System.currentTimeMillis(); >>>> for( int i = 0; i < oneIteration; i++ ) { >>>> target.get(i).invalidate(); >>>> } >>>> long e = System.currentTimeMillis(); >>>> long diff = e - s; >>>> System.err.println(" Total time calls: " + diff); >>>> System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); >>>> } >>>> >>>> { >>>> System.err.println(""); >>>> System.err.println("Test invokation multiple times"); >>>> System.err.println("==============================="); >>>> long s = System.currentTimeMillis(); >>>> >>>> for( int i = 0; i < invokationOverheadCallCount; i++ ) { >>>> >>>> } >>>> long e = System.currentTimeMillis(); >>>> long diff = e - s; >>>> System.err.println(" Total time calls: " + diff); >>>> System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); >>>> } >>>> >>>> } >>>> >>>> public static class LamdaInvalidationProperty extends SimpleObjectProperty { >>>> private Consumer> c; >>>> >>>> public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { >>>> super(bean, name); >>>> this.c = c; >>>> } >>>> >>>> @Override >>>> protected void invalidated() { >>>> c.accept(this); >>>> } >>>> } >>>> >>>> public interface TestObject { >>>> public void invalidate(); >>>> } >>>> >>>> public static class SimpleLambdaBean implements TestObject { >>>> private AtomicInteger i = new AtomicInteger(); >>>> >>>> private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { >>>> i.incrementAndGet(); >>>> }); >>>> >>>> public void invalidate() { >>>> sample.setValue(new Object()); >>>> } >>>> } >>>> >>>> public static class SimpleSubclassBean implements TestObject { >>>> private AtomicInteger i = new AtomicInteger(); >>>> >>>> private ObjectProperty sample = new ObjectPropertyBase() { >>>> @Override >>>> public Object getBean() { >>>> return SimpleSubclassBean.this; >>>> } >>>> >>>> public String getName() { >>>> return "sample"; >>>> } >>>> >>>> public Object getValue() { >>>> return null; >>>> } >>>> >>>> protected void invalidated() { >>>> i.incrementAndGet(); >>>> } >>>> }; >>>> >>>> public void invalidate() { >>>> sample.setValue(new Object()); >>>> } >>>> } >>>> >>>> } >>>> >>> >>> >>> On 21.03.14 23:26, Kevin Rushforth wrote: >>> >>>> It does seem promising. We'll also need data to show the trade-offs to >>>> help inform whether it is worth making such a massive change. >>>> >>>> -- Kevin >>>> >>>> >>>> Stephen F Northover wrote: >>>> >>>>> This looks good. I wonder if we should make this (massive) change >>>>> before we lambda graphics and controls? Probably doesn't matter. >>>>> We'll need a JIRA and someone assigned to it in order to track the work. >>>>> >>>>> Steve >>>>> >>>>> On 2014-03-21 12:53 PM, Tom Schindl wrote: >>>>> >>>>>> Hi Richard, >>>>>> >>>>>> Coming back to this old thread and now that we are using lamdas all over >>>>>> I guess we could take one more look into that. >>>>>> >>>>>> I've prototyped an initial version by introducing a new internal type >>>>>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>>>>> code pasted below. >>>>>> >>>>>> And now one can write code like this: >>>>>> >>>>>> >>>>>>> public final ObjectProperty viewportProperty() { >>>>>>> if (viewport == null) { >>>>>>> viewport = new InvalidatedSimpleObjectProperty<>(this, >>>>>>> "viewport", (o) -> { >>>>>>> invalidateWidthHeight(); >>>>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>>>> impl_geomChanged(); >>>>>>> } ); >>>>>>> } >>>>>>> return viewport; >>>>>>> } >>>>>>> >>>>>> instead of >>>>>> >>>>>> >>>>>>> public final ObjectProperty viewportProperty() { >>>>>>> if (viewport == null) { >>>>>>> viewport = new ObjectPropertyBase() { >>>>>>> >>>>>>> @Override >>>>>>> protected void invalidated() { >>>>>>> invalidateWidthHeight(); >>>>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>>>> impl_geomChanged(); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public Object getBean() { >>>>>>> return ImageView.this; >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public String getName() { >>>>>>> return "viewport"; >>>>>>> } >>>>>>> }; >>>>>>> } >>>>>>> return viewport; >>>>>>> } >>>>>>> >>>>>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>>>>>> package com.sun.javafx.property; >>>>>>> >>>>>>> import java.util.function.Consumer; >>>>>>> >>>>>>> import javafx.beans.property.SimpleObjectProperty; >>>>>>> >>>>>>> public final class InvalidatedSimpleObjectProperty extends >>>>>>> SimpleObjectProperty { >>>>>>> private final Consumer> >>>>>>> invalidationConsumer; >>>>>>> /** >>>>>>> * The constructor of {@code ObjectProperty} >>>>>>> * >>>>>>> * @param initialValue >>>>>>> * the initial value of the wrapped value >>>>>>> * @param invalidationConsumer >>>>>>> * the consumer to be called when the bean is >>>>>>> invalidated >>>>>>> */ >>>>>>> public InvalidatedSimpleObjectProperty(T initialValue, final >>>>>>> Consumer> invalidationConsumer) { >>>>>>> super(initialValue); >>>>>>> if( invalidationConsumer == null ) { >>>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>>> null"); >>>>>>> } >>>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>>> } >>>>>>> >>>>>>> /** >>>>>>> * The constructor of {@code ObjectProperty} >>>>>>> * >>>>>>> * @param bean >>>>>>> * the bean of this {@code ObjectProperty} >>>>>>> * @param name >>>>>>> * the name of this {@code ObjectProperty} >>>>>>> * @param invalidationConsumer >>>>>>> * the consumer to be called when the bean is >>>>>>> invalidated >>>>>>> */ >>>>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>>>> name, final Consumer> >>>>>>> invalidationConsumer) { >>>>>>> super(bean, name); >>>>>>> if( invalidationConsumer == null ) { >>>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>>> null"); >>>>>>> } >>>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>>> } >>>>>>> >>>>>>> /** >>>>>>> * The constructor of {@code ObjectProperty} >>>>>>> * >>>>>>> * @param bean >>>>>>> * the bean of this {@code ObjectProperty} >>>>>>> * @param name >>>>>>> * the name of this {@code ObjectProperty} >>>>>>> * @param initialValue >>>>>>> * the initial value of the wrapped value >>>>>>> * @param invalidationConsumer >>>>>>> * the consumer to be called when the bean is >>>>>>> invalidated >>>>>>> */ >>>>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>>>> name, T initialValue, final >>>>>>> Consumer> invalidationConsumer) { >>>>>>> super(bean,name,initialValue); >>>>>>> if( invalidationConsumer == null ) { >>>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>>> null"); >>>>>>> } >>>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>>> } >>>>>>> @Override >>>>>>> protected void invalidated() { >>>>>>> invalidationConsumer.accept(this); >>>>>>> } >>>>>>> } >>>>>>> >>>>>> On 22.01.13 10:30, Richard Bair wrote: >>>>>> >>>>>>>> Is the Java8 plan still there if not should the current >>>>>>>> Simple*Property >>>>>>>> subclasses who overload invalidated be changed to PropertyBase? >>>>>>>> >>>>>>> It is unlikely that we'll be able to do anything major here in Java >>>>>>> 8 just because we don't really have Lambda yet that we can play >>>>>>> with, and changing over every property is a big job. Unless we knew >>>>>>> it would be a major win. I would say, if you encounter a Simple* >>>>>>> property that has been subclassed, then we should fix it up as we go >>>>>>> to be a PropertyBase* guy instead. >>>>>>> >>>>>>> >>> >>> > From steve.x.northover at oracle.com Mon Mar 24 22:40:25 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 24 Mar 2014 18:40:25 -0400 Subject: Using JavaFX deploy and having signing issues... In-Reply-To: References: <1395683939.13459.YahooMailNeo@web121802.mail.ne1.yahoo.com> <1395700212.98750.YahooMailNeo@web121801.mail.ne1.yahoo.com> Message-ID: <5330B459.6000206@oracle.com> Yes and we'll put them on the OpenJFX wiki. Steve On 2014-03-24 6:39 PM, Mark Fortner wrote: > Tony and/or Danno, > Would you mind documenting the steps that you had to go through to make a > Mac application that was submittable to the Apple Store? I'm sure everyone > who's struggling to create applications would appreciate the information. > > Cheers, > > Mark > > > > On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito wrote: > >> Ok I was able to codesign and submit. The JavaFX deploy task is not >> creating a info.plist when the jdk is added to the bundle for the jdk. >> >> After submission there were some issues related to signing and it now >> requires a entitlements file for some things in the jre. >> >> Regards, >> -Tony >> >> >> >> On Monday, March 24, 2014 12:01 PM, Tony Anecito >> wrote: >> >> So you have tried codesign with Mavericks OS X? I am getting invalid >> bundle when the jdk is bundled as required by the Apple Store. You have to >> codesign the jdk plugin seprately. >> Yes you can create a pkg or dmg image but I am looking for the correct way >> get the jdk codesigned else the app codesign fails also. >> >> Do you have a working example of codesign the jdk in the bundle? >> >> Thanks, >> -Tony >> >> >> >> >> On Monday, March 24, 2014 11:48 AM, Danno Ferrin >> wrote: >> >> You can still deploy apps to the app store using JavaFX. You just cannot >> use the media library at the moment. You can do it also via non app store >> distribution and sign it via gatekeeper as well and keep the media >> libraries in. And it shouldn't matter what version of Mac OSX you use to >> build it. >> >> Tony Anecito wrote: >> >> >> Thanks Richard, >> >> I know some more now. It seems with Mavericks 10.9 codesign and the bundle >> format that JavaFX deploy creates is no longer valid. There are starting to >> appear to be more references to this issue on the internet. >> So JavaFX apps can no longer be created and work on the Mac at least as >> far as the Apple Store is concerned. >> >> I may have to downgrade my Mac OS X to 10.8 to create Apple Store >> distributable JavaFX apps for the Mac. >> >> -Tony >> >> >> >> On Monday, March 24, 2014 10:57 AM, Richard Bair >> wrote: >> >>> One last hurdle, you need to remove the media library for JavaFX >> (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that >> is being disowned by apple. This may be fixed in a later 8u update, but >> not in 8.0.0_b132. >> >> Oh good grief, Apple! So what should we be using instead? This means I >> cannot make use of fx media in any app submitted to the app store? >> >> Richard >> From tom.schindl at bestsolution.at Mon Mar 24 22:43:22 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Mar 2014 23:43:22 +0100 Subject: *PropertyBase vs Simple*Property In-Reply-To: <5330B44F.8060704@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> <50EEECB5.1070302@bestsolution.at> <3B4454EA-F471-4943-963B-52D281C5A240@oracle.com> <532C98CD.4050300@bestsolution.at> <532CBA56.9060004@oracle.com> <532CBC82.8060104@oracle.com> <5330AD64.4080701@bestsolution.at> <5330B24E.1010205@oracle.com> <5330B353.5090302@bestsolution.at> <5330B44F.8060704@bestsolution.at> Message-ID: <5330B50A.7030700@bestsolution.at> Arghhh time for bed: Number is 179 vs 150 but I only ran it once so the numbers might be completely bogus! Tom On 24.03.14 23:40, Tom Schindl wrote: > Ups there was an error in my test for the last Call line so the numbers > there are: > > 38 (lambda) vs 32 (subclass) > >> package hello; >> >> import java.util.ArrayList; >> import java.util.List; >> import java.util.concurrent.atomic.AtomicInteger; >> import java.util.function.Consumer; >> >> import javafx.beans.property.ObjectProperty; >> import javafx.beans.property.ObjectPropertyBase; >> import javafx.beans.property.SimpleObjectProperty; >> >> public class TestMemory { >> private static int oneIteration = 1_000_000; >> private static int iterationCount = 10; >> private static int invokationOverheadCallCount = 1_000_000; >> >> private static boolean testLambda = false; >> >> private static void testLambda(int iterations, List storage) { >> for( int i = 0; i < iterations; i++ ) { >> storage.add(new SimpleLambdaBean()); >> } >> } >> >> private static void testSubclass(int iterations, List storage) { >> for( int i = 0; i < iterations; i++ ) { >> storage.add(new SimpleSubclassBean()); >> } >> } >> >> public static void main(String[] args) { >> System.err.println("Test Creation time"); >> System.err.println("=================="); >> >> { >> long timeDiffTotal = 0; >> for( int i = 0; i < iterationCount; i++ ) { >> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >> System.err.println(" ---------------------------------"); >> long s = System.currentTimeMillis(); >> if( testLambda ) { >> testLambda(oneIteration, new ArrayList<>()); >> } else { >> testSubclass(oneIteration, new ArrayList<>()); >> } >> long e = System.currentTimeMillis(); >> long diff = e - s; >> >> timeDiffTotal+=diff; >> System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); >> >> System.err.println(" ---------------------------------"); >> } >> >> System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); >> } >> >> List target = new ArrayList(iterationCount * oneIteration); >> >> { >> System.err.println(""); >> System.err.println("Test Creation memory"); >> System.err.println("=================="); >> >> for( int i = 0; i < iterationCount; i++ ) { >> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >> System.err.println(" ---------------------------------"); >> if( testLambda ) { >> testLambda(oneIteration, target); >> } else { >> testSubclass(oneIteration, target); >> } >> >> long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); >> System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); >> System.err.println(" ---------------------------------"); >> } >> >> System.err.println(" Total objects created: " + target.size()); >> } >> >> { >> System.err.println(""); >> System.err.println("Test invokation overhead (all then times)"); >> System.err.println("========================================="); >> >> long s = System.currentTimeMillis(); >> for( int i = 0; i < oneIteration; i++ ) { >> target.get(i).invalidate(); >> } >> long e = System.currentTimeMillis(); >> long diff = e - s; >> System.err.println(" Total time calls: " + diff); >> System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); >> } >> >> { >> System.err.println(""); >> System.err.println("Test invokation multiple times"); >> System.err.println("==============================="); >> long s = System.currentTimeMillis(); >> TestObject o = target.get(0); >> for( int i = 0; i < invokationOverheadCallCount; i++ ) { >> o.invalidate(); >> } >> long e = System.currentTimeMillis(); >> long diff = e - s; >> System.err.println(" Total time calls: " + diff); >> System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); >> } >> >> } >> >> public static class LamdaInvalidationProperty extends SimpleObjectProperty { >> private Consumer> c; >> >> public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { >> super(bean, name); >> this.c = c; >> } >> >> @Override >> protected void invalidated() { >> c.accept(this); >> } >> } >> >> public interface TestObject { >> public void invalidate(); >> } >> >> public static class SimpleLambdaBean implements TestObject { >> private AtomicInteger i = new AtomicInteger(); >> >> private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { >> i.incrementAndGet(); >> }); >> >> public void invalidate() { >> sample.setValue(new Object()); >> } >> } >> >> public static class SimpleSubclassBean implements TestObject { >> private AtomicInteger i = new AtomicInteger(); >> >> private ObjectProperty sample = new ObjectPropertyBase() { >> @Override >> public Object getBean() { >> return SimpleSubclassBean.this; >> } >> >> public String getName() { >> return "sample"; >> } >> >> public Object getValue() { >> return null; >> } >> >> protected void invalidated() { >> i.incrementAndGet(); >> } >> }; >> >> public void invalidate() { >> sample.setValue(new Object()); >> } >> } >> >> } > > > On 24.03.14 23:36, Tom Schindl wrote: >> The code I run is attached in the mail copy it to your env and run it >> and flip the testLambda from true to false. >> >> I might have been something dumb wrong but this is what I came up with. >> >> Tom >> >> On 24.03.14 23:31, Kevin Rushforth wrote: >>> Those results are surprising. Is this an apples-to-apples comparison >>> with the only difference being a Lambda versus an equivalent anonymous >>> inner class? >>> >>> -- Kevin >>> >>> >>> Tom Schindl wrote: >>>> Hi, >>>> >>>> I've written a small sample to see what it gets me to check: >>>> * creation overhead >>>> * memory overhead >>>> * call overhead >>>> >>>> I'm not very good at this kind of thing so someone who knows to write >>>> benchmarks might know a lot better - need to check out JMH most likely. >>>> >>>> Anyways here are the numbers: >>>> >>>> Topic Lambda Subclass >>>> -------------------------------------------------------------- >>>> Create10M 372ms (0.00003723) 220ms (0.00002205) >>>> Mem 108byte / instance 84byte / instance >>>> Call-1M*10 42ms (0.0000042) 35ms (0.0000035) >>>> Call-1*1M 11ms (0.0000011) 10ms (0.0000010) >>>> >>>> So Lamda is considerable slower 40% and takes 20% more space, call >>>> behavior is fairly the same. I'll try to learn about JMH. >>>> >>>> Tom >>>> >>>> >>>> >>>>> package hello; >>>>> >>>>> import java.util.ArrayList; >>>>> import java.util.List; >>>>> import java.util.concurrent.atomic.AtomicInteger; >>>>> import java.util.function.Consumer; >>>>> >>>>> import javafx.beans.property.ObjectProperty; >>>>> import javafx.beans.property.ObjectPropertyBase; >>>>> import javafx.beans.property.SimpleObjectProperty; >>>>> >>>>> public class TestMemory { >>>>> private static int oneIteration = 1_000_000; >>>>> private static int iterationCount = 10; >>>>> private static int invokationOverheadCallCount = 1_000_000; >>>>> >>>>> private static boolean testLambda = false; >>>>> >>>>> private static void testLambda(int iterations, List storage) { >>>>> for( int i = 0; i < iterations; i++ ) { >>>>> storage.add(new SimpleLambdaBean()); >>>>> } >>>>> } >>>>> >>>>> private static void testSubclass(int iterations, List storage) { >>>>> for( int i = 0; i < iterations; i++ ) { >>>>> storage.add(new SimpleSubclassBean()); >>>>> } >>>>> } >>>>> >>>>> public static void main(String[] args) { >>>>> System.err.println("Test Creation time"); >>>>> System.err.println("=================="); >>>>> >>>>> { >>>>> long timeDiffTotal = 0; >>>>> for( int i = 0; i < iterationCount; i++ ) { >>>>> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >>>>> System.err.println(" ---------------------------------"); >>>>> long s = System.currentTimeMillis(); >>>>> if( testLambda ) { >>>>> testLambda(oneIteration, new ArrayList<>()); >>>>> } else { >>>>> testSubclass(oneIteration, new ArrayList<>()); >>>>> } >>>>> long e = System.currentTimeMillis(); >>>>> long diff = e - s; >>>>> >>>>> timeDiffTotal+=diff; >>>>> System.err.println(" Creation time: " + diff + "("+diff * 1.0 / oneIteration+")"); >>>>> >>>>> System.err.println(" ---------------------------------"); >>>>> } >>>>> >>>>> System.err.println(" Average time: " + timeDiffTotal * 1.0 / (iterationCount * oneIteration)); >>>>> } >>>>> >>>>> List target = new ArrayList(iterationCount * oneIteration); >>>>> >>>>> { >>>>> System.err.println(""); >>>>> System.err.println("Test Creation memory"); >>>>> System.err.println("=================="); >>>>> >>>>> for( int i = 0; i < iterationCount; i++ ) { >>>>> System.err.println(" Working for objects: " + (i * oneIteration) + " - " + ((i+1) * oneIteration) ); >>>>> System.err.println(" ---------------------------------"); >>>>> if( testLambda ) { >>>>> testLambda(oneIteration, target); >>>>> } else { >>>>> testSubclass(oneIteration, target); >>>>> } >>>>> >>>>> long freeDiff = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); >>>>> System.err.println(" Memory: " + freeDiff + "("+freeDiff * 1.0 / target.size()+")"); >>>>> System.err.println(" ---------------------------------"); >>>>> } >>>>> >>>>> System.err.println(" Total objects created: " + target.size()); >>>>> } >>>>> >>>>> { >>>>> System.err.println(""); >>>>> System.err.println("Test invokation overhead (all then times)"); >>>>> System.err.println("========================================="); >>>>> >>>>> long s = System.currentTimeMillis(); >>>>> for( int i = 0; i < oneIteration; i++ ) { >>>>> target.get(i).invalidate(); >>>>> } >>>>> long e = System.currentTimeMillis(); >>>>> long diff = e - s; >>>>> System.err.println(" Total time calls: " + diff); >>>>> System.err.println(" Time per call: " + diff * 1.0 / invokationOverheadCallCount); >>>>> } >>>>> >>>>> { >>>>> System.err.println(""); >>>>> System.err.println("Test invokation multiple times"); >>>>> System.err.println("==============================="); >>>>> long s = System.currentTimeMillis(); >>>>> >>>>> for( int i = 0; i < invokationOverheadCallCount; i++ ) { >>>>> >>>>> } >>>>> long e = System.currentTimeMillis(); >>>>> long diff = e - s; >>>>> System.err.println(" Total time calls: " + diff); >>>>> System.err.println(" Time per call calls: " + diff * 1.0 / invokationOverheadCallCount); >>>>> } >>>>> >>>>> } >>>>> >>>>> public static class LamdaInvalidationProperty extends SimpleObjectProperty { >>>>> private Consumer> c; >>>>> >>>>> public LamdaInvalidationProperty(Object bean, String name, Consumer> c) { >>>>> super(bean, name); >>>>> this.c = c; >>>>> } >>>>> >>>>> @Override >>>>> protected void invalidated() { >>>>> c.accept(this); >>>>> } >>>>> } >>>>> >>>>> public interface TestObject { >>>>> public void invalidate(); >>>>> } >>>>> >>>>> public static class SimpleLambdaBean implements TestObject { >>>>> private AtomicInteger i = new AtomicInteger(); >>>>> >>>>> private ObjectProperty sample = new LamdaInvalidationProperty<>(this, "sample", (e) -> { >>>>> i.incrementAndGet(); >>>>> }); >>>>> >>>>> public void invalidate() { >>>>> sample.setValue(new Object()); >>>>> } >>>>> } >>>>> >>>>> public static class SimpleSubclassBean implements TestObject { >>>>> private AtomicInteger i = new AtomicInteger(); >>>>> >>>>> private ObjectProperty sample = new ObjectPropertyBase() { >>>>> @Override >>>>> public Object getBean() { >>>>> return SimpleSubclassBean.this; >>>>> } >>>>> >>>>> public String getName() { >>>>> return "sample"; >>>>> } >>>>> >>>>> public Object getValue() { >>>>> return null; >>>>> } >>>>> >>>>> protected void invalidated() { >>>>> i.incrementAndGet(); >>>>> } >>>>> }; >>>>> >>>>> public void invalidate() { >>>>> sample.setValue(new Object()); >>>>> } >>>>> } >>>>> >>>>> } >>>>> >>>> >>>> >>>> On 21.03.14 23:26, Kevin Rushforth wrote: >>>> >>>>> It does seem promising. We'll also need data to show the trade-offs to >>>>> help inform whether it is worth making such a massive change. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Stephen F Northover wrote: >>>>> >>>>>> This looks good. I wonder if we should make this (massive) change >>>>>> before we lambda graphics and controls? Probably doesn't matter. >>>>>> We'll need a JIRA and someone assigned to it in order to track the work. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 2014-03-21 12:53 PM, Tom Schindl wrote: >>>>>> >>>>>>> Hi Richard, >>>>>>> >>>>>>> Coming back to this old thread and now that we are using lamdas all over >>>>>>> I guess we could take one more look into that. >>>>>>> >>>>>>> I've prototyped an initial version by introducing a new internal type >>>>>>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see >>>>>>> code pasted below. >>>>>>> >>>>>>> And now one can write code like this: >>>>>>> >>>>>>> >>>>>>>> public final ObjectProperty viewportProperty() { >>>>>>>> if (viewport == null) { >>>>>>>> viewport = new InvalidatedSimpleObjectProperty<>(this, >>>>>>>> "viewport", (o) -> { >>>>>>>> invalidateWidthHeight(); >>>>>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>>>>> impl_geomChanged(); >>>>>>>> } ); >>>>>>>> } >>>>>>>> return viewport; >>>>>>>> } >>>>>>>> >>>>>>> instead of >>>>>>> >>>>>>> >>>>>>>> public final ObjectProperty viewportProperty() { >>>>>>>> if (viewport == null) { >>>>>>>> viewport = new ObjectPropertyBase() { >>>>>>>> >>>>>>>> @Override >>>>>>>> protected void invalidated() { >>>>>>>> invalidateWidthHeight(); >>>>>>>> impl_markDirty(DirtyBits.NODE_VIEWPORT); >>>>>>>> impl_geomChanged(); >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public Object getBean() { >>>>>>>> return ImageView.this; >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public String getName() { >>>>>>>> return "viewport"; >>>>>>>> } >>>>>>>> }; >>>>>>>> } >>>>>>>> return viewport; >>>>>>>> } >>>>>>>> >>>>>>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> >>>>>>>> package com.sun.javafx.property; >>>>>>>> >>>>>>>> import java.util.function.Consumer; >>>>>>>> >>>>>>>> import javafx.beans.property.SimpleObjectProperty; >>>>>>>> >>>>>>>> public final class InvalidatedSimpleObjectProperty extends >>>>>>>> SimpleObjectProperty { >>>>>>>> private final Consumer> >>>>>>>> invalidationConsumer; >>>>>>>> /** >>>>>>>> * The constructor of {@code ObjectProperty} >>>>>>>> * >>>>>>>> * @param initialValue >>>>>>>> * the initial value of the wrapped value >>>>>>>> * @param invalidationConsumer >>>>>>>> * the consumer to be called when the bean is >>>>>>>> invalidated >>>>>>>> */ >>>>>>>> public InvalidatedSimpleObjectProperty(T initialValue, final >>>>>>>> Consumer> invalidationConsumer) { >>>>>>>> super(initialValue); >>>>>>>> if( invalidationConsumer == null ) { >>>>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>>>> null"); >>>>>>>> } >>>>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>>>> } >>>>>>>> >>>>>>>> /** >>>>>>>> * The constructor of {@code ObjectProperty} >>>>>>>> * >>>>>>>> * @param bean >>>>>>>> * the bean of this {@code ObjectProperty} >>>>>>>> * @param name >>>>>>>> * the name of this {@code ObjectProperty} >>>>>>>> * @param invalidationConsumer >>>>>>>> * the consumer to be called when the bean is >>>>>>>> invalidated >>>>>>>> */ >>>>>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>>>>> name, final Consumer> >>>>>>>> invalidationConsumer) { >>>>>>>> super(bean, name); >>>>>>>> if( invalidationConsumer == null ) { >>>>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>>>> null"); >>>>>>>> } >>>>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>>>> } >>>>>>>> >>>>>>>> /** >>>>>>>> * The constructor of {@code ObjectProperty} >>>>>>>> * >>>>>>>> * @param bean >>>>>>>> * the bean of this {@code ObjectProperty} >>>>>>>> * @param name >>>>>>>> * the name of this {@code ObjectProperty} >>>>>>>> * @param initialValue >>>>>>>> * the initial value of the wrapped value >>>>>>>> * @param invalidationConsumer >>>>>>>> * the consumer to be called when the bean is >>>>>>>> invalidated >>>>>>>> */ >>>>>>>> public InvalidatedSimpleObjectProperty(Object bean, String >>>>>>>> name, T initialValue, final >>>>>>>> Consumer> invalidationConsumer) { >>>>>>>> super(bean,name,initialValue); >>>>>>>> if( invalidationConsumer == null ) { >>>>>>>> throw new IllegalArgumentException("Consumer can not be >>>>>>>> null"); >>>>>>>> } >>>>>>>> this.invalidationConsumer = invalidationConsumer; >>>>>>>> } >>>>>>>> @Override >>>>>>>> protected void invalidated() { >>>>>>>> invalidationConsumer.accept(this); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>> On 22.01.13 10:30, Richard Bair wrote: >>>>>>> >>>>>>>>> Is the Java8 plan still there if not should the current >>>>>>>>> Simple*Property >>>>>>>>> subclasses who overload invalidated be changed to PropertyBase? >>>>>>>>> >>>>>>>> It is unlikely that we'll be able to do anything major here in Java >>>>>>>> 8 just because we don't really have Lambda yet that we can play >>>>>>>> with, and changing over every property is a big job. Unless we knew >>>>>>>> it would be a major win. I would say, if you encounter a Simple* >>>>>>>> property that has been subclassed, then we should fix it up as we go >>>>>>>> to be a PropertyBase* guy instead. >>>>>>>> >>>>>>>> >>>> >>>> >> > From hang.vo at oracle.com Tue Mar 25 01:17:33 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 01:17:33 +0000 Subject: hg: openjfx/8u-dev/rt: RT-32460: TextArea: Wrong behavior of CTRL-DOWN on Windows Message-ID: <201403250117.s2P1HjlH013852@aojmv0008> Changeset: e08cbee88d7d Author: leifs Date: 2014-03-24 18:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e08cbee88d7d RT-32460: TextArea: Wrong behavior of CTRL-DOWN on Windows ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java From adanecito at yahoo.com Tue Mar 25 01:37:56 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Mon, 24 Mar 2014 18:37:56 -0700 (PDT) Subject: Using JavaFX deploy and having signing issues... In-Reply-To: <5330B459.6000206@oracle.com> References: <1395683939.13459.YahooMailNeo@web121802.mail.ne1.yahoo.com> <1395700212.98750.YahooMailNeo@web121801.mail.ne1.yahoo.com> <5330B459.6000206@oracle.com> Message-ID: <1395711476.28005.YahooMailNeo@web121804.mail.ne1.yahoo.com> I have already started doing that since the info I found on the web does not mention some of the issues I am running into. ? -Tony On Monday, March 24, 2014 4:40 PM, Stephen F Northover wrote: Yes and we'll put them on the OpenJFX wiki. Steve On 2014-03-24 6:39 PM, Mark Fortner wrote: > Tony and/or Danno, > Would you mind documenting the steps that you had to go through to make a > Mac application that was submittable to the Apple Store?? I'm sure everyone > who's struggling to create applications would appreciate the information. > > Cheers, > > Mark > > > > On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito wrote: > >> Ok I was able to codesign and submit. The JavaFX deploy task is not >> creating a info.plist when the jdk is added to the bundle for the jdk. >> >> After submission there were some issues related to signing and it now >> requires a entitlements file for some things in the jre. >> >> Regards, >> -Tony >> >> >> >> On Monday, March 24, 2014 12:01 PM, Tony Anecito >> wrote: >> >> So you have tried codesign with Mavericks OS X? I am getting invalid >> bundle when the jdk is bundled as required by the Apple Store. You have to >> codesign the jdk plugin seprately. >> Yes you can create a pkg or dmg image but I am looking for the correct way >> get the jdk codesigned else the app codesign fails also. >> >> Do you have a working example of codesign the jdk in the bundle? >> >> Thanks, >> -Tony >> >> >> >> >> On Monday, March 24, 2014 11:48 AM, Danno Ferrin >> wrote: >> >> You can still deploy apps to the app store using JavaFX.? You just cannot >> use the media library at the moment.? You can do it also via non app store >> distribution and sign it via gatekeeper as well and keep the media >> libraries in.? And it shouldn't matter what version of Mac OSX you use to >> build it. >> >> Tony Anecito wrote: >> >> >> Thanks Richard, >> >> I know some more now. It seems with Mavericks 10.9 codesign and the bundle >> format that JavaFX deploy creates is no longer valid. There are starting to >> appear to be more references to this issue on the internet. >> So JavaFX apps can no longer be created and work on the Mac at least as >> far as the Apple Store is concerned. >> >> I may have to downgrade my Mac OS X to 10.8 to create Apple Store >> distributable JavaFX apps for the Mac. >> >> -Tony >> >> >> >> On Monday, March 24, 2014 10:57 AM, Richard Bair >> wrote: >> >>> One last hurdle, you need to remove the media library for JavaFX >> (lib/libjfxmedia.dylib) from your bundled JDK.? It uses QuickTime and that >> is being disowned by apple.? This may be fixed in a later 8u update, but >> not in 8.0.0_b132. >> >> Oh good grief, Apple! So what should we be using instead? This means I >> cannot make use of fx media in any app submitted to the app store? >> >> Richard >> From hang.vo at oracle.com Tue Mar 25 02:47:41 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 02:47:41 +0000 Subject: hg: openjfx/8u-dev/rt: 4 new changesets Message-ID: <201403250248.s2P2mBZI028087@aojmv0008> Changeset: d21a135c84d5 Author: jgiles Date: 2014-03-25 10:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d21a135c84d5 RT-36334: Clean up warnings in control component Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/Separator.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java Changeset: f1e1491949bb Author: jgiles Date: 2014-03-25 11:25 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f1e1491949bb [Accessibility] Standardise controls files wrt accessibility code layout and positioning. ! modules/controls/src/main/java/javafx/scene/control/Accordion.java ! modules/controls/src/main/java/javafx/scene/control/Button.java ! modules/controls/src/main/java/javafx/scene/control/ButtonBase.java ! modules/controls/src/main/java/javafx/scene/control/CheckBox.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/controls/src/main/java/javafx/scene/control/Hyperlink.java ! modules/controls/src/main/java/javafx/scene/control/Label.java ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/Pagination.java ! modules/controls/src/main/java/javafx/scene/control/PasswordField.java ! modules/controls/src/main/java/javafx/scene/control/ProgressBar.java ! modules/controls/src/main/java/javafx/scene/control/ProgressIndicator.java ! modules/controls/src/main/java/javafx/scene/control/RadioButton.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/TabPane.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TextArea.java ! modules/controls/src/main/java/javafx/scene/control/TextField.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java ! modules/controls/src/main/java/javafx/scene/control/ToggleButton.java ! modules/controls/src/main/java/javafx/scene/control/ToolBar.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java Changeset: fd6893fc1047 Author: jgiles Date: 2014-03-25 11:28 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fd6893fc1047 [IntelliJ only] Don't include inspection profiles in rt repo. ! .hgignore Changeset: c61f0f745e0d Author: jgiles Date: 2014-03-25 15:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c61f0f745e0d RT-36280: ComboBox's popup cannot be closed with ENTER ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java From hang.vo at oracle.com Tue Mar 25 06:47:39 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 06:47:39 +0000 Subject: hg: openjfx/8u-dev/rt: RT-34667: Mac: PickTest3D appears washed out Message-ID: <201403250647.s2P6loTo002240@aojmv0008> Changeset: e530f77a64a4 Author: vadim Date: 2014-03-25 10:34 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e530f77a64a4 RT-34667: Mac: PickTest3D appears washed out Reviewed-by: anthony, kcr Summary: synchronize CAOpenGLLayer opacity with NSWindow opacity ! modules/graphics/src/main/native-glass/mac/GlassWindow.m From hang.vo at oracle.com Tue Mar 25 09:17:52 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 09:17:52 +0000 Subject: hg: openjfx/8u-dev/rt: 2 new changesets Message-ID: <201403250918.s2P9IBTD024740@aojmv0008> Changeset: 7d3f955a9729 Author: Martin Sladecek Date: 2014-03-25 10:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7d3f955a9729 RT-36166 [Layout] ListCell and FlowPane, minHeight issue Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListCellSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: baf51881af79 Author: Martin Sladecek Date: 2014-03-25 10:14 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/baf51881af79 Fixed accidental typo done just prior to RT-36166 commit (7d3f955a9729) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Tue Mar 25 10:17:36 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 10:17:36 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36238 [Ensemble8] SwingInterop throws IllegalStateException: Not on FX application thread Message-ID: <201403251017.s2PAHlGj006008@aojmv0008> Changeset: c037c7fb6786 Author: Martin Sladecek Date: 2014-03-25 11:05 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c037c7fb6786 RT-36238 [Ensemble8] SwingInterop throws IllegalStateException: Not on FX application thread - apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/ProcessListener.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInteropApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInteropService.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInteropTask.java From kirill.kirichenko at oracle.com Tue Mar 25 11:00:49 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Tue, 25 Mar 2014 15:00:49 +0400 Subject: Adding GStreamer plugins In-Reply-To: References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> Message-ID: <533161E1.7050602@oracle.com> Hi Michael. See my comments inline. On 24.03.2014 04:31, Michael Berry wrote: > I'm now a bit further along with this, though struggling to get the > matroska plugin to compile (getting a bunch of unresolved external symbol > errors for functions it uses in glib - not entirely sure why at the moment, > as I said C is not my strong point.) I've also noticed the plugins > currently bundled have quite a few changes to the gstreamer version, and I > can't quite work out the logic behind why things have been changed the way > they have - so even after the compilation issue is resolved I'm now less > confident that it will just drop in and work! Again, if someone > knowledgeable in this area that's lurking in the shadows could shed any > light on any of this, it would be hugely appreciated. We did some changes in existing GStreamer code because it had errors and because we needed to expand some functionality. The changes are not very extensive. > However, putting the current problems aside for a bit, the snags I hit up > until this point could I think be relatively easily addressed in the > documentation. With that in mind could I suggest a few additional points > for the wiki? These may be obvious to the majority reading here, but as > someone completely new to building JFX they had me stumped for a while! I can give you some directions. There is no wiki. I'd appreciate if you created one. > - It turns out that the Gstreamer stuff doesn't compile at all by default, > which is why I wasn't seeing any changes on the native level. To ensure > GStreamer is actually compiled, you need to copy the > gradle.properties.template file to gradle.properties, and uncomment the > "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist for > any webkit alterations as per the line above.) You don't need to comment/uncomment anything. Just add -PCOMPILE_MEDIA=true to the gradle command line. You can however change the properties file too. > - As well as the requirements listed, I needed the Windows SDK ( > http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for > GStreamer to compile successfully under Windows (7) - without it cygpath > just threw a rather confusing error. You need windows 7.1a SDK and speaking precisely you need only samples from it because samples have BaseClasses at Samples/multimedia/directshow/baseclasses. BaseClasses are used for Oracle direchshowwrapper plugin. > - The developer workflow page ( > https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers > to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" instead? What are you gonna use it for ? > I'm happy to make the above changes myself but unsure of if / where you can > sign up for an account, so I'm just throwing them here for now - if anyone > could point me to the right place then that'd be great! Steve. Can you give an advice ? > If I do ever manage to get this working (ha-ha) I'd also like to throw up a > wiki page just detailing how to grab a gstreamer plugin and make the > necessary changes to it to compile it into openjfx as a stop gap to then > perhaps working on one or both of the above JIRA issues and seeing where I > get - does this sound reasonable? It does. >>> On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >>>> However, I'm not sure if I'm going about including the matroska plugin >>> in >>>> the right way - I've currently done the following: >>>> >>>> - Downloaded the latest version of the plugins from here ( >>>> http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the >>>> matroska one to the modules/media/src/main/native/gstreamer/plugins/ >>>> folder, as well as the >>>> >>> modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ >>>> folder (I'm unsure of this - should I add it to both these folders?). Well you see. If you download the latest matroska plugin it potentially can have dependencies on the latest GStreamer platform. We don't have/use the latest gstreamer. The version we use is 0.10.35. And the latest available is 1.x. They are incompatible in some methods. >>>> - Added all the C files from the first folder mentioned above to the >>>> plugins.vcxproj file >>>> >>>> - Added the relevant files and directory to Makefile.gstplugins >>>> >>>> - Called the additional relevant plugin_init() function in >>>> gstplugins-lite.c There is one more thing you need to do here for Windows only apart from running gradle with -PCOMPILE_MEDIA=true. Windows build system has files that export symbols 1) from glib-lite.dll ${jfxroot}/rt/modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.28.8/build/win32/vs100/{glib-lite.def|glib-liteD.def} Here the version with "D" is used for debug build and may contain more symbols for export. 2) from gstreamer-lite.dll ${jfxroot}/rt/modules/media/src/main/native/gstreamer/projects/win/gstreamer-lite.def - used for both Release and Debug. If your plugin uses some methods of gstreamer/glib libraries not mentioned in the files you should add the methods to the files. Syntax is pretty simple. If you don't add depending methods to these files you will get linker errors. C/C++ compiler will not generate errors. Actually I think the best way to start developing/improving the Media component is to upgrade GStreamer to 1.x from 0.10.35. It would be a very good starting point and you would get less or no problems using the latest available plugins. If someone wanna take over this I can explain in details how to do it. K From mjrb5 at kent.ac.uk Tue Mar 25 13:21:15 2014 From: mjrb5 at kent.ac.uk (Michael Berry) Date: Tue, 25 Mar 2014 13:21:15 +0000 Subject: Adding GStreamer plugins In-Reply-To: <533161E1.7050602@oracle.com> References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> <533161E1.7050602@oracle.com> Message-ID: Hi Kirill, Many thanks for the detailed response, that's incredibly helpful. I had noted already that you were using gstreamer 0.10.35 from downloading the gstreamer modifications for JFX8 from Oracle's site, so was using the appropriate version of the plugin already to try to ensure no compatibility issues arose. It seems the issue that I was having was indeed to do with the step you outlined; I was getting unresolved external linker issues because it couldn't find the functions I hadn't added. However, while the linker errors associated with all the glib functions have now been resolved through adding the methods (to both glib-lite.def and glib-liteD.def), adding the relevant functions to gstreamer-lite.def complains about an unresolved external symbol in the def file: gstreamer-lite.def : error LNK2001: unresolved external symbol gst_byte_writer_free gstreamer-lite.def : error LNK2001: unresolved external symbol gst_byte_writer_free_and_get_buffer gstreamer-lite.def : error LNK2001: unresolved external symbol gst_byte_writer_new_with_size When they're not in the def file, I get the following linker errors instead: libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external symbol _gst_byte_writer_free referenced in function _gst_ebml_write_finalize libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external symbol _gst_byte_writer_new_with_size referenced in function _gst_ebml_start_streamheader libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external symbol _gst_byte_writer_free_and_get_bufferreferenced in function _gst_ebml_stop_streamheader I've added these to the gstreamer-lite.def file in exactly the same way as I added the glib functions to the glib files - any idea what I might have missed? gst_byte_writer_free_and_get_buffer @184 NONAME gst_byte_writer_free @185 NONAME gst_byte_writer_new_with_size @186 NONAME (I'm assuming NONAME is always there, and the number is sequential.) The functions are in gstbytewriter.h which is there, though perhaps I need to make the linker aware of that file specifically if it's not used anywhere else? (I'm just guessing here though.) Happy to look at upgrading gstreamer to the latest version as a next task, so I'd be more than willing to give that a go. Though I would quite like to get the matroska plugin working first - just so I've got some experience at building in a working plugin, and have some end result from what I'm trying to achieve here! Many thanks, Michael On 25 March 2014 11:00, Kirill Kirichenko wrote: > Hi Michael. > See my comments inline. > > > On 24.03.2014 04:31, Michael Berry wrote: > >> I'm now a bit further along with this, though struggling to get the >> matroska plugin to compile (getting a bunch of unresolved external symbol >> errors for functions it uses in glib - not entirely sure why at the >> moment, >> as I said C is not my strong point.) I've also noticed the plugins >> currently bundled have quite a few changes to the gstreamer version, and I >> can't quite work out the logic behind why things have been changed the way >> they have - so even after the compilation issue is resolved I'm now less >> confident that it will just drop in and work! Again, if someone >> knowledgeable in this area that's lurking in the shadows could shed any >> light on any of this, it would be hugely appreciated. >> > We did some changes in existing GStreamer code because it had errors and > because we needed to expand some functionality. The changes are not very > extensive. > > > However, putting the current problems aside for a bit, the snags I hit up >> until this point could I think be relatively easily addressed in the >> documentation. With that in mind could I suggest a few additional points >> for the wiki? These may be obvious to the majority reading here, but as >> someone completely new to building JFX they had me stumped for a while! >> > I can give you some directions. There is no wiki. I'd appreciate if you > created one. > > > - It turns out that the Gstreamer stuff doesn't compile at all by >> default, >> which is why I wasn't seeing any changes on the native level. To ensure >> GStreamer is actually compiled, you need to copy the >> gradle.properties.template file to gradle.properties, and uncomment the >> "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist >> for >> any webkit alterations as per the line above.) >> > You don't need to comment/uncomment anything. Just add > -PCOMPILE_MEDIA=true to the gradle command line. You can however change the > properties file too. > > > - As well as the requirements listed, I needed the Windows SDK ( >> http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed >> for >> GStreamer to compile successfully under Windows (7) - without it cygpath >> just threw a rather confusing error. >> > You need windows 7.1a SDK and speaking precisely you need only samples > from it because samples have BaseClasses at Samples/multimedia/directshow/baseclasses. > BaseClasses are used for Oracle direchshowwrapper plugin. > > > - The developer workflow page ( >> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers >> to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" >> instead? >> > What are you gonna use it for ? > > > I'm happy to make the above changes myself but unsure of if / where you >> can >> sign up for an account, so I'm just throwing them here for now - if anyone >> could point me to the right place then that'd be great! >> > Steve. Can you give an advice ? > > > If I do ever manage to get this working (ha-ha) I'd also like to throw up >> a >> wiki page just detailing how to grab a gstreamer plugin and make the >> necessary changes to it to compile it into openjfx as a stop gap to then >> perhaps working on one or both of the above JIRA issues and seeing where I >> get - does this sound reasonable? >> > It does. > > > On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >>>> >>>>> However, I'm not sure if I'm going about including the matroska plugin >>>>> >>>> in >>>> >>>>> the right way - I've currently done the following: >>>>> >>>>> - Downloaded the latest version of the plugins from here ( >>>>> http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added >>>>> the >>>>> matroska one to the modules/media/src/main/native/gstreamer/plugins/ >>>>> folder, as well as the >>>>> >>>>> modules/media/src/main/native/gstreamer/gstreamer-lite/gst- >>>> plugins-good/gst/ >>>> >>>>> folder (I'm unsure of this - should I add it to both these folders?). >>>>> >>>> Well you see. If you download the latest matroska plugin it potentially > can have dependencies on the latest GStreamer platform. We don't have/use > the latest gstreamer. The version we use is 0.10.35. And the latest > available is 1.x. They are incompatible in some methods. > > > - Added all the C files from the first folder mentioned above to the >>>>> plugins.vcxproj file >>>>> >>>>> - Added the relevant files and directory to Makefile.gstplugins >>>>> >>>>> - Called the additional relevant plugin_init() function in >>>>> gstplugins-lite.c >>>>> >>>> There is one more thing you need to do here for Windows only apart from > running gradle with -PCOMPILE_MEDIA=true. Windows build system has files > that export symbols > 1) from glib-lite.dll ${jfxroot}/rt/modules/media/ > src/main/native/gstreamer/3rd_party/glib/glib-2.28.8/build/ > win32/vs100/{glib-lite.def|glib-liteD.def} > Here the version with "D" is used for debug build and may contain more > symbols for export. > 2) from gstreamer-lite.dll ${jfxroot}/rt/modules/media/ > src/main/native/gstreamer/projects/win/gstreamer-lite.def - used for both > Release and Debug. > > If your plugin uses some methods of gstreamer/glib libraries not mentioned > in the files you should add the methods to the files. Syntax is pretty > simple. If you don't add depending methods to these files you will get > linker errors. C/C++ compiler will not generate errors. > > Actually I think the best way to start developing/improving the Media > component is to upgrade GStreamer to 1.x from 0.10.35. It would be a very > good starting point and you would get less or no problems using the latest > available plugins. If someone wanna take over this I can explain in details > how to do it. > > K > From adanecito at yahoo.com Tue Mar 25 13:26:24 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Tue, 25 Mar 2014 06:26:24 -0700 (PDT) Subject: Is Quicktime API calls inside JavaFX? Message-ID: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> Hi All, Is JavaFX using Apple Quicktime for video support? Thanks, -Tony From kirill.kirichenko at oracle.com Tue Mar 25 13:32:01 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Tue, 25 Mar 2014 17:32:01 +0400 Subject: Adding GStreamer plugins In-Reply-To: References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> <533161E1.7050602@oracle.com> Message-ID: <53318551.4080803@oracle.com> On 25.03.2014 17:21, Michael Berry wrote: > It seems the issue that I was having was indeed to do with the step you > outlined; I was getting unresolved external linker issues because it > couldn't find the functions I hadn't added. However, while the linker > errors associated with all the glib functions have now been resolved > through adding the methods (to both glib-lite.def and glib-liteD.def), > adding the relevant functions to gstreamer-lite.def complains about an > unresolved external symbol in the def file: > > gstreamer-lite.def : error LNK2001: unresolved external symbol > gst_byte_writer_free > gstreamer-lite.def : error LNK2001: unresolved external symbol > gst_byte_writer_free_and_get_buffer > gstreamer-lite.def : error LNK2001: unresolved external symbol > gst_byte_writer_new_with_size > > When they're not in the def file, I get the following linker errors instead: > > libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external > symbol _gst_byte_writer_free referenced in function _gst_ebml_write_finalize > libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external > symbol _gst_byte_writer_new_with_size referenced in function > _gst_ebml_start_streamheader > libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external > symbol _gst_byte_writer_free_and_get_bufferreferenced in function > _gst_ebml_stop_streamheader > > I've added these to the gstreamer-lite.def file in exactly the same way > as I added the glib functions to the glib files - any idea what I might > have missed? > > gst_byte_writer_free_and_get_buffer at 184NONAME > gst_byte_writer_free at 185NONAME > gst_byte_writer_new_with_size at 186NONAME This is not necessary that you should add all methods to the def file. Here first you should look for where the symbols are implemented and you possibly miss this file from from makefile. Take all symbols that linker shows to you, strip leading underscore character, and find them in the vanilla glib. It's possible that we did not include the file where they are implemented to the sources. In short: look where gst_byte_writer_free, gst_byte_writer_new_with_size and gst_byte_writer_free_and_get_bufferreferenced are implemented and make sure this file is compiled. > > (I'm assuming NONAME is always there, and the number is sequential.) The > functions are in gstbytewriter.h which is there, though perhaps I need > to make the linker aware of that file specifically if it's not used > anywhere else? (I'm just guessing here though.) NONAME is always there and the number is sequential. Also make sure use TABS between the columns. As far as I remember TABS are used, but do double check it. > > Happy to look at upgrading gstreamer to the latest version as a next > task, so I'd be more than willing to give that a go. Though I would > quite like to get the matroska plugin working first - just so I've got > some experience at building in a working plugin, and have some end > result from what I'm trying to achieve here! OK. > > Many thanks, > > Michael > > > On 25 March 2014 11:00, Kirill Kirichenko > wrote: > > Hi Michael. > See my comments inline. > > > On 24.03.2014 04:31, Michael Berry wrote: > > I'm now a bit further along with this, though struggling to get the > matroska plugin to compile (getting a bunch of unresolved > external symbol > errors for functions it uses in glib - not entirely sure why at > the moment, > as I said C is not my strong point.) I've also noticed the plugins > currently bundled have quite a few changes to the gstreamer > version, and I > can't quite work out the logic behind why things have been > changed the way > they have - so even after the compilation issue is resolved I'm > now less > confident that it will just drop in and work! Again, if someone > knowledgeable in this area that's lurking in the shadows could > shed any > light on any of this, it would be hugely appreciated. > > We did some changes in existing GStreamer code because it had errors > and because we needed to expand some functionality. The changes are > not very extensive. > > > However, putting the current problems aside for a bit, the snags > I hit up > until this point could I think be relatively easily addressed in the > documentation. With that in mind could I suggest a few > additional points > for the wiki? These may be obvious to the majority reading here, > but as > someone completely new to building JFX they had me stumped for a > while! > > I can give you some directions. There is no wiki. I'd appreciate if > you created one. > > > - It turns out that the Gstreamer stuff doesn't compile at > all by default, > which is why I wasn't seeing any changes on the native level. To > ensure > GStreamer is actually compiled, you need to copy the > gradle.properties.template file to gradle.properties, and > uncomment the > "#COMPILE_MEDIA = true" line. (A similar scenario would appear > to exist for > any webkit alterations as per the line above.) > > You don't need to comment/uncomment anything. Just add > -PCOMPILE_MEDIA=true to the gradle command line. You can however > change the properties file too. > > > - As well as the requirements listed, I needed the Windows SDK ( > http://www.microsoft.com/en-__gb/download/details.aspx?id=__8279 > ) > installed for > GStreamer to compile successfully under Windows (7) - without it > cygpath > just threw a rather confusing error. > > You need windows 7.1a SDK and speaking precisely you need only > samples from it because samples have BaseClasses at > Samples/multimedia/directshow/__baseclasses. BaseClasses are used > for Oracle direchshowwrapper plugin. > > > - The developer workflow page ( > https://wiki.openjdk.java.net/__display/OpenJFX/Developer+__Work+Flow > ) > refers > to "-Djavafx.ext.dirs" - I think this should be > "-Djava.ext.dirs" instead? > > What are you gonna use it for ? > > > I'm happy to make the above changes myself but unsure of if / > where you can > sign up for an account, so I'm just throwing them here for now - > if anyone > could point me to the right place then that'd be great! > > Steve. Can you give an advice ? > > > If I do ever manage to get this working (ha-ha) I'd also like to > throw up a > wiki page just detailing how to grab a gstreamer plugin and make the > necessary changes to it to compile it into openjfx as a stop gap > to then > perhaps working on one or both of the above JIRA issues and > seeing where I > get - does this sound reasonable? > > It does. > > > On Mar 22, 2014, at 9:26 PM, Michael Berry > > wrote: > > However, I'm not sure if I'm going about including > the matroska plugin > > in > > the right way - I've currently done the following: > > - Downloaded the latest version of the plugins from > here ( > http://gstreamer.freedesktop.__org/src/gst-plugins-good/ > ), > then added the > matroska one to the > modules/media/src/main/native/__gstreamer/plugins/ > folder, as well as the > > modules/media/src/main/native/__gstreamer/gstreamer-lite/gst-__plugins-good/gst/ > > folder (I'm unsure of this - should I add it to both > these folders?). > > Well you see. If you download the latest matroska plugin it > potentially can have dependencies on the latest GStreamer platform. > We don't have/use the latest gstreamer. The version we use is > 0.10.35. And the latest available is 1.x. They are incompatible in > some methods. > > > - Added all the C files from the first folder > mentioned above to the > plugins.vcxproj file > > - Added the relevant files and directory to > Makefile.gstplugins > > - Called the additional relevant plugin_init() > function in > gstplugins-lite.c > > There is one more thing you need to do here for Windows only apart > from running gradle with -PCOMPILE_MEDIA=true. Windows build system > has files that export symbols > 1) from glib-lite.dll > ${jfxroot}/rt/modules/media/__src/main/native/gstreamer/3rd___party/glib/glib-2.28.8/build/__win32/vs100/{glib-lite.def|__glib-liteD.def} > > Here the version with "D" is used for debug build and may contain > more symbols for export. > 2) from gstreamer-lite.dll > ${jfxroot}/rt/modules/media/__src/main/native/gstreamer/__projects/win/gstreamer-lite.__def > - used for both Release and Debug. > > If your plugin uses some methods of gstreamer/glib libraries not > mentioned in the files you should add the methods to the files. > Syntax is pretty simple. If you don't add depending methods to these > files you will get linker errors. C/C++ compiler will not generate > errors. > > Actually I think the best way to start developing/improving the > Media component is to upgrade GStreamer to 1.x from 0.10.35. It > would be a very good starting point and you would get less or no > problems using the latest available plugins. If someone wanna take > over this I can explain in details how to do it. > > K > > From adanecito at yahoo.com Tue Mar 25 14:06:12 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Tue, 25 Mar 2014 07:06:12 -0700 (PDT) Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> Message-ID: <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> Hi All, Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage Regards, -Tony On Tuesday, March 25, 2014 7:49 AM, Tony Anecito wrote: Hi All, Is JavaFX using Apple Quicktime for video support? Thanks, -Tony From david.dehaven at oracle.com Tue Mar 25 15:26:58 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 25 Mar 2014 08:26:58 -0700 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> Message-ID: <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> > Hi All, > Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. > > http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage It uses the now deprecated QTKit to play media. -DrD- From adanecito at yahoo.com Tue Mar 25 15:46:53 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Tue, 25 Mar 2014 08:46:53 -0700 (PDT) Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> Message-ID: <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. I am guessing these new rules will soon apply to everything but I could be wrong. Regards, -Tony On Tuesday, March 25, 2014 9:27 AM, David DeHaven wrote: > Hi All, > Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. > > http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage It uses the now deprecated QTKit to play media. -DrD- From steve.x.northover at oracle.com Tue Mar 25 16:19:19 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 25 Mar 2014 12:19:19 -0400 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> Message-ID: <5331AC87.9090009@oracle.com> Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 Steve On 2014-03-25 11:46 AM, Tony Anecito wrote: > Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. > I am guessing these new rules will soon apply to everything but I could be wrong. > > Regards, > -Tony > > > > > > On Tuesday, March 25, 2014 9:27 AM, David DeHaven wrote: > > >> Hi All, >> Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. >> >> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage > It uses the now deprecated QTKit to play media. > > -DrD- From philip.race at oracle.com Tue Mar 25 16:39:02 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 25 Mar 2014 09:39:02 -0700 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <5331AC87.9090009@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> Message-ID: <5331B126.3080209@oracle.com> I presume that Apple now want you to use AVKit which is new in 10.9. However I don't understand how you can develop an app that targets 10.8 if its unable to use QTKit since that's all there is on 10.8 or earlier. Does the AppStore really disallow targeting something like half the installed base ?? -phil. On 3/25/2014 9:19 AM, Stephen F Northover wrote: > Here is the JIRA that is tracking this: > https://javafx-jira.kenai.com/browse/RT-34893 > > Steve > > On 2014-03-25 11:46 AM, Tony Anecito wrote: >> Thanks for the verification. No matter what state Quicktime is in it >> is no longer accepted by the Apple Store. >> I am guessing these new rules will soon apply to everything but I >> could be wrong. >> >> Regards, >> -Tony >> >> >> >> >> >> On Tuesday, March 25, 2014 9:27 AM, David DeHaven >> wrote: >> >>> Hi All, >>> Apparently the JavaFX includes some libraries that use the obsolete >>> Quicktime. When some submits to the Apple Store a JavaFX app it gets >>> rejected based on JavaFX having the obsolete API. I found out how to >>> fix it from someone else running into the same issue. >>> >>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>> >> It uses the now deprecated QTKit to play media. >> >> -DrD- > From steve.x.northover at oracle.com Tue Mar 25 17:01:41 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 25 Mar 2014 13:01:41 -0400 Subject: Adding GStreamer plugins In-Reply-To: <533161E1.7050602@oracle.com> References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> <533161E1.7050602@oracle.com> Message-ID: <5331B675.5050508@oracle.com> On 2014-03-25 7:00 AM, Kirill Kirichenko wrote: > Hi Michael. > See my comments inline. > > On 24.03.2014 04:31, Michael Berry wrote: >> I'm now a bit further along with this, though struggling to get the >> matroska plugin to compile (getting a bunch of unresolved external >> symbol >> errors for functions it uses in glib - not entirely sure why at the >> moment, >> as I said C is not my strong point.) I've also noticed the plugins >> currently bundled have quite a few changes to the gstreamer version, >> and I >> can't quite work out the logic behind why things have been changed >> the way >> they have - so even after the compilation issue is resolved I'm now less >> confident that it will just drop in and work! Again, if someone >> knowledgeable in this area that's lurking in the shadows could shed any >> light on any of this, it would be hugely appreciated. > We did some changes in existing GStreamer code because it had errors > and because we needed to expand some functionality. The changes are > not very extensive. > >> However, putting the current problems aside for a bit, the snags I >> hit up >> until this point could I think be relatively easily addressed in the >> documentation. With that in mind could I suggest a few additional points >> for the wiki? These may be obvious to the majority reading here, but as >> someone completely new to building JFX they had me stumped for a while! > I can give you some directions. There is no wiki. I'd appreciate if > you created one. > >> - It turns out that the Gstreamer stuff doesn't compile at all by >> default, >> which is why I wasn't seeing any changes on the native level. To ensure >> GStreamer is actually compiled, you need to copy the >> gradle.properties.template file to gradle.properties, and uncomment the >> "#COMPILE_MEDIA = true" line. (A similar scenario would appear to >> exist for >> any webkit alterations as per the line above.) > You don't need to comment/uncomment anything. Just add > -PCOMPILE_MEDIA=true to the gradle command line. You can however > change the properties file too. > >> - As well as the requirements listed, I needed the Windows SDK ( >> http://www.microsoft.com/en-gb/download/details.aspx?id=8279) >> installed for >> GStreamer to compile successfully under Windows (7) - without it cygpath >> just threw a rather confusing error. > You need windows 7.1a SDK and speaking precisely you need only samples > from it because samples have BaseClasses at > Samples/multimedia/directshow/baseclasses. BaseClasses are used for > Oracle direchshowwrapper plugin. > >> - The developer workflow page ( >> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) >> refers >> to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" >> instead? > What are you gonna use it for ? I updated the page and got rid of the BINARY_STUB reference that is no longer needed. > >> I'm happy to make the above changes myself but unsure of if / where >> you can >> sign up for an account, so I'm just throwing them here for now - if >> anyone >> could point me to the right place then that'd be great! > Steve. Can you give an advice ? If you are looking to contribute (when you get to a good place), the process is well known and is followed by the everyone. https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews > >> If I do ever manage to get this working (ha-ha) I'd also like to >> throw up a >> wiki page just detailing how to grab a gstreamer plugin and make the >> necessary changes to it to compile it into openjfx as a stop gap to then >> perhaps working on one or both of the above JIRA issues and seeing >> where I >> get - does this sound reasonable? Only committers can edit the wiki right now. It is possible to become an Author and write to the wiki, but I would be happy to publish your recipe when you are happy with it. > It does. > > >>>> On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >>>>> However, I'm not sure if I'm going about including the matroska >>>>> plugin >>>> in >>>>> the right way - I've currently done the following: >>>>> >>>>> - Downloaded the latest version of the plugins from here ( >>>>> http://gstreamer.freedesktop.org/src/gst-plugins-good/), then >>>>> added the >>>>> matroska one to the modules/media/src/main/native/gstreamer/plugins/ >>>>> folder, as well as the >>>>> >>>> modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ >>>> >>>>> folder (I'm unsure of this - should I add it to both these folders?). > Well you see. If you download the latest matroska plugin it > potentially can have dependencies on the latest GStreamer platform. We > don't have/use the latest gstreamer. The version we use is 0.10.35. > And the latest available is 1.x. They are incompatible in some methods. > >>>>> - Added all the C files from the first folder mentioned above to the >>>>> plugins.vcxproj file >>>>> >>>>> - Added the relevant files and directory to Makefile.gstplugins >>>>> >>>>> - Called the additional relevant plugin_init() function in >>>>> gstplugins-lite.c > There is one more thing you need to do here for Windows only apart > from running gradle with -PCOMPILE_MEDIA=true. Windows build system > has files that export symbols > 1) from glib-lite.dll > ${jfxroot}/rt/modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.28.8/build/win32/vs100/{glib-lite.def|glib-liteD.def} > > Here the version with "D" is used for debug build and may contain more > symbols for export. > 2) from gstreamer-lite.dll > ${jfxroot}/rt/modules/media/src/main/native/gstreamer/projects/win/gstreamer-lite.def > - used for both Release and Debug. > > If your plugin uses some methods of gstreamer/glib libraries not > mentioned in the files you should add the methods to the files. Syntax > is pretty simple. If you don't add depending methods to these files > you will get linker errors. C/C++ compiler will not generate errors. > > Actually I think the best way to start developing/improving the Media > component is to upgrade GStreamer to 1.x from 0.10.35. It would be a > very good starting point and you would get less or no problems using > the latest available plugins. If someone wanna take over this I can > explain in details how to do it. > > K From adanecito at yahoo.com Tue Mar 25 17:27:25 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Tue, 25 Mar 2014 10:27:25 -0700 (PDT) Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <5331B126.3080209@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> Message-ID: <1395768445.74168.YahooMailNeo@web121804.mail.ne1.yahoo.com> Thanks I read it. I also added a new issue regarding Apple now needing a pinfo file for the jdk plugin inside the bundle created by JavaFX deploy. Regards, -Tony On Tuesday, March 25, 2014 10:36 AM, Phil Race wrote: I presume that Apple now want you to use AVKit which is new in 10.9. However I don't understand how you can develop an app that targets 10.8 if its unable to use QTKit since that's all there is on? 10.8 or earlier. Does the AppStore? really disallow targeting something like half the installed base ?? -phil. On 3/25/2014 9:19 AM, Stephen F Northover wrote: > Here is the JIRA that is tracking this: > https://javafx-jira.kenai.com/browse/RT-34893 > > Steve > > On 2014-03-25 11:46 AM, Tony Anecito wrote: >> Thanks for the verification. No matter what state Quicktime is in it >> is no longer accepted by the Apple Store. >> I am guessing these new rules will soon apply to everything but I >> could be wrong. >> >> Regards, >> -Tony >> >> >> >> >> >> On Tuesday, March 25, 2014 9:27 AM, David DeHaven >> wrote: >> >>> Hi All, >>> Apparently the JavaFX includes some libraries that use the obsolete >>> Quicktime. When some submits to the Apple Store a JavaFX app it gets >>> rejected based on JavaFX having the obsolete API. I found out how to >>> fix it from someone else running into the same issue. >>> >>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>> >> It uses the now deprecated QTKit to play media. >> >> -DrD- > From hang.vo at oracle.com Tue Mar 25 17:32:46 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 17:32:46 +0000 Subject: hg: openjfx/8u-dev/rt: Fix for RT-36360 [Monocle] Slight refactor; cache native display in java instead of native code. Message-ID: <201403251732.s2PHWwuU024431@aojmv0008> Changeset: a4f4d7834a8f Author: Lisa.Selle at oracle.com Date: 2014-03-25 13:30 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a4f4d7834a8f Fix for RT-36360 [Monocle] Slight refactor; cache native display in java instead of native code. Reviewed by dblaukopf. Tested with HelloSanity. ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6AcceleratedScreen.java ! modules/graphics/src/main/native-glass/monocle/mx6/MX6AcceleratedScreen.c From adanecito at yahoo.com Tue Mar 25 17:38:09 2014 From: adanecito at yahoo.com (Tony Anecito) Date: Tue, 25 Mar 2014 10:38:09 -0700 (PDT) Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <1395768445.74168.YahooMailNeo@web121804.mail.ne1.yahoo.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> <1395768445.74168.YahooMailNeo@web121804.mail.ne1.yahoo.com> Message-ID: <1395769089.70343.YahooMailNeo@web121803.mail.ne1.yahoo.com> Hi Phil, What happened is when I submitted my app package it uploaded and Apple ran a check and pointed out the issue but did not suggest a solution. There are other solutions for video out there but not sure Apple would approve. I will find out soon with my next app but for now trying not to throw too much technology at them at once. Oracle may be interested in what I am up to and why I think it is very important I get my app approved for the Apple App Store. http://www.myuniportal.com/screenshots.html Best Regards, Tony Anecito Founder/President MyUniPortal http://www.myuniportal.com Winner of Java Dukes Award On Tuesday, March 25, 2014 11:27 AM, Tony Anecito wrote: Thanks I read it. I also added a new issue regarding Apple now needing a pinfo file for the jdk plugin inside the bundle created by JavaFX deploy. Regards, -Tony On Tuesday, March 25, 2014 10:36 AM, Phil Race wrote: I presume that Apple now want you to use AVKit which is new in 10.9. However I don't understand how you can develop an app that targets 10.8 if its unable to use QTKit since that's all there is on? 10.8 or earlier. Does the AppStore? really disallow targeting something like half the installed base ?? -phil. On 3/25/2014 9:19 AM, Stephen F Northover wrote: > Here is the JIRA that is tracking this: > https://javafx-jira.kenai.com/browse/RT-34893 > > Steve > > On 2014-03-25 11:46 AM, Tony Anecito wrote: >> Thanks for the verification. No matter what state Quicktime is in it >> is no longer accepted by the Apple Store. >> I am guessing these new rules will soon apply to everything but I >> could be wrong. >> >> Regards, >> -Tony >> >> >> >> >> >> On Tuesday, March 25, 2014 9:27 AM, David DeHaven >> wrote: >> >>> Hi All, >>> Apparently the JavaFX includes some libraries that use the obsolete >>> Quicktime. When some submits to the Apple Store a JavaFX app it gets >>> rejected based on JavaFX having the obsolete API. I found out how to >>> fix it from someone else running into the same issue. >>> >>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>> >> It uses the now deprecated QTKit to play media. >> >> -DrD- > From David.Hill at Oracle.com Tue Mar 25 18:46:29 2014 From: David.Hill at Oracle.com (David Hill) Date: Tue, 25 Mar 2014 14:46:29 -0400 Subject: Glass Robot and getSCreenCapture In-Reply-To: <532C6E7E.4000401@Oracle.com> References: <532C6E7E.4000401@Oracle.com> Message-ID: <5331CF05.7070402@Oracle.com> On 3/21/14, Mar 21, 12:53 PM, David Hill wrote: Having heard a little feedback, here is my proposal in the form of a review request :-) > > > My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. > > This code is "internal" API, so I expect the real impact would be on SQE. I really like the idea of adding a bounds restriction - so that the requested bounds must be within the Screen. It seems the simplest solution to my issue of handling the odd edge case of out of bound pixels, with the least likely impact. This means that existing code in the implementations are not affected. I suspect that there will we little if any impact on SQE tests, given that most of us would avoid asking for a screen capture with undefined pixels. I do expect that we will encounter a few exceptions to this when tests are run on smaller displays (like embedded). I also added bounds checking to Robot.getPixelColor() for consistency, and because Embedded passes this call through to common code for screen capture. I did a grep through the JavaFX code base, and don't see any JavaFX use cases. I expect any "golden image" test code could be affected. I separated out this internal API changes from my embedded changes so we have a clear and easy thing to review. Jira: https://javafx-jira.kenai.com/browse/RT-36382 Patch: is inline in the Jira, but also here: diff -r bb72bd2fa889 modules/graphics/src/main/java/com/sun/glass/ui/Robot.java --- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 14:21:26 2014 -0400 +++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 14:41:37 2014 -0400 @@ -144,9 +144,20 @@ protected abstract int _getPixelColor(int x, int y); /** * Returns pixel color at specified screen coordinates in IntARGB format. + * + * If the requested pixel is not contained by the actual Screen + * bounds an IllegalArgumentException will be thrown. + * + * @param x The screen X of the requested capture (must be >=0) + * @param y The screen Y of the requested capture (must be >=0) */ public int getPixelColor(int x, int y) { Application.checkEventThread(); + Screen s = Screen.getMainScreen(); + if (x < 0 || y < 0 || + x >= s.getWidth() || y > s.getHeight()) { + throw new IllegalArgumentException("Capture out of bounds"); + } return _getPixelColor(x, y); } @@ -162,13 +173,27 @@ * will result in a Pixels object with dimensions (20x20). Calling code * should use the returned objects's getWidth() and getHeight() methods * to determine the image size. - * + * * If (@code isHiDPI) is {@code false}, the returned Pixels object is of * the requested size. Note that in this case the image may be scaled in * order to fit to the requested dimensions if running on a HiDPI display. + * + * If the requested capture bounds is not contained by the actual Screen + * bounds an IllegalArgumentException will be thrown. + * + * @param x The screen X of the requested capture (must be >=0) + * @param y The screen Y of the requested capture (must be >=0) + * @param width The of width the requested capture (must be >=1 and fit on the screen) + * @param height The of width the requested capture (must be >=1 and fit on the screen) + * @param isHiDPI return HiDPI if available */ public Pixels getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) { Application.checkEventThread(); + Screen s = Screen.getMainScreen(); + if (x < 0 || y < 0 || + x + width > s.getWidth() || y + height > s.getHeight()) { + throw new IllegalArgumentException("Capture out of bounds"); + } return _getScreenCapture(x, y, width, height, isHiDPI); } @@ -176,6 +201,14 @@ * Returns a capture of the specified area of the screen. * It is equivalent to calling getScreenCapture(x, y, width, height, false), * i.e. this method takes a "LowDPI" screen shot. + * + * If the requested capture bounds is not contained by the actual Screen + * bounds an IllegalArgumentException will be thrown. + * + * @param x The screen X of the requested capture (must be >=0) + * @param y The screen Y of the requested capture (must be >=0) + * @param width The of width the requested capture (must be >=1 and fit on the screen) + * @param height The of width the requested capture (must be >=1 and fit on the screen) */ public Pixels getScreenCapture(int x, int y, int width, int height) { return getScreenCapture(x, y, width, height, false); -- David Hill Java Embedded Development "On a clear disk, you can seek forever." From david.dehaven at oracle.com Tue Mar 25 19:09:27 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 25 Mar 2014 12:09:27 -0700 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <5331B126.3080209@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> Message-ID: Therein lies The Problem, and why we had to go with QTKit when we supported 10.6... Every two releases they seem to deprecate half-baked APIs in favor of some new half-baked API. At least as of 10.8 that seems to have stabilized somewhat, as we transition more and more to an iOS clone. We had issues with AVFoundation not working the way we needed and it wasn't available on 10.6. It's supposed to work correctly (never had time to confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to stick with QTKit for older releases and move to AVFoundation in 10.8 and later. Ideally, the QTKit component would be separate so it could be removed allowing MAS apps to still support A/V playback. I think the QTKit component can be dropped completely in FX 9 but it needs to be there in FX 8. AVKit is a high level component that sits on top of AVFoundation, it doesn't look useful for our purposes at first glance. -DrD- > I presume that Apple now want you to use AVKit which is new in 10.9. > However I don't understand how you can develop an app that targets 10.8 if its > unable to use QTKit since that's all there is on 10.8 or earlier. > > Does the AppStore really disallow targeting something like half the installed base ?? > > -phil. > > On 3/25/2014 9:19 AM, Stephen F Northover wrote: >> Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 >> >> Steve >> >> On 2014-03-25 11:46 AM, Tony Anecito wrote: >>> Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. >>> I am guessing these new rules will soon apply to everything but I could be wrong. >>> >>> Regards, >>> -Tony >>> >>> >>> >>> >>> >>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven wrote: >>> >>>> Hi All, >>>> Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. >>>> >>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>> It uses the now deprecated QTKit to play media. >>> >>> -DrD- >> > From philip.race at oracle.com Tue Mar 25 19:30:47 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 25 Mar 2014 12:30:47 -0700 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> Message-ID: <5331D967.602@oracle.com> I see .. so AVFoundation was already there since 10.7, its AVKit that's new in 10.9 but AV Foundation is what FX would use. It looks like Apple starting encouraging migration to AV Foundation about 18 months ago based on the date of this document :- https://developer.apple.com/library/mac/technotes/tn2300/_index.html I suppose we need to learn read the apple seeds and interpret that as a big, urgent, hint. -phil. On 3/25/2014 12:09 PM, David DeHaven wrote: > Therein lies The Problem, and why we had to go with QTKit when we supported 10.6... Every two releases they seem to deprecate half-baked APIs in favor of some new half-baked API. At least as of 10.8 that seems to have stabilized somewhat, as we transition more and more to an iOS clone. > > We had issues with AVFoundation not working the way we needed and it wasn't available on 10.6. It's supposed to work correctly (never had time to confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to stick with QTKit for older releases and move to AVFoundation in 10.8 and later. Ideally, the QTKit component would be separate so it could be removed allowing MAS apps to still support A/V playback. I think the QTKit component can be dropped completely in FX 9 but it needs to be there in FX 8. > > AVKit is a high level component that sits on top of AVFoundation, it doesn't look useful for our purposes at first glance. > > -DrD- > >> I presume that Apple now want you to use AVKit which is new in 10.9. >> However I don't understand how you can develop an app that targets 10.8 if its >> unable to use QTKit since that's all there is on 10.8 or earlier. >> >> Does the AppStore really disallow targeting something like half the installed base ?? >> >> -phil. >> >> On 3/25/2014 9:19 AM, Stephen F Northover wrote: >>> Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 >>> >>> Steve >>> >>> On 2014-03-25 11:46 AM, Tony Anecito wrote: >>>> Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. >>>> I am guessing these new rules will soon apply to everything but I could be wrong. >>>> >>>> Regards, >>>> -Tony >>>> >>>> >>>> >>>> >>>> >>>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven wrote: >>>> >>>>> Hi All, >>>>> Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. >>>>> >>>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>>> It uses the now deprecated QTKit to play media. >>>> >>>> -DrD- From steve.x.northover at oracle.com Tue Mar 25 19:30:36 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 25 Mar 2014 15:30:36 -0400 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <5331D967.602@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> <5331D967.602@oracle.com> Message-ID: <5331D95C.5070902@oracle.com> Apple has a long history of burning developers like this. It's the price of running on their platform. Steve On 2014-03-25 3:30 PM, Phil Race wrote: > I see .. so AVFoundation was already there since 10.7, its AVKit > that's new in 10.9 > but AV Foundation is what FX would use. > It looks like Apple starting encouraging migration to AV Foundation > about 18 months ago > based on the date of this document :- > https://developer.apple.com/library/mac/technotes/tn2300/_index.html > I suppose we need to learn read the apple seeds and interpret that as > a big, urgent, hint. > > -phil. > > > > > On 3/25/2014 12:09 PM, David DeHaven wrote: >> Therein lies The Problem, and why we had to go with QTKit when we >> supported 10.6... Every two releases they seem to deprecate >> half-baked APIs in favor of some new half-baked API. At least as of >> 10.8 that seems to have stabilized somewhat, as we transition more >> and more to an iOS clone. >> >> We had issues with AVFoundation not working the way we needed and it >> wasn't available on 10.6. It's supposed to work correctly (never had >> time to confirm) on 10.8 but that still leaves 10.7 out in the cold. >> So we'll likely have to stick with QTKit for older releases and move >> to AVFoundation in 10.8 and later. Ideally, the QTKit component would >> be separate so it could be removed allowing MAS apps to still support >> A/V playback. I think the QTKit component can be dropped completely >> in FX 9 but it needs to be there in FX 8. >> >> AVKit is a high level component that sits on top of AVFoundation, it >> doesn't look useful for our purposes at first glance. >> >> -DrD- >> >>> I presume that Apple now want you to use AVKit which is new in 10.9. >>> However I don't understand how you can develop an app that targets >>> 10.8 if its >>> unable to use QTKit since that's all there is on 10.8 or earlier. >>> >>> Does the AppStore really disallow targeting something like half the >>> installed base ?? >>> >>> -phil. >>> >>> On 3/25/2014 9:19 AM, Stephen F Northover wrote: >>>> Here is the JIRA that is tracking this: >>>> https://javafx-jira.kenai.com/browse/RT-34893 >>>> >>>> Steve >>>> >>>> On 2014-03-25 11:46 AM, Tony Anecito wrote: >>>>> Thanks for the verification. No matter what state Quicktime is in >>>>> it is no longer accepted by the Apple Store. >>>>> I am guessing these new rules will soon apply to everything but I >>>>> could be wrong. >>>>> >>>>> Regards, >>>>> -Tony >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> Apparently the JavaFX includes some libraries that use the >>>>>> obsolete Quicktime. When some submits to the Apple Store a JavaFX >>>>>> app it gets rejected based on JavaFX having the obsolete API. I >>>>>> found out how to fix it from someone else running into the same >>>>>> issue. >>>>>> >>>>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>>>>> >>>>> It uses the now deprecated QTKit to play media. >>>>> >>>>> -DrD- > From david.dehaven at oracle.com Tue Mar 25 20:02:42 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 25 Mar 2014 13:02:42 -0700 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <5331D95C.5070902@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> <5331D967.602@oracle.com> <5331D95C.5070902@oracle.com> Message-ID: <89DB63A7-0FDB-4EC6-A185-86312D408E29@oracle.com> Yes, this is true, but QuickTime (despite it's horrible component architecture) was stable and actually useful for a very long time, then they dropped it and replaced it with what amounts to absolutely nothing useful. Only in 10.8 did they start putting useful bits back in, it's still a long ways to go to catch up to the utility of QuickTime. -DrD- > Apple has a long history of burning developers like this. It's the price of running on their platform. > > Steve > > On 2014-03-25 3:30 PM, Phil Race wrote: >> I see .. so AVFoundation was already there since 10.7, its AVKit that's new in 10.9 >> but AV Foundation is what FX would use. >> It looks like Apple starting encouraging migration to AV Foundation about 18 months ago >> based on the date of this document :- >> https://developer.apple.com/library/mac/technotes/tn2300/_index.html >> I suppose we need to learn read the apple seeds and interpret that as a big, urgent, hint. >> >> -phil. >> >> >> >> >> On 3/25/2014 12:09 PM, David DeHaven wrote: >>> Therein lies The Problem, and why we had to go with QTKit when we supported 10.6... Every two releases they seem to deprecate half-baked APIs in favor of some new half-baked API. At least as of 10.8 that seems to have stabilized somewhat, as we transition more and more to an iOS clone. >>> >>> We had issues with AVFoundation not working the way we needed and it wasn't available on 10.6. It's supposed to work correctly (never had time to confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to stick with QTKit for older releases and move to AVFoundation in 10.8 and later. Ideally, the QTKit component would be separate so it could be removed allowing MAS apps to still support A/V playback. I think the QTKit component can be dropped completely in FX 9 but it needs to be there in FX 8. >>> >>> AVKit is a high level component that sits on top of AVFoundation, it doesn't look useful for our purposes at first glance. >>> >>> -DrD- >>> >>>> I presume that Apple now want you to use AVKit which is new in 10.9. >>>> However I don't understand how you can develop an app that targets 10.8 if its >>>> unable to use QTKit since that's all there is on 10.8 or earlier. >>>> >>>> Does the AppStore really disallow targeting something like half the installed base ?? >>>> >>>> -phil. >>>> >>>> On 3/25/2014 9:19 AM, Stephen F Northover wrote: >>>>> Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 >>>>> >>>>> Steve >>>>> >>>>> On 2014-03-25 11:46 AM, Tony Anecito wrote: >>>>>> Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. >>>>>> I am guessing these new rules will soon apply to everything but I could be wrong. >>>>>> >>>>>> Regards, >>>>>> -Tony >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. >>>>>>> >>>>>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>>>>> It uses the now deprecated QTKit to play media. >>>>>> >>>>>> -DrD- >> > From steve.x.northover at oracle.com Tue Mar 25 20:08:59 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 25 Mar 2014 16:08:59 -0400 Subject: Is Quicktime API calls inside JavaFX? In-Reply-To: <89DB63A7-0FDB-4EC6-A185-86312D408E29@oracle.com> References: <1395753984.99439.YahooMailNeo@web121805.mail.ne1.yahoo.com> <1395756372.96142.YahooMailNeo@web121801.mail.ne1.yahoo.com> <94A243EE-779D-4D89-95B2-D6EA107DC774@oracle.com> <1395762413.45937.YahooMailNeo@web121806.mail.ne1.yahoo.com> <5331AC87.9090009@oracle.com> <5331B126.3080209@oracle.com> <5331D967.602@oracle.com> <5331D95C.5070902@oracle.com> <89DB63A7-0FDB-4EC6-A185-86312D408E29@oracle.com> Message-ID: <5331E25B.3020105@oracle.com> As I said, Apple does this. It took cocoa (a "nice" API) years until it had the functionality of carbon (an "awful" API). Believe me, I have experienced the trail of dead API and the pointless developer rewrites. Steve On 2014-03-25 4:02 PM, David DeHaven wrote: > Yes, this is true, but QuickTime (despite it's horrible component architecture) was stable and actually useful for a very long time, then they dropped it and replaced it with what amounts to absolutely nothing useful. Only in 10.8 did they start putting useful bits back in, it's still a long ways to go to catch up to the utility of QuickTime. > > -DrD- > >> Apple has a long history of burning developers like this. It's the price of running on their platform. >> >> Steve >> >> On 2014-03-25 3:30 PM, Phil Race wrote: >>> I see .. so AVFoundation was already there since 10.7, its AVKit that's new in 10.9 >>> but AV Foundation is what FX would use. >>> It looks like Apple starting encouraging migration to AV Foundation about 18 months ago >>> based on the date of this document :- >>> https://developer.apple.com/library/mac/technotes/tn2300/_index.html >>> I suppose we need to learn read the apple seeds and interpret that as a big, urgent, hint. >>> >>> -phil. >>> >>> >>> >>> >>> On 3/25/2014 12:09 PM, David DeHaven wrote: >>>> Therein lies The Problem, and why we had to go with QTKit when we supported 10.6... Every two releases they seem to deprecate half-baked APIs in favor of some new half-baked API. At least as of 10.8 that seems to have stabilized somewhat, as we transition more and more to an iOS clone. >>>> >>>> We had issues with AVFoundation not working the way we needed and it wasn't available on 10.6. It's supposed to work correctly (never had time to confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to stick with QTKit for older releases and move to AVFoundation in 10.8 and later. Ideally, the QTKit component would be separate so it could be removed allowing MAS apps to still support A/V playback. I think the QTKit component can be dropped completely in FX 9 but it needs to be there in FX 8. >>>> >>>> AVKit is a high level component that sits on top of AVFoundation, it doesn't look useful for our purposes at first glance. >>>> >>>> -DrD- >>>> >>>>> I presume that Apple now want you to use AVKit which is new in 10.9. >>>>> However I don't understand how you can develop an app that targets 10.8 if its >>>>> unable to use QTKit since that's all there is on 10.8 or earlier. >>>>> >>>>> Does the AppStore really disallow targeting something like half the installed base ?? >>>>> >>>>> -phil. >>>>> >>>>> On 3/25/2014 9:19 AM, Stephen F Northover wrote: >>>>>> Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 >>>>>> >>>>>> Steve >>>>>> >>>>>> On 2014-03-25 11:46 AM, Tony Anecito wrote: >>>>>>> Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. >>>>>>> I am guessing these new rules will soon apply to everything but I could be wrong. >>>>>>> >>>>>>> Regards, >>>>>>> -Tony >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. >>>>>>>> >>>>>>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage >>>>>>> It uses the now deprecated QTKit to play media. >>>>>>> >>>>>>> -DrD- From anthony.petrov at oracle.com Tue Mar 25 20:10:58 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 26 Mar 2014 00:10:58 +0400 Subject: [8u20] Review request for RT-35263: Win: Crashing VM in a JavaFX 3D app reading and writing STL files Message-ID: <5331E2D2.9010503@oracle.com> Hi Felipe, Steve, Please review a fix for https://javafx-jira.kenai.com/browse/RT-35263 -- best regards, Anthony From hang.vo at oracle.com Tue Mar 25 21:03:08 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 21:03:08 +0000 Subject: hg: openjfx/8u-dev/rt: [Accessibility] cosmetic changes Message-ID: <201403252103.s2PL3LDU027865@aojmv0008> Changeset: e260e71603ca Author: felipe Date: 2014-03-25 13:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e260e71603ca [Accessibility] cosmetic changes ! modules/graphics/src/main/java/com/sun/glass/ui/PlatformAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java From hang.vo at oracle.com Tue Mar 25 21:47:37 2014 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 25 Mar 2014 21:47:37 +0000 Subject: hg: openjfx/8u-dev/rt: RT-36375: Monocle, fix order of operations with Buffer in capture Message-ID: <201403252147.s2PLloTH004735@aojmv0008> Changeset: 85e8ec504bff Author: ddhill Date: 2014-03-25 17:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/85e8ec504bff RT-36375: Monocle, fix order of operations with Buffer in capture Reviewed-by: dblaukopf ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleRobot.java From mjrb5 at kent.ac.uk Tue Mar 25 23:39:40 2014 From: mjrb5 at kent.ac.uk (Michael Berry) Date: Tue, 25 Mar 2014 23:39:40 +0000 Subject: Adding GStreamer plugins In-Reply-To: <5331B675.5050508@oracle.com> References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> <533161E1.7050602@oracle.com> <5331B675.5050508@oracle.com> Message-ID: Hi all, Turns out it was a stupid mistake on my part causing the last few linking errors, I hadn't added one of the C files I needed to the makefile (well I had, but I'd then reverted it again without realising!) Thanks to all for the prods and advice. Once I'd done that, the build went through without a hitch - and then it was just a case of making the relevant additions to the native code to register the MKV type and create a pipeline from it using the plugin. This wasn't hard to work out at all; I've since tried several test files in MKV format (with AAC audio) all of which play in MediaPlayer without a hitch! I mainly wanted to do this as a personal exercise, though I'd imagine this is a useful piece of functionality for many others also - so should I submit a patch of the changes, or is this unlikely to be accepted? (Again, sorry for the perhaps obvious question, I'm rather new to this.) I've had a look at the code review process and it seems to suggest adding a patch to the relevant JIRA issue for those who don't have commit access (in this case 18009), but I don't seem to have permission to do that either? Thanks, Michael On 25 March 2014 17:01, Stephen F Northover wrote: > > On 2014-03-25 7:00 AM, Kirill Kirichenko wrote: > >> Hi Michael. >> See my comments inline. >> >> On 24.03.2014 04:31, Michael Berry wrote: >> >>> I'm now a bit further along with this, though struggling to get the >>> matroska plugin to compile (getting a bunch of unresolved external symbol >>> errors for functions it uses in glib - not entirely sure why at the >>> moment, >>> as I said C is not my strong point.) I've also noticed the plugins >>> currently bundled have quite a few changes to the gstreamer version, and >>> I >>> can't quite work out the logic behind why things have been changed the >>> way >>> they have - so even after the compilation issue is resolved I'm now less >>> confident that it will just drop in and work! Again, if someone >>> knowledgeable in this area that's lurking in the shadows could shed any >>> light on any of this, it would be hugely appreciated. >>> >> We did some changes in existing GStreamer code because it had errors and >> because we needed to expand some functionality. The changes are not very >> extensive. >> >> However, putting the current problems aside for a bit, the snags I hit up >>> until this point could I think be relatively easily addressed in the >>> documentation. With that in mind could I suggest a few additional points >>> for the wiki? These may be obvious to the majority reading here, but as >>> someone completely new to building JFX they had me stumped for a while! >>> >> I can give you some directions. There is no wiki. I'd appreciate if you >> created one. >> >> - It turns out that the Gstreamer stuff doesn't compile at all by >>> default, >>> which is why I wasn't seeing any changes on the native level. To ensure >>> GStreamer is actually compiled, you need to copy the >>> gradle.properties.template file to gradle.properties, and uncomment the >>> "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist >>> for >>> any webkit alterations as per the line above.) >>> >> You don't need to comment/uncomment anything. Just add >> -PCOMPILE_MEDIA=true to the gradle command line. You can however change the >> properties file too. >> >> - As well as the requirements listed, I needed the Windows SDK ( >>> http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed >>> for >>> GStreamer to compile successfully under Windows (7) - without it cygpath >>> just threw a rather confusing error. >>> >> You need windows 7.1a SDK and speaking precisely you need only samples >> from it because samples have BaseClasses at Samples/multimedia/directshow/baseclasses. >> BaseClasses are used for Oracle direchshowwrapper plugin. >> >> - The developer workflow page ( >>> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) >>> refers >>> to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" >>> instead? >>> >> What are you gonna use it for ? >> > I updated the page and got rid of the BINARY_STUB reference that is no > longer needed. > > >> I'm happy to make the above changes myself but unsure of if / where you >>> can >>> sign up for an account, so I'm just throwing them here for now - if >>> anyone >>> could point me to the right place then that'd be great! >>> >> Steve. Can you give an advice ? >> > If you are looking to contribute (when you get to a good place), the > process is well known and is followed by the everyone. > > https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews > > >> If I do ever manage to get this working (ha-ha) I'd also like to throw >>> up a >>> wiki page just detailing how to grab a gstreamer plugin and make the >>> necessary changes to it to compile it into openjfx as a stop gap to then >>> perhaps working on one or both of the above JIRA issues and seeing where >>> I >>> get - does this sound reasonable? >>> >> > Only committers can edit the wiki right now. It is possible to become an > Author and write to the wiki, but I would be happy to publish your recipe > when you are happy with it. > > > It does. >> >> >> On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >>>>> >>>>>> However, I'm not sure if I'm going about including the matroska plugin >>>>>> >>>>> in >>>>> >>>>>> the right way - I've currently done the following: >>>>>> >>>>>> - Downloaded the latest version of the plugins from here ( >>>>>> http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added >>>>>> the >>>>>> matroska one to the modules/media/src/main/native/gstreamer/plugins/ >>>>>> folder, as well as the >>>>>> >>>>>> modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ >>>>> >>>>> >>>>>> folder (I'm unsure of this - should I add it to both these folders?). >>>>>> >>>>> Well you see. If you download the latest matroska plugin it >> potentially can have dependencies on the latest GStreamer platform. We >> don't have/use the latest gstreamer. The version we use is 0.10.35. And the >> latest available is 1.x. They are incompatible in some methods. >> >> - Added all the C files from the first folder mentioned above to the >>>>>> plugins.vcxproj file >>>>>> >>>>>> - Added the relevant files and directory to Makefile.gstplugins >>>>>> >>>>>> - Called the additional relevant plugin_init() function in >>>>>> gstplugins-lite.c >>>>>> >>>>> There is one more thing you need to do here for Windows only apart >> from running gradle with -PCOMPILE_MEDIA=true. Windows build system has >> files that export symbols >> 1) from glib-lite.dll ${jfxroot}/rt/modules/media/ >> src/main/native/gstreamer/3rd_party/glib/glib-2.28.8/build/ >> win32/vs100/{glib-lite.def|glib-liteD.def} >> Here the version with "D" is used for debug build and may contain more >> symbols for export. >> 2) from gstreamer-lite.dll ${jfxroot}/rt/modules/media/ >> src/main/native/gstreamer/projects/win/gstreamer-lite.def - used for >> both Release and Debug. >> >> If your plugin uses some methods of gstreamer/glib libraries not >> mentioned in the files you should add the methods to the files. Syntax is >> pretty simple. If you don't add depending methods to these files you will >> get linker errors. C/C++ compiler will not generate errors. >> >> Actually I think the best way to start developing/improving the Media >> component is to upgrade GStreamer to 1.x from 0.10.35. It would be a very >> good starting point and you would get less or no problems using the latest >> available plugins. If someone wanna take over this I can explain in details >> how to do it. >> >> K >> > > From richard.bair at oracle.com Tue Mar 25 23:46:19 2014 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 25 Mar 2014 16:46:19 -0700 Subject: Adding GStreamer plugins In-Reply-To: References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> <533161E1.7050602@oracle.com> <5331B675.5050508@oracle.com> Message-ID: <67B92F92-EDA6-4373-93C5-5808CF4EA148@oracle.com> > Turns out it was a stupid mistake on my part causing the last few linking > errors, I hadn't added one of the C files I needed to the makefile (well I > had, but I'd then reverted it again without realising!) Thanks to all for > the prods and advice. > > Once I'd done that, the build went through without a hitch - and then it > was just a case of making the relevant additions to the native code to > register the MKV type and create a pipeline from it using the plugin. This > wasn't hard to work out at all; I've since tried several test files in MKV > format (with AAC audio) all of which play in MediaPlayer without a hitch! Awesome! > I mainly wanted to do this as a personal exercise, though I'd imagine this > is a useful piece of functionality for many others also - so should I > submit a patch of the changes, or is this unlikely to be accepted? (Again, > sorry for the perhaps obvious question, I'm rather new to this.) I've had a > look at the code review process and it seems to suggest adding a patch to > the relevant JIRA issue for those who don't have commit access (in this > case 18009), but I don't seem to have permission to do that either? It sounds like there are perhaps two different ways to move forward here, the first is to take a submission in the form of WIKI writeup that we can post so that anybody else who wants to try extending the media files can follow the path you took. The other is to take a patch for the given JIRA issue. Sadly, the JIRA server doesn?t allow just anybody to supply patches, so you will have to email to Steve or Kevin and they can attach it to the issue for you. Thanks! Richard From jonathan.giles at oracle.com Tue Mar 25 23:47:03 2014 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 26 Mar 2014 12:47:03 +1300 Subject: Adding GStreamer plugins In-Reply-To: References: <033F0179-0260-46F1-AF42-C24C5CF866D2@gmail.com> <533161E1.7050602@oracle.com> <5331B675.5050508@oracle.com> Message-ID: <53321577.4070303@oracle.com> Typically in this case you would email the patch to the assigned developer, but it appears RT-18009 is unassigned at present. I think that is the first hurdle that needs to be resolved, but if you email me your patch I will attach it to the jira issue so that it is at least available for others. Thanks! -- Jonathan On 26/03/2014 12:39 p.m., Michael Berry wrote: > Hi all, > > Turns out it was a stupid mistake on my part causing the last few linking > errors, I hadn't added one of the C files I needed to the makefile (well I > had, but I'd then reverted it again without realising!) Thanks to all for > the prods and advice. > > Once I'd done that, the build went through without a hitch - and then it > was just a case of making the relevant additions to the native code to > register the MKV type and create a pipeline from it using the plugin. This > wasn't hard to work out at all; I've since tried several test files in MKV > format (with AAC audio) all of which play in MediaPlayer without a hitch! > > I mainly wanted to do this as a personal exercise, though I'd imagine this > is a useful piece of functionality for many others also - so should I > submit a patch of the changes, or is this unlikely to be accepted? (Again, > sorry for the perhaps obvious question, I'm rather new to this.) I've had a > look at the code review process and it seems to suggest adding a patch to > the relevant JIRA issue for those who don't have commit access (in this > case 18009), but I don't seem to have permission to do that either? > > Thanks, > > Michael > > > On 25 March 2014 17:01, Stephen F Northover wrote: > >> On 2014-03-25 7:00 AM, Kirill Kirichenko wrote: >> >>> Hi Michael. >>> See my comments inline. >>> >>> On 24.03.2014 04:31, Michael Berry wrote: >>> >>>> I'm now a bit further along with this, though struggling to get the >>>> matroska plugin to compile (getting a bunch of unresolved external symbol >>>> errors for functions it uses in glib - not entirely sure why at the >>>> moment, >>>> as I said C is not my strong point.) I've also noticed the plugins >>>> currently bundled have quite a few changes to the gstreamer version, and >>>> I >>>> can't quite work out the logic behind why things have been changed the >>>> way >>>> they have - so even after the compilation issue is resolved I'm now less >>>> confident that it will just drop in and work! Again, if someone >>>> knowledgeable in this area that's lurking in the shadows could shed any >>>> light on any of this, it would be hugely appreciated. >>>> >>> We did some changes in existing GStreamer code because it had errors and >>> because we needed to expand some functionality. The changes are not very >>> extensive. >>> >>> However, putting the current problems aside for a bit, the snags I hit up >>>> until this point could I think be relatively easily addressed in the >>>> documentation. With that in mind could I suggest a few additional points >>>> for the wiki? These may be obvious to the majority reading here, but as >>>> someone completely new to building JFX they had me stumped for a while! >>>> >>> I can give you some directions. There is no wiki. I'd appreciate if you >>> created one. >>> >>> - It turns out that the Gstreamer stuff doesn't compile at all by >>>> default, >>>> which is why I wasn't seeing any changes on the native level. To ensure >>>> GStreamer is actually compiled, you need to copy the >>>> gradle.properties.template file to gradle.properties, and uncomment the >>>> "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist >>>> for >>>> any webkit alterations as per the line above.) >>>> >>> You don't need to comment/uncomment anything. Just add >>> -PCOMPILE_MEDIA=true to the gradle command line. You can however change the >>> properties file too. >>> >>> - As well as the requirements listed, I needed the Windows SDK ( >>>> http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed >>>> for >>>> GStreamer to compile successfully under Windows (7) - without it cygpath >>>> just threw a rather confusing error. >>>> >>> You need windows 7.1a SDK and speaking precisely you need only samples >>> from it because samples have BaseClasses at Samples/multimedia/directshow/baseclasses. >>> BaseClasses are used for Oracle direchshowwrapper plugin. >>> >>> - The developer workflow page ( >>>> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) >>>> refers >>>> to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" >>>> instead? >>>> >>> What are you gonna use it for ? >>> >> I updated the page and got rid of the BINARY_STUB reference that is no >> longer needed. >> >> >>> I'm happy to make the above changes myself but unsure of if / where you >>>> can >>>> sign up for an account, so I'm just throwing them here for now - if >>>> anyone >>>> could point me to the right place then that'd be great! >>>> >>> Steve. Can you give an advice ? >>> >> If you are looking to contribute (when you get to a good place), the >> process is well known and is followed by the everyone. >> >> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews >> >> >>> If I do ever manage to get this working (ha-ha) I'd also like to throw >>>> up a >>>> wiki page just detailing how to grab a gstreamer plugin and make the >>>> necessary changes to it to compile it into openjfx as a stop gap to then >>>> perhaps working on one or both of the above JIRA issues and seeing where >>>> I >>>> get - does this sound reasonable? >>>> >> Only committers can edit the wiki right now. It is possible to become an >> Author and write to the wiki, but I would be happy to publish your recipe >> when you are happy with it. >> >> >> It does. >>> >>> On Mar 22, 2014, at 9:26 PM, Michael Berry wrote: >>>>>>> However, I'm not sure if I'm going about including the matroska plugin >>>>>>> >>>>>> in >>>>>> >>>>>>> the right way - I've currently done the following: >>>>>>> >>>>>>> - Downloaded the latest version of the plugins from here ( >>>>>>> http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added >>>>>>> the >>>>>>> matroska one to the modules/media/src/main/native/gstreamer/plugins/ >>>>>>> folder, as well as the >>>>>>> >>>>>>> modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ >>>>>> >>>>>>> folder (I'm unsure of this - should I add it to both these folders?)