From hang.vo at oracle.com Fri Mar 1 01:04:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 09:04:03 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130301090413.E442F4750E@hg.openjdk.java.net> Changeset: 534729526388 Author: Martin Sladecek Date: 2013-03-01 09:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/534729526388 RT-28198 com.sun.javafx.binding.SelectBinding$SelectBindingHelper has a dependency on javafx.beans ! javafx-beans/src/com/sun/javafx/binding/SelectBinding.java + javafx-beans/src/com/sun/javafx/property/JavaBeanAccessHelper.java ! javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanQuickAccessor.java Changeset: fe1c4d375337 Author: Martin Sladecek Date: 2013-03-01 09:58 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe1c4d375337 merge From milan.kubec at oracle.com Fri Mar 1 07:39:47 2013 From: milan.kubec at oracle.com (Milan Kubec) Date: Fri, 01 Mar 2013 16:39:47 +0100 Subject: Bugs with patches In-Reply-To: References: Message-ID: <5130CBC3.8040502@oracle.com> Hello, RT-25559 fix will be pushed soon. Milan Dne 28.2.2013 0:24, Danno Ferrin napsal(a): > As I mentioned on twitter, I have some JIRAs with patches attached that I > fear may have been forgotten about. > > http://javafx-jira.kenai.com/browse/RT-27989 - DEB installer should > generate installed size field > http://javafx-jira.kenai.com/browse/RT-27984 - MSI and EXE installers > disagree on vendor from same install params > http://javafx-jira.kenai.com/browse/RT-25559 - A revisit, but improve the > error output so it blames the correct failures > From ccaks at bestsolution.at Fri Mar 1 07:41:37 2013 From: ccaks at bestsolution.at (Christoph Caks) Date: Fri, 01 Mar 2013 16:41:37 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application Message-ID: <5130CC31.3070501@bestsolution.at> Hi, I'm developing a OpenGL based 3d application and instead of writing my own ui code I'd like to reuse javafx for the ui part. Since getting an OpenGL context from JavaFX seems to be very complicated (as discussed here) i thought about a different approach. What if javafx could reuse my rendering context. I'm thinking of implementing a custom prism backend which renders within my application context, after my content was rendered. As far as i know is the prism api is an internal implementation detail, but it may be possible to ignore changes to it by bundling a specific jre version with the application. I have not yet digged into prism code but I like to hear your thoughts about this approach. greetings Christoph From hang.vo at oracle.com Fri Mar 1 08:49:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 16:49:09 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130301164922.6087E47519@hg.openjdk.java.net> Changeset: 16e4c07f8562 Author: hudson Date: 2013-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/16e4c07f8562 Added tag 8.0-b79 for changeset 06afa65a1aa3 ! .hgtags Changeset: 7a6a30b004c8 Author: David Grieve Date: 2013-03-01 11:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7a6a30b004c8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Fri Mar 1 10:18:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 18:18:39 +0000 Subject: hg: openjfx/8/controls/rt: Modena app, changed to Java project from FX project. Moved fonts to menu rather than button. Message-ID: <20130301181848.E778547524@hg.openjdk.java.net> Changeset: 39bb41c52de5 Author: "Jasper Potts" Date: 2013-03-01 10:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/39bb41c52de5 Modena app, changed to Java project from FX project. Moved fonts to menu rather than button. ! apps/experiments/Modena/build.xml ! apps/experiments/Modena/nbproject/build-impl.xml - apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties - apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties ! apps/experiments/Modena/nbproject/genfiles.properties - apps/experiments/Modena/nbproject/jfx-impl.xml - apps/experiments/Modena/nbproject/jfx-impl_backup.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_2.xml ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/nbproject/project.xml ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java From hang.vo at oracle.com Fri Mar 1 11:33:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 19:33:44 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-28223: Fix controls heights to be consistent. reviewed by Jonathan and Rich. This includeds fixes to controls to utilize new API from RT-27762 also fixes for padding snapping to pixel in consitant way. Message-ID: <20130301193351.89ACE47529@hg.openjdk.java.net> Changeset: 1908325045af Author: "Jasper Potts" Date: 2013-03-01 11:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1908325045af Fixed RT-28223: Fix controls heights to be consistent. reviewed by Jonathan and Rich. This includeds fixes to controls to utilize new API from RT-27762 also fixes for padding snapping to pixel in consitant way. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabelSkinTest.java From hang.vo at oracle.com Fri Mar 1 12:33:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 20:33:47 +0000 Subject: hg: openjfx/8/controls/rt: Modena test app, fixed project. Updated alignment page to move lines to match font size. Message-ID: <20130301203350.CD6B1477C0@hg.openjdk.java.net> Changeset: fe536d52fcd7 Author: "Jasper Potts" Date: 2013-03-01 12:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fe536d52fcd7 Modena test app, fixed project. Updated alignment page to move lines to match font size. ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SameHeightTest.fxml + apps/experiments/Modena/src/modena/SameHeightTest.fxml.bak + apps/experiments/Modena/src/modena/SameHeightTestController.java ! apps/experiments/Modena/src/modena/SamplePage.java From mark.howe at oracle.com Fri Mar 1 13:05:52 2013 From: mark.howe at oracle.com (Mark Howe) Date: Fri, 1 Mar 2013 13:05:52 -0800 Subject: Bugs with patches In-Reply-To: <5130CBC3.8040502@oracle.com> References: <5130CBC3.8040502@oracle.com> Message-ID: The other two will be handled by either myself or Chris Bensen. Thanks for the reminder. Thanks Mark On Mar 1, 2013, at 7:39 AM, Milan Kubec wrote: > Hello, > RT-25559 fix will be pushed soon. > > Milan > > > Dne 28.2.2013 0:24, Danno Ferrin napsal(a): >> As I mentioned on twitter, I have some JIRAs with patches attached that I >> fear may have been forgotten about. >> >> http://javafx-jira.kenai.com/browse/RT-27989 - DEB installer should >> generate installed size field >> http://javafx-jira.kenai.com/browse/RT-27984 - MSI and EXE installers >> disagree on vendor from same install params >> http://javafx-jira.kenai.com/browse/RT-25559 - A revisit, but improve the >> error output so it blames the correct failures >> > From hang.vo at oracle.com Fri Mar 1 13:33:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 21:33:33 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed the classpath handling for Gradle build. I think I have it right now. The bootclasspath should be reset so that it only includes rt.jar (and specifically doesn't have jfxrt.jar). I then put jfxrt.jar on the classpath AFTER all the other project dependencies etc, so that it operates appropriately as a binary stub. Message-ID: <20130301213340.314AB477C5@hg.openjdk.java.net> Changeset: efc566a46a12 Author: rbair Date: 2013-03-01 13:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/efc566a46a12 Fixed the classpath handling for Gradle build. I think I have it right now. The bootclasspath should be reset so that it only includes rt.jar (and specifically doesn't have jfxrt.jar). I then put jfxrt.jar on the classpath AFTER all the other project dependencies etc, so that it operates appropriately as a binary stub. Also disabled tests until I get them sorted out. ! build.gradle From hang.vo at oracle.com Fri Mar 1 15:33:30 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Mar 2013 23:33:30 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-20784: Mac: Headless environment issue. Approved by Kevin and Phil Message-ID: <20130301233338.0E982477CB@hg.openjdk.java.net> Changeset: 41a9ef3f44e9 Author: Thor johannesson Date: 2013-03-01 15:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/41a9ef3f44e9 Fix RT-20784: Mac: Headless environment issue. Approved by Kevin and Phil ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java From hang.vo at oracle.com Fri Mar 1 17:04:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Mar 2013 01:04:29 +0000 Subject: hg: openjfx/8/graphics/rt: fix live resize for SWT Message-ID: <20130302010436.3BDC4477CC@hg.openjdk.java.net> Changeset: 520d4cf6f15f Author: snorthov Date: 2013-03-01 19:48 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/520d4cf6f15f fix live resize for SWT ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java From hang.vo at oracle.com Fri Mar 1 17:18:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Mar 2013 01:18:47 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble3: Fix for RT-28757 Home Page resize bad performance Message-ID: <20130302011852.80BC3477CD@hg.openjdk.java.net> Changeset: d27aceac8d66 Author: Alexander Kouznetsov Date: 2013-03-01 17:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d27aceac8d66 Ensemble3: Fix for RT-28757 Home Page resize bad performance ! apps/samples/Ensemble8/src/app/ensemble/HomePage.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java From ozemale at ozemail.com.au Fri Mar 1 18:01:16 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sat, 2 Mar 2013 13:01:16 +1100 Subject: Ensemble 8 Message-ID: <00b501ce16e9$d3293fd0$797bbf70$@com.au> Is it available for download anywhere yet? From hang.vo at oracle.com Fri Mar 1 18:04:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Mar 2013 02:04:58 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130302020640.4DD98477D0@hg.openjdk.java.net> Changeset: c33368d498fd Author: "Jasper Potts" Date: 2013-03-01 17:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c33368d498fd Added Modena to intellij project + apps/experiments/Modena/Modena.iml Changeset: 43c640c06b87 Author: "Jasper Potts" Date: 2013-03-01 17:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/43c640c06b87 Modena test app, enlarged vertical tab examples so can see more than one tab ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java Changeset: 3ffac5400582 Author: "Jasper Potts" Date: 2013-03-01 18:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3ffac5400582 Fixed RT-28758: REGRESSION: ComboBoxes are much wider by default ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java From hang.vo at oracle.com Fri Mar 1 18:04:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Mar 2013 02:04:55 +0000 Subject: hg: openjfx/8/graphics/rt: Failed to build on some Java 8 VM, due to long confusion. Likely bug in javac. Message-ID: <20130302020523.4B396477CF@hg.openjdk.java.net> Changeset: 787376bff0fd Author: rbair Date: 2013-03-01 17:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/787376bff0fd Failed to build on some Java 8 VM, due to long confusion. Likely bug in javac. ! javafx-logging/src/com/sun/javafx/logging/PulseLogger.java From richard.bair at oracle.com Fri Mar 1 18:23:22 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Mar 2013 18:23:22 -0800 Subject: Ensemble 8 In-Reply-To: <00b501ce16e9$d3293fd0$797bbf70$@com.au> References: <00b501ce16e9$d3293fd0$797bbf70$@com.au> Message-ID: <1273C2BD-6C59-47DF-8DF4-8AFF84125DD5@oracle.com> I think you have to build it (the sources are open source). We usually don't post documentation / samples onto any official place until after the release (lest the masses get confused I suppose). Richard On Mar 1, 2013, at 6:01 PM, "John C. Turnbull" wrote: > Is it available for download anywhere yet? > From ozemale at ozemail.com.au Fri Mar 1 18:32:19 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sat, 2 Mar 2013 13:32:19 +1100 Subject: Ensemble 8 In-Reply-To: <1273C2BD-6C59-47DF-8DF4-8AFF84125DD5@oracle.com> References: <00b501ce16e9$d3293fd0$797bbf70$@com.au> <1273C2BD-6C59-47DF-8DF4-8AFF84125DD5@oracle.com> Message-ID: <00ba01ce16ee$29d426c0$7d7c7440$@com.au> Thanks Richard. I suspected that would be the case :-) -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Saturday, 2 March 2013 13:23 To: John C. Turnbull Cc: openjfx-dev at openjdk.java.net Subject: Re: Ensemble 8 I think you have to build it (the sources are open source). We usually don't post documentation / samples onto any official place until after the release (lest the masses get confused I suppose). Richard On Mar 1, 2013, at 6:01 PM, "John C. Turnbull" wrote: > Is it available for download anywhere yet? > From hang.vo at oracle.com Fri Mar 1 18:34:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Mar 2013 02:34:09 +0000 Subject: hg: openjfx/8/controls/rt: Modena CSS cleanup of file. Message-ID: <20130302023414.4E77E477D5@hg.openjdk.java.net> Changeset: 8ee27ba99e2a Author: "Jasper Potts" Date: 2013-03-01 18:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8ee27ba99e2a Modena CSS cleanup of file. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Fri Mar 1 18:33:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Mar 2013 02:33:58 +0000 Subject: hg: openjfx/8/graphics/rt: Lots of work on the build script -- the tests now all compile. Abstracted some hardcoded values into settable properties (such as from Hudson). Added some logging. Fixed up the bootclasspath stuff (really hoping I got it this time!). Had to switch to 1.7 source because 1.8 tickles a compiler bug when compiling the tests. Message-ID: <20130302023405.0550D477D4@hg.openjdk.java.net> Changeset: 6faf8a3c2214 Author: rbair Date: 2013-03-01 18:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6faf8a3c2214 Lots of work on the build script -- the tests now all compile. Abstracted some hardcoded values into settable properties (such as from Hudson). Added some logging. Fixed up the bootclasspath stuff (really hoping I got it this time!). Had to switch to 1.7 source because 1.8 tickles a compiler bug when compiling the tests. ! build.gradle From herve.girod at gmail.com Sat Mar 2 05:09:52 2013 From: herve.girod at gmail.com (Herve Girod) Date: Sat, 2 Mar 2013 14:09:52 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application Message-ID: > > Hi, > > I'm developing a OpenGL based 3d application and instead of writing my > own ui code I'd like to reuse javafx for the ui part. > > Since getting an OpenGL context from JavaFX seems to be very complicated > (as discussed here) i thought about a different approach. > > What if javafx could reuse my rendering context. > I'm thinking of implementing a custom prism backend which renders within > my application context, after my content was rendered. > > As far as i know is the prism api is an internal implementation detail, > but it may be possible to ignore changes to it by bundling a specific > jre version with the application. > > I have not yet digged into prism code but I like to hear your thoughts > about this approach. > > greetings Christoph > > We also would like to integrate a JavaFX UI in an external OpenGL context. We already do it with regular Swing by leveraging JOGL and another OpenGL-AWT geom bridge library in our Open source project ( http://sourceforge.net/projects/j661/), but it's not so simple to to it well. It would be greate to be able to make JavaFX to work "easily" with other applications which also use OpenGL. Our use case is integrating Java graphics on top of an external context created by apps such as a flight simulator terrain rendering for example. We could also do it in Java of course, but often you have to use an existing OpenGL renderer for that. However for information it's not necessary to change the JDK to do this in Swing, even if it is not simple as I said. From swpalmer at gmail.com Sat Mar 2 10:56:41 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 2 Mar 2013 13:56:41 -0500 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: References: Message-ID: On 2013-03-02, at 8:09 AM, Herve Girod wrote: >> >> Hi, >> >> I'm developing a OpenGL based 3d application and instead of writing my >> own ui code I'd like to reuse javafx for the ui part. >> >> Since getting an OpenGL context from JavaFX seems to be very complicated >> (as discussed here) i thought about a different approach. >> >> What if javafx could reuse my rendering context. >> I'm thinking of implementing a custom prism backend which renders within >> my application context, after my content was rendered. >> >> As far as i know is the prism api is an internal implementation detail, >> but it may be possible to ignore changes to it by bundling a specific >> jre version with the application. >> >> I have not yet digged into prism code but I like to hear your thoughts >> about this approach. >> >> greetings Christoph >> >> > We also would like to integrate a JavaFX UI in an external OpenGL context. > We already do it with regular Swing by leveraging JOGL and another > OpenGL-AWT geom bridge library in our Open source project ( > http://sourceforge.net/projects/j661/), but it's not so simple to to it > well. It would be greate to be able to make JavaFX to work "easily" with > other applications which also use OpenGL. > > Our use case is integrating Java graphics on top of an external context > created by apps such as a flight simulator terrain rendering for example. > We could also do it in Java of course, but often you have to use an > existing OpenGL renderer for that. > > However for information it's not necessary to change the JDK to do this in > Swing, even if it is not simple as I said. I wonder if something as simple as using two windows would work. Your custom OpenGL window beneath a mostly transparent but otherwise ordinary JavaFX Stage. The issue of course is keeping the two windows paired up. That's one reason that I've been pushing for access to native window handles (via JNI-only so there are no security concerns). It would be awesome if we had the ability to make a window via native code that used our JavaFX window as it's parent. It *seems* like a simple thing to do, but it opens up a world of possibilities. Scott From herve.girod at gmail.com Sat Mar 2 13:18:54 2013 From: herve.girod at gmail.com (Herve Girod) Date: Sat, 2 Mar 2013 22:18:54 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: References: Message-ID: Yes we only need this kind of stuff via JNI of course. 2013/3/2 Scott Palmer > > On 2013-03-02, at 8:09 AM, Herve Girod wrote: > > >> > >> Hi, > >> > >> I'm developing a OpenGL based 3d application and instead of writing my > >> own ui code I'd like to reuse javafx for the ui part. > >> > >> Since getting an OpenGL context from JavaFX seems to be very complicated > >> (as discussed here) i thought about a different approach. > >> > >> What if javafx could reuse my rendering context. > >> I'm thinking of implementing a custom prism backend which renders within > >> my application context, after my content was rendered. > >> > >> As far as i know is the prism api is an internal implementation detail, > >> but it may be possible to ignore changes to it by bundling a specific > >> jre version with the application. > >> > >> I have not yet digged into prism code but I like to hear your thoughts > >> about this approach. > >> > >> greetings Christoph > >> > >> > > We also would like to integrate a JavaFX UI in an external OpenGL > context. > > We already do it with regular Swing by leveraging JOGL and another > > OpenGL-AWT geom bridge library in our Open source project ( > > http://sourceforge.net/projects/j661/), but it's not so simple to to it > > well. It would be greate to be able to make JavaFX to work "easily" with > > other applications which also use OpenGL. > > > > Our use case is integrating Java graphics on top of an external context > > created by apps such as a flight simulator terrain rendering for example. > > We could also do it in Java of course, but often you have to use an > > existing OpenGL renderer for that. > > > > However for information it's not necessary to change the JDK to do this > in > > Swing, even if it is not simple as I said. > > I wonder if something as simple as using two windows would work. Your > custom OpenGL window beneath a mostly transparent but otherwise ordinary > JavaFX Stage. The issue of course is keeping the two windows paired up. > That's one reason that I've been pushing for access to native window > handles (via JNI-only so there are no security concerns). It would be > awesome if we had the ability to make a window via native code that used > our JavaFX window as it's parent. > > It *seems* like a simple thing to do, but it opens up a world of > possibilities. > > > Scott > > From phdoerfler at gmail.com Sat Mar 2 13:30:15 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Sat, 2 Mar 2013 22:30:15 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: References: Message-ID: I'd be very interested in integrating pure OpenGL with JavaFX, too. I imagine that it might be possible to render either the existing OpenGL scene or the JavaFX scene into a framebuffer object with the same resolution and then to share it. The most important thing is that both share the same OpenGL context, though. Cheers, ~ Philipp Am 02.03.2013 um 22:18 schrieb Herve Girod : > Yes we only need this kind of stuff via JNI of course. > > 2013/3/2 Scott Palmer > >> >> On 2013-03-02, at 8:09 AM, Herve Girod wrote: >> >>>> >>>> Hi, >>>> >>>> I'm developing a OpenGL based 3d application and instead of writing my >>>> own ui code I'd like to reuse javafx for the ui part. >>>> >>>> Since getting an OpenGL context from JavaFX seems to be very complicated >>>> (as discussed here) i thought about a different approach. >>>> >>>> What if javafx could reuse my rendering context. >>>> I'm thinking of implementing a custom prism backend which renders within >>>> my application context, after my content was rendered. >>>> >>>> As far as i know is the prism api is an internal implementation detail, >>>> but it may be possible to ignore changes to it by bundling a specific >>>> jre version with the application. >>>> >>>> I have not yet digged into prism code but I like to hear your thoughts >>>> about this approach. >>>> >>>> greetings Christoph >>>> >>>> >>> We also would like to integrate a JavaFX UI in an external OpenGL >> context. >>> We already do it with regular Swing by leveraging JOGL and another >>> OpenGL-AWT geom bridge library in our Open source project ( >>> http://sourceforge.net/projects/j661/), but it's not so simple to to it >>> well. It would be greate to be able to make JavaFX to work "easily" with >>> other applications which also use OpenGL. >>> >>> Our use case is integrating Java graphics on top of an external context >>> created by apps such as a flight simulator terrain rendering for example. >>> We could also do it in Java of course, but often you have to use an >>> existing OpenGL renderer for that. >>> >>> However for information it's not necessary to change the JDK to do this >> in >>> Swing, even if it is not simple as I said. >> >> I wonder if something as simple as using two windows would work. Your >> custom OpenGL window beneath a mostly transparent but otherwise ordinary >> JavaFX Stage. The issue of course is keeping the two windows paired up. >> That's one reason that I've been pushing for access to native window >> handles (via JNI-only so there are no security concerns). It would be >> awesome if we had the ability to make a window via native code that used >> our JavaFX window as it's parent. >> >> It *seems* like a simple thing to do, but it opens up a world of >> possibilities. >> >> >> Scott >> >> From ccaks at bestsolution.at Sat Mar 2 12:46:27 2013 From: ccaks at bestsolution.at (Christoph Caks) Date: Sat, 02 Mar 2013 21:46:27 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: References: Message-ID: <51326523.4020801@bestsolution.at> Am 02.03.2013 19:56, schrieb Scott Palmer: > > On 2013-03-02, at 8:09 AM, Herve Girod wrote: > >>> >>> Hi, >>> >>> I'm developing a OpenGL based 3d application and instead of writing my >>> own ui code I'd like to reuse javafx for the ui part. >>> >>> Since getting an OpenGL context from JavaFX seems to be very complicated >>> (as discussed here) i thought about a different approach. >>> >>> What if javafx could reuse my rendering context. >>> I'm thinking of implementing a custom prism backend which renders within >>> my application context, after my content was rendered. >>> >>> As far as i know is the prism api is an internal implementation detail, >>> but it may be possible to ignore changes to it by bundling a specific >>> jre version with the application. >>> >>> I have not yet digged into prism code but I like to hear your thoughts >>> about this approach. >>> >>> greetings Christoph >>> >>> >> We also would like to integrate a JavaFX UI in an external OpenGL context. >> We already do it with regular Swing by leveraging JOGL and another >> OpenGL-AWT geom bridge library in our Open source project ( >> http://sourceforge.net/projects/j661/), but it's not so simple to to it >> well. It would be greate to be able to make JavaFX to work "easily" with >> other applications which also use OpenGL. >> >> Our use case is integrating Java graphics on top of an external context >> created by apps such as a flight simulator terrain rendering for example. >> We could also do it in Java of course, but often you have to use an >> existing OpenGL renderer for that. >> >> However for information it's not necessary to change the JDK to do this in >> Swing, even if it is not simple as I said. > > I wonder if something as simple as using two windows would work. Your custom OpenGL window beneath a mostly transparent but otherwise ordinary JavaFX Stage. The issue of course is keeping the two windows paired up. That's one reason that I've been pushing for access to native window handles (via JNI-only so there are no security concerns). It would be awesome if we had the ability to make a window via native code that used our JavaFX window as it's parent. > > It *seems* like a simple thing to do, but it opens up a world of possibilities. > > > Scott > In windows this would mean you have an directx javafx stage on top of an opengl based application - i have no idea how those two affect each other in terms of performance since they need to share a single graphics card. i don't like the idea to use an additional graphics system like directx for rendering the ui of an opengl based application. I'm trying to write my own jogl based prism pipeline and made some progress: i already 'injected' my pipline and got some things running, but i'm still trying to render a simple rectangle. As far as i know oracles first es2 implementation was also jogl based - its a pity that this code is not opensource, it would speed things up -.- And even if i succeed in implementing a working pipeline - i still face some problems: - i'll have to keep it compatible with changes in the internal prism api - and the only way (i found so far) to inject it, is to place a jar into the ext folder of the jre - also i have no idea about legal issues - is it for example allowed to bundle a patched jre with my application? (patched = additional jars in ext folder) Christoph From herve.girod at gmail.com Sat Mar 2 14:14:53 2013 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Sat, 2 Mar 2013 23:14:53 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: <51326523.4020801@bestsolution.at> References: <51326523.4020801@bestsolution.at> Message-ID: <56079768-7CF7-49F8-9994-AA3110AEA38E@gmail.com> We did not need anything special with our Swing OpenGL renderer. We "only" had to reuse a custom Graphics2D which performed OpenGL calls, and pass it the right context. Of course it meant that Java was in this case not any more in charge of when the repainting was performed. However I don't know Prism rendering architecture, so this same approach might not work. Herv? Sent from my iPhone On 2 mars 2013, at 21:46, Christoph Caks wrote: > Am 02.03.2013 19:56, schrieb Scott Palmer: >> >> On 2013-03-02, at 8:09 AM, Herve Girod wrote: >> >>>> >>>> Hi, >>>> >>>> I'm developing a OpenGL based 3d application and instead of writing my >>>> own ui code I'd like to reuse javafx for the ui part. >>>> >>>> Since getting an OpenGL context from JavaFX seems to be very complicated >>>> (as discussed here) i thought about a different approach. >>>> >>>> What if javafx could reuse my rendering context. >>>> I'm thinking of implementing a custom prism backend which renders within >>>> my application context, after my content was rendered. >>>> >>>> As far as i know is the prism api is an internal implementation detail, >>>> but it may be possible to ignore changes to it by bundling a specific >>>> jre version with the application. >>>> >>>> I have not yet digged into prism code but I like to hear your thoughts >>>> about this approach. >>>> >>>> greetings Christoph >>> We also would like to integrate a JavaFX UI in an external OpenGL context. >>> We already do it with regular Swing by leveraging JOGL and another >>> OpenGL-AWT geom bridge library in our Open source project ( >>> http://sourceforge.net/projects/j661/), but it's not so simple to to it >>> well. It would be greate to be able to make JavaFX to work "easily" with >>> other applications which also use OpenGL. >>> >>> Our use case is integrating Java graphics on top of an external context >>> created by apps such as a flight simulator terrain rendering for example. >>> We could also do it in Java of course, but often you have to use an >>> existing OpenGL renderer for that. >>> >>> However for information it's not necessary to change the JDK to do this in >>> Swing, even if it is not simple as I said. >> >> I wonder if something as simple as using two windows would work. Your custom OpenGL window beneath a mostly transparent but otherwise ordinary JavaFX Stage. The issue of course is keeping the two windows paired up. That's one reason that I've been pushing for access to native window handles (via JNI-only so there are no security concerns). It would be awesome if we had the ability to make a window via native code that used our JavaFX window as it's parent. >> >> It *seems* like a simple thing to do, but it opens up a world of possibilities. >> >> >> Scott > > In windows this would mean you have an directx javafx stage on top of an opengl based application - i have no idea how those two affect each other in terms of performance since they need to share a single graphics card. > i don't like the idea to use an additional graphics system like directx for rendering the ui of an opengl based application. > > > I'm trying to write my own jogl based prism pipeline and made some progress: i already 'injected' my pipline and got some things running, but i'm still trying to render a simple rectangle. > > As far as i know oracles first es2 implementation was also jogl based - its a pity that this code is not opensource, it would speed things up -.- > > And even if i succeed in implementing a working pipeline - i still face some problems: > - i'll have to keep it compatible with changes in the internal prism api > - and the only way (i found so far) to inject it, is to place a jar into the ext folder of the jre > - also i have no idea about legal issues - is it for example allowed to bundle a patched jre with my application? (patched = additional jars in ext folder) > > > Christoph From ccaks at bestsolution.at Sat Mar 2 13:56:59 2013 From: ccaks at bestsolution.at (Christoph Caks) Date: Sat, 02 Mar 2013 22:56:59 +0100 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: <56079768-7CF7-49F8-9994-AA3110AEA38E@gmail.com> References: <51326523.4020801@bestsolution.at> <56079768-7CF7-49F8-9994-AA3110AEA38E@gmail.com> Message-ID: <513275AB.4000807@bestsolution.at> Am 02.03.2013 23:14, schrieb Herv? Girod: > We did not need anything special with our Swing OpenGL renderer. We "only" had to reuse a custom Graphics2D which performed OpenGL calls, and pass it the right context. Of course it meant that Java was in this case not any more in charge of when the repainting was performed. > > However I don't know Prism rendering architecture, so this same approach might not work. > > Herv? Basically this is the same approach. But afaik for javafx you need a custom prism pipeline to delegate the rendering to wherever you need it. Prism is not part of the public api, while swings Graphics2D interface is. Only the top layer of the javafx stack (mainly the scene graph) is exposed as public api, and everything below is an internal implementation detail. Christoph > > Sent from my iPhone > > On 2 mars 2013, at 21:46, Christoph Caks wrote: > >> Am 02.03.2013 19:56, schrieb Scott Palmer: >>> >>> On 2013-03-02, at 8:09 AM, Herve Girod wrote: >>> >>>>> >>>>> Hi, >>>>> >>>>> I'm developing a OpenGL based 3d application and instead of writing my >>>>> own ui code I'd like to reuse javafx for the ui part. >>>>> >>>>> Since getting an OpenGL context from JavaFX seems to be very complicated >>>>> (as discussed here) i thought about a different approach. >>>>> >>>>> What if javafx could reuse my rendering context. >>>>> I'm thinking of implementing a custom prism backend which renders within >>>>> my application context, after my content was rendered. >>>>> >>>>> As far as i know is the prism api is an internal implementation detail, >>>>> but it may be possible to ignore changes to it by bundling a specific >>>>> jre version with the application. >>>>> >>>>> I have not yet digged into prism code but I like to hear your thoughts >>>>> about this approach. >>>>> >>>>> greetings Christoph >>>> We also would like to integrate a JavaFX UI in an external OpenGL context. >>>> We already do it with regular Swing by leveraging JOGL and another >>>> OpenGL-AWT geom bridge library in our Open source project ( >>>> http://sourceforge.net/projects/j661/), but it's not so simple to to it >>>> well. It would be greate to be able to make JavaFX to work "easily" with >>>> other applications which also use OpenGL. >>>> >>>> Our use case is integrating Java graphics on top of an external context >>>> created by apps such as a flight simulator terrain rendering for example. >>>> We could also do it in Java of course, but often you have to use an >>>> existing OpenGL renderer for that. >>>> >>>> However for information it's not necessary to change the JDK to do this in >>>> Swing, even if it is not simple as I said. >>> >>> I wonder if something as simple as using two windows would work. Your custom OpenGL window beneath a mostly transparent but otherwise ordinary JavaFX Stage. The issue of course is keeping the two windows paired up. That's one reason that I've been pushing for access to native window handles (via JNI-only so there are no security concerns). It would be awesome if we had the ability to make a window via native code that used our JavaFX window as it's parent. >>> >>> It *seems* like a simple thing to do, but it opens up a world of possibilities. >>> >>> >>> Scott >> >> In windows this would mean you have an directx javafx stage on top of an opengl based application - i have no idea how those two affect each other in terms of performance since they need to share a single graphics card. >> i don't like the idea to use an additional graphics system like directx for rendering the ui of an opengl based application. >> >> >> I'm trying to write my own jogl based prism pipeline and made some progress: i already 'injected' my pipline and got some things running, but i'm still trying to render a simple rectangle. >> >> As far as i know oracles first es2 implementation was also jogl based - its a pity that this code is not opensource, it would speed things up -.- >> >> And even if i succeed in implementing a working pipeline - i still face some problems: >> - i'll have to keep it compatible with changes in the internal prism api >> - and the only way (i found so far) to inject it, is to place a jar into the ext folder of the jre >> - also i have no idea about legal issues - is it for example allowed to bundle a patched jre with my application? (patched = additional jars in ext folder) >> >> >> Christoph From jasper.potts at oracle.com Sat Mar 2 17:01:02 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Sat, 2 Mar 2013 17:01:02 -0800 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: <51326523.4020801@bestsolution.at> References: <51326523.4020801@bestsolution.at> Message-ID: We have DirectX, OpenGL and Software implementations of Prism. We use OpenGL on Mac and Linux. It is sometimes run on Windows by the Graphics team for their own development but it is not supported on Windows and is often broken. We are working on open sourcing all of prism so if its not there yet it will be as soon as we can. We are also been talking about ideas of giving low level access for integrating pure OpenGL or other native stuff. No hard plans yet but we at least are thinking this would be a problem we would like to solve. Jasper On Mar 2, 2013, at 12:46 PM, Christoph Caks wrote: > Am 02.03.2013 19:56, schrieb Scott Palmer: >> >> On 2013-03-02, at 8:09 AM, Herve Girod wrote: >> >>>> >>>> Hi, >>>> >>>> I'm developing a OpenGL based 3d application and instead of writing my >>>> own ui code I'd like to reuse javafx for the ui part. >>>> >>>> Since getting an OpenGL context from JavaFX seems to be very complicated >>>> (as discussed here) i thought about a different approach. >>>> >>>> What if javafx could reuse my rendering context. >>>> I'm thinking of implementing a custom prism backend which renders within >>>> my application context, after my content was rendered. >>>> >>>> As far as i know is the prism api is an internal implementation detail, >>>> but it may be possible to ignore changes to it by bundling a specific >>>> jre version with the application. >>>> >>>> I have not yet digged into prism code but I like to hear your thoughts >>>> about this approach. >>>> >>>> greetings Christoph >>> We also would like to integrate a JavaFX UI in an external OpenGL context. >>> We already do it with regular Swing by leveraging JOGL and another >>> OpenGL-AWT geom bridge library in our Open source project ( >>> http://sourceforge.net/projects/j661/), but it's not so simple to to it >>> well. It would be greate to be able to make JavaFX to work "easily" with >>> other applications which also use OpenGL. >>> >>> Our use case is integrating Java graphics on top of an external context >>> created by apps such as a flight simulator terrain rendering for example. >>> We could also do it in Java of course, but often you have to use an >>> existing OpenGL renderer for that. >>> >>> However for information it's not necessary to change the JDK to do this in >>> Swing, even if it is not simple as I said. >> >> I wonder if something as simple as using two windows would work. Your custom OpenGL window beneath a mostly transparent but otherwise ordinary JavaFX Stage. The issue of course is keeping the two windows paired up. That's one reason that I've been pushing for access to native window handles (via JNI-only so there are no security concerns). It would be awesome if we had the ability to make a window via native code that used our JavaFX window as it's parent. >> >> It *seems* like a simple thing to do, but it opens up a world of possibilities. >> >> >> Scott > > In windows this would mean you have an directx javafx stage on top of an opengl based application - i have no idea how those two affect each other in terms of performance since they need to share a single graphics card. > i don't like the idea to use an additional graphics system like directx for rendering the ui of an opengl based application. > > > I'm trying to write my own jogl based prism pipeline and made some progress: i already 'injected' my pipline and got some things running, but i'm still trying to render a simple rectangle. > > As far as i know oracles first es2 implementation was also jogl based - its a pity that this code is not opensource, it would speed things up -.- > > And even if i succeed in implementing a working pipeline - i still face some problems: > - i'll have to keep it compatible with changes in the internal prism api > - and the only way (i found so far) to inject it, is to place a jar into the ext folder of the jre > - also i have no idea about legal issues - is it for example allowed to bundle a patched jre with my application? (patched = additional jars in ext folder) > > > Christoph From thekonradzuse at hotmail.com Sat Mar 2 17:06:01 2013 From: thekonradzuse at hotmail.com (Konrad Zuse) Date: Sat, 2 Mar 2013 20:06:01 -0500 Subject: Why is there no x, y, and z coordinate for box? As well as possibly other 3D Shapes? Message-ID: I am happy with the new additions of 3D shapes, however there is no setting there positions. I know there was an issue of where do we start x,y,z is it at top left, or middle. It seems that using relocate(x,y) works for now, but there is no z, so I would have to do z translations. I think location setting is important for all shapes we will use. From swpalmer at gmail.com Sat Mar 2 17:19:49 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 2 Mar 2013 20:19:49 -0500 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: <51326523.4020801@bestsolution.at> References: <51326523.4020801@bestsolution.at> Message-ID: <6E73EF8D-F5F1-4774-A768-C66EAC1E2CB2@gmail.com> On 2013-03-02, at 3:46 PM, Christoph Caks wrote: > Am 02.03.2013 19:56, schrieb Scott Palmer: >> >> On 2013-03-02, at 8:09 AM, Herve Girod wrote: >> >>>> >>>> Hi, >>>> >>>> I'm developing a OpenGL based 3d application and instead of writing my >>>> own ui code I'd like to reuse javafx for the ui part. >>>> >>>> Since getting an OpenGL context from JavaFX seems to be very complicated >>>> (as discussed here) i thought about a different approach. >>>> >>>> What if javafx could reuse my rendering context. >>>> I'm thinking of implementing a custom prism backend which renders within >>>> my application context, after my content was rendered. >>>> >>>> As far as i know is the prism api is an internal implementation detail, >>>> but it may be possible to ignore changes to it by bundling a specific >>>> jre version with the application. >>>> >>>> I have not yet digged into prism code but I like to hear your thoughts >>>> about this approach. >>>> >>>> greetings Christoph >>>> >>>> >>> We also would like to integrate a JavaFX UI in an external OpenGL context. >>> We already do it with regular Swing by leveraging JOGL and another >>> OpenGL-AWT geom bridge library in our Open source project ( >>> http://sourceforge.net/projects/j661/), but it's not so simple to to it >>> well. It would be greate to be able to make JavaFX to work "easily" with >>> other applications which also use OpenGL. >>> >>> Our use case is integrating Java graphics on top of an external context >>> created by apps such as a flight simulator terrain rendering for example. >>> We could also do it in Java of course, but often you have to use an >>> existing OpenGL renderer for that. >>> >>> However for information it's not necessary to change the JDK to do this in >>> Swing, even if it is not simple as I said. >> >> I wonder if something as simple as using two windows would work. Your custom OpenGL window beneath a mostly transparent but otherwise ordinary JavaFX Stage. The issue of course is keeping the two windows paired up. That's one reason that I've been pushing for access to native window handles (via JNI-only so there are no security concerns). It would be awesome if we had the ability to make a window via native code that used our JavaFX window as it's parent. >> >> It *seems* like a simple thing to do, but it opens up a world of possibilities. >> >> >> Scott >> > > In windows this would mean you have an directx javafx stage on top of an opengl based application - i have no idea how those two affect each other in terms of performance since they need to share a single graphics card. I don't have a good idea either, but it should be easy to find out. I personally don't know why Java, being a cross platform system, would bother with DirectX when OpenGL is already cross-platform. I've heard that the DirectX (Direct3D) drivers are usually more polished on Windows? sadly choosing Direct3D leads to a feedback cycle that ensures that will always be the case. (Reminds me of this: http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX ) > i don't like the idea to use an additional graphics system like directx for rendering the ui of an opengl based application. > I'm trying to write my own jogl based prism pipeline and made some progress: i already 'injected' my pipline and got some things running, but i'm still trying to render a simple rectangle. > > As far as i know oracles first es2 implementation was also jogl based - its a pity that this code is not opensource, it would speed things up -.- Presumably you can look at the Linux and Mac versions that are open sourced, since they would have to use OpenGL for hardware acceleration. > And even if i succeed in implementing a working pipeline - i still face some problems: > - i'll have to keep it compatible with changes in the internal prism api > - and the only way (i found so far) to inject it, is to place a jar into the ext folder of the jre > - also i have no idea about legal issues - is it for example allowed to bundle a patched jre with my application? (patched = additional jars in ext folder) If you are basing this on Open-JFX you just have to comply with the open source license. I am not a lawyer, but I think that means you can have a hacked up Java, as long as you don't call it Java. (Since you would not have gone through the process of passing compatibility tests and all that stuff.) Scott From swpalmer at gmail.com Sat Mar 2 17:27:38 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 2 Mar 2013 20:27:38 -0500 Subject: Integrating javafx ui into custom (jogl based) OpenGL application In-Reply-To: References: <51326523.4020801@bestsolution.at> Message-ID: <187F994B-6CAE-4A84-9CAE-8D50ABF1FA67@gmail.com> On 2013-03-02, at 8:01 PM, Jasper Potts wrote: > We have DirectX, OpenGL and Software implementations of Prism. We use OpenGL on Mac and Linux. It is sometimes run on Windows by the Graphics team for their own development but it is not supported on Windows and is often broken. We are working on open sourcing all of prism so if its not there yet it will be as soon as we can. > Looks like only the software renderer is available so-far based on this commit: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1007001aa197 > We are also been talking about ideas of giving low level access for integrating pure OpenGL or other native stuff. No hard plans yet but we at least are thinking this would be a problem we would like to solve. Awesome. In terms of "other native stuff" - how about access to the window handle of the Stage? (Via JNI so there are no security concerns.) Scott From jasper.potts at oracle.com Sat Mar 2 20:03:42 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Sat, 2 Mar 2013 20:03:42 -0800 Subject: Why is there no x, y, and z coordinate for box? As well as possibly other 3D Shapes? In-Reply-To: References: Message-ID: You can use setTranslateX(..) Y and Z the same. Jasper Sent from my iPhone On Mar 2, 2013, at 5:06 PM, Konrad Zuse wrote: > I am happy with the new additions of 3D shapes, however there is no setting there positions. I know there was an issue of where do we start x,y,z is it at top left, or middle. It seems that using relocate(x,y) works for now, but there is no z, so I would have to do z translations. I think location setting is important for all shapes we will use. From hang.vo at oracle.com Sat Mar 2 23:34:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 03 Mar 2013 07:34:02 +0000 Subject: hg: openjfx/8/controls/rt: RT-28367 Clean up AccessibleList, AccessibleListItem; RT-28419 Slider knob rendered outside Message-ID: <20130303073417.06E89477EF@hg.openjdk.java.net> Changeset: 7f9c1f256882 Author: Paru Somashekar Date: 2013-03-02 23:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7f9c1f256882 RT-28367 Clean up AccessibleList, AccessibleListItem; RT-28419 Slider knob rendered outside RT-26025 ChoiceBox right click opens both popup and context menu. ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleList.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleListItem.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java From hang.vo at oracle.com Sun Mar 3 01:48:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 03 Mar 2013 09:48:52 +0000 Subject: hg: openjfx/8/controls/rt: RT-26025, removed debug output left behind by accident. Message-ID: <20130303094900.B500E477F2@hg.openjdk.java.net> Changeset: 7a0dc6ed9c7b Author: Paru Somashekar Date: 2013-03-03 01:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7a0dc6ed9c7b RT-26025, removed debug output left behind by accident. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java From hang.vo at oracle.com Sun Mar 3 08:33:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 03 Mar 2013 16:33:54 +0000 Subject: hg: openjfx/8/graphics/rt: Build GTK in cross builds as well as host builds Message-ID: <20130303163405.E89C3477F4@hg.openjdk.java.net> Changeset: 9134330dc4e0 Author: Daniel Blaukopf Date: 2013-03-03 18:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9134330dc4e0 Build GTK in cross builds as well as host builds ! glass/build-common.xml ! glass/glass-lib-gtk/build.xml From hang.vo at oracle.com Mon Mar 4 02:48:20 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 10:48:20 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25559: Allow event handlers to come from the namespace; better error message, tests added to the suite; minor rename; license update Message-ID: <20130304104826.C266847802@hg.openjdk.java.net> Changeset: f200832fb53a Author: Milan Kubec Date: 2013-03-04 10:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f200832fb53a RT-25559: Allow event handlers to come from the namespace; better error message, tests added to the suite; minor rename; license update ! javafx-fxml/src/javafx/fxml/FXMLLoader.java - javafx-fxml/test/javafx/fxml/RT_25559.java + javafx-fxml/test/javafx/fxml/RT_25559Test.java ! javafx-fxml/test/javafx/fxml/rt_25559.fxml + javafx-fxml/test/javafx/fxml/rt_25559_err1.fxml From hang.vo at oracle.com Mon Mar 4 03:18:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 11:18:11 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20130304111823.42ED647803@hg.openjdk.java.net> Changeset: 3e43e2361e9a Author: Martin Sladecek Date: 2013-03-04 12:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e43e2361e9a [TEST] new tests for ListChangeListener.Change implementations. + javafx-beans/test/com/sun/javafx/collections/MappingChangeTest.java + javafx-beans/test/com/sun/javafx/collections/NonIterableChangeTest.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java Changeset: 392abf0df66f Author: Martin Sladecek Date: 2013-03-04 12:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/392abf0df66f merge - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 63c947b7d28a Author: Martin Sladecek Date: 2013-03-04 12:03 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/63c947b7d28a merge From hang.vo at oracle.com Mon Mar 4 05:17:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 13:17:56 +0000 Subject: hg: openjfx/8/graphics/rt: RT-27589: JavaFXBuilderFactory has a strong dependency on webnode Message-ID: <20130304131802.4F43A47804@hg.openjdk.java.net> Changeset: 171ff8b064e2 Author: Milan Kubec Date: 2013-03-04 12:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/171ff8b064e2 RT-27589: JavaFXBuilderFactory has a strong dependency on webnode ! javafx-fxml/nbproject/project.xml ! javafx-fxml/src/javafx/fxml/JavaFXBuilderFactory.java - javafx-fxml/test/javafx/fxml/RT_23519.java + javafx-fxml/test/javafx/fxml/RT_23519Test.java ! javafx-fxml/test/javafx/fxml/rt_23519.fxml From hang.vo at oracle.com Mon Mar 4 11:18:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 19:18:00 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: don't crash if source file is not available Message-ID: <20130304191812.072654781B@hg.openjdk.java.net> Changeset: 29787a06e0de Author: snorthov Date: 2013-03-04 14:04 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29787a06e0de Ensemble8: don't crash if source file is not available ! apps/samples/Ensemble8/src/app/ensemble/util/Utils.java From hang.vo at oracle.com Mon Mar 4 14:04:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 22:04:24 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130304220440.4F8FD47822@hg.openjdk.java.net> Changeset: 0eb24b573aec Author: David Grieve Date: 2013-03-04 16:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0eb24b573aec RT-28768: when looking up parent cache entry for inherited font, if parent cache entry's font is null, find the font to use. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: f4857dbc5287 Author: David Grieve Date: 2013-03-04 16:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f4857dbc5287 RT-28769: check for null styleHelper in impl_getStyleMap and impl_setStyleMap ! javafx-ui-common/src/javafx/scene/Node.java From hang.vo at oracle.com Mon Mar 4 14:18:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 22:18:11 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130304221831.398E247823@hg.openjdk.java.net> Changeset: c99b1563212f Author: "Jasper Potts" Date: 2013-03-04 11:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c99b1563212f Modena test app, added pill buttons same text example ! apps/experiments/Modena/src/modena/SamplePage.java Changeset: 6d47b9a930db Author: "Jasper Potts" Date: 2013-03-04 11:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6d47b9a930db Modena UI tweeks ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: f4c5ee1d15b1 Author: "Jasper Potts" Date: 2013-03-04 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f4c5ee1d15b1 Modena make chart legened more subtle. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 044e79cda8fe Author: "Jasper Potts" Date: 2013-03-04 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/044e79cda8fe MERGE AFTER : Modena make chart legened more subtle. From hang.vo at oracle.com Mon Mar 4 14:32:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 22:32:58 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130304223307.8022547824@hg.openjdk.java.net> Changeset: 13c375a722d0 Author: David Grieve Date: 2013-03-04 17:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/13c375a722d0 RT-28760: list of ua stylesheets might contain nulls ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 6240fcb97940 Author: David Grieve Date: 2013-03-04 17:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6240fcb97940 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt From hang.vo at oracle.com Mon Mar 4 15:33:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Mar 2013 23:33:03 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130304233316.8DC4A47825@hg.openjdk.java.net> Changeset: fd3743c5c84d Author: "Jasper Potts" Date: 2013-03-04 15:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fd3743c5c84d Modena chart gridlines making dashed in both H and V as feels better ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 649ecc9fc736 Author: "Jasper Potts" Date: 2013-03-04 15:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/649ecc9fc736 Merge From david.hill at oracle.com Mon Mar 4 15:43:41 2013 From: david.hill at oracle.com (david.hill at oracle.com) Date: Mon, 04 Mar 2013 23:43:41 +0000 Subject: hg: openjfx/8/graphics: RT-28431 Initial support for crossbuilding. Message-ID: <20130304234341.B3B9047826@hg.openjdk.java.net> Changeset: 0aa99c6657c9 Author: David Hill Date: 2013-03-04 18:43 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rev/0aa99c6657c9 RT-28431 Initial support for crossbuilding. ! .hgignore ! build-defs.xml + build-src/build-cross.xml + build-src/platform/raspberry-pi.properties From hang.vo at oracle.com Mon Mar 4 16:18:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 00:18:06 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed up tests for Gradle build. Now all the tests run and pass. Message-ID: <20130305001812.7AD0347827@hg.openjdk.java.net> Changeset: b11664e10c75 Author: rbair Date: 2013-03-04 16:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b11664e10c75 Fixed up tests for Gradle build. Now all the tests run and pass. ! build.gradle ! generator.gradle From hang.vo at oracle.com Mon Mar 4 17:18:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 01:18:00 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed exclude login in stub toolkit tests for Gradle Build Message-ID: <20130305011805.E045D47828@hg.openjdk.java.net> Changeset: b47611118080 Author: rbair Date: 2013-03-04 17:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b47611118080 Fixed exclude login in stub toolkit tests for Gradle Build ! build.gradle From hang.vo at oracle.com Mon Mar 4 18:03:13 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 02:03:13 +0000 Subject: hg: openjfx/8/controls/rt: Modena: fix toolbars anding support for right and bottom styleclasses for special cases. Added spacing for overflow arrow when vertical. Modena app added test cases for RIGHT and BOTTOM toolbars. Modena App added refresh support for stylesheet when running from IntelliJ Message-ID: <20130305020321.0D60347829@hg.openjdk.java.net> Changeset: 0973fa2d0c6f Author: "Jasper Potts" Date: 2013-03-04 17:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0973fa2d0c6f Modena: fix toolbars anding support for right and bottom styleclasses for special cases. Added spacing for overflow arrow when vertical. Modena app added test cases for RIGHT and BOTTOM toolbars. Modena App added refresh support for stylesheet when running from IntelliJ ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Mon Mar 4 22:18:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 06:18:06 +0000 Subject: hg: openjfx/8/controls/rt: 7 new changesets Message-ID: <20130305061833.247B047834@hg.openjdk.java.net> Changeset: 959641c9fede Author: jgiles Date: 2013-03-01 09:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/959641c9fede RT-28668: Ensemble tree arrow disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 19a14723a52d Author: jgiles Date: 2013-03-02 19:11 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/19a14723a52d RT-22463: It should be possible to clear a TableView items list, and subsequently set a new items list in a TableView where the contents are considered equal (that is, equals() returns true), with the expectation that the new text is displayed rather than the old text (by the fact that the old items were first cleared out - if they weren't then we would still likely see the old items). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: 8a3b4ebaa2be Author: jgiles Date: 2013-03-02 19:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8a3b4ebaa2be Slight update for RT-28668: Ensemble tree arrow disappears (plays nicer with the CSS engine now). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: c3376fd7fd9a Author: jgiles Date: 2013-03-05 11:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c3376fd7fd9a Finishing off unit tests for RT-22463 for ListView, TreeView, TableView and TreeTableView ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java + javafx-ui-controls/test/com/sun/javafx/scene/control/test/RT_22463_Person.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: f77115aa3398 Author: jgiles Date: 2013-03-05 11:19 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f77115aa3398 Added (currently @Ignore'd) unit tests for RT-28637: [ListView, TreeView, TableView, TreeTableView] selectionModel selectedItem returns wrong item. ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: d50ad13e2f3c Author: jgiles Date: 2013-03-05 19:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d50ad13e2f3c Adding (currently @Ignore'd) unit tests for RT-28615: ListChangeListener on MultipleSelectionModel selectedItems does not always report correct item added. ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java Changeset: ece1fe2f059b Author: jgiles Date: 2013-03-05 19:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ece1fe2f059b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Tue Mar 5 04:18:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 12:18:01 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28784: Accessibility of methods in FXMLLoader unintentionally changed to protected Message-ID: <20130305121810.37CD34783E@hg.openjdk.java.net> Changeset: cb061795e1f7 Author: Milan Kubec Date: 2013-03-05 12:12 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cb061795e1f7 RT-28784: Accessibility of methods in FXMLLoader unintentionally changed to protected ! javafx-fxml/src/javafx/fxml/FXMLLoader.java From hang.vo at oracle.com Tue Mar 5 07:04:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 15:04:08 +0000 Subject: hg: openjfx/8/controls/rt: RT-28773 : BarChart empty space on axis Message-ID: <20130305150414.AFCC147844@hg.openjdk.java.net> Changeset: ab59ba026313 Author: Paru Somashekar Date: 2013-03-05 06:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ab59ba026313 RT-28773 : BarChart empty space on axis ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java From hang.vo at oracle.com Tue Mar 5 08:33:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 16:33:17 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28749 Ensemble8: add to internal build Message-ID: <20130305163324.306F94784B@hg.openjdk.java.net> Changeset: 4620dab2c1ac Author: dmasada Date: 2013-03-05 08:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4620dab2c1ac RT-28749 Ensemble8: add to internal build + apps/build-defs.xml + apps/build.xml ! apps/samples/Ensemble8/nbproject/project.properties + apps/samples/build.xml From hang.vo at oracle.com Tue Mar 5 10:18:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 18:18:03 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-28796 NPE in Ensemble8 Message-ID: <20130305181807.2FE2847856@hg.openjdk.java.net> Changeset: 008bdab5b9fb Author: Alexander Kouznetsov Date: 2013-03-05 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/008bdab5b9fb Ensemble8: Fix for RT-28796 NPE in Ensemble8 ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java From hang.vo at oracle.com Tue Mar 5 11:17:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 19:17:57 +0000 Subject: hg: openjfx/8/controls/rt: RT-28052 : optimise converters Message-ID: <20130305191801.2098D47857@hg.openjdk.java.net> Changeset: 3e08d75e32a1 Author: mickf Date: 2013-03-05 19:05 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3e08d75e32a1 RT-28052 : optimise converters ! javafx-ui-common/src/com/sun/javafx/css/ParsedValueImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/converters/EnumConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/RepeatStructConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java From hang.vo at oracle.com Tue Mar 5 14:48:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Mar 2013 22:48:39 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130305224848.7112147866@hg.openjdk.java.net> Changeset: 9170500c6400 Author: David Grieve Date: 2013-03-05 17:32 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9170500c6400 RT-28022: fix url resolution for @font-face ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: f4bbc8b8b78c Author: David Grieve Date: 2013-03-05 17:32 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f4bbc8b8b78c RT-28769: follow on fixes after feedback from scene builder folks. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java From hang.vo at oracle.com Wed Mar 6 00:03:21 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 08:03:21 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble3: Fix for RT-28257 Ensemble3: XYChart Visualization in TreeTableView doesn't update on underlying data update Message-ID: <20130306080328.2F96047883@hg.openjdk.java.net> Changeset: 14df3baed0f8 Author: Alexander Kouznetsov Date: 2013-03-05 23:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/14df3baed0f8 Ensemble3: Fix for RT-28257 Ensemble3: XYChart Visualization in TreeTableView doesn't update on underlying data update ! apps/samples/Ensemble8/src/app/ensemble/samplepage/XYDataVisualizer.java From hang.vo at oracle.com Wed Mar 6 00:18:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 08:18:29 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28797: Fixed NPE when picking node clipped by a node with pickOnBounds set to true. Message-ID: <20130306081833.4973547884@hg.openjdk.java.net> Changeset: 57f5d847140b Author: Pavel Safrata Date: 2013-03-06 08:10 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/57f5d847140b RT-28797: Fixed NPE when picking node clipped by a node with pickOnBounds set to true. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/PickAndContainsTest.java From hang.vo at oracle.com Wed Mar 6 04:04:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 12:04:01 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28636 ObservableLists has wrong order of notification types Message-ID: <20130306120410.02C9147894@hg.openjdk.java.net> Changeset: dd17e3699d72 Author: Martin Sladecek Date: 2013-03-06 12:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd17e3699d72 RT-28636 ObservableLists has wrong order of notification types ! javafx-beans/src/javafx/collections/ListChangeBuilder.java ! javafx-beans/src/javafx/collections/ListChangeListener.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java From hang.vo at oracle.com Wed Mar 6 04:18:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 12:18:39 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28537 Bidirectional Binding does not maintain the invariant if one of the properties is bound Message-ID: <20130306121846.8448647895@hg.openjdk.java.net> Changeset: 7fa12f6c2e16 Author: Martin Sladecek Date: 2013-03-06 13:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7fa12f6c2e16 RT-28537 Bidirectional Binding does not maintain the invariant if one of the properties is bound ! javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java ! javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingTest.java From alexander.zvegintsev at oracle.com Wed Mar 6 05:03:43 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 06 Mar 2013 17:03:43 +0400 Subject: [API Review]: RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes Message-ID: <51373EAF.9050709@oracle.com> Hi all, In order to fix http://javafx-jira.kenai.com/browse/RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes we need to extend API of FileChooser: public final ExtensionFilter getSelectedExtensionFilter() Returns selected ExtensionFilter of last displayed file dialog. It may be null if not supported by platform or dialog canceled. -- Thanks, Alexander. From hang.vo at oracle.com Wed Mar 6 06:03:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 14:03:24 +0000 Subject: hg: openjfx/8/controls/rt: RT-26633 ColorPicker setValue partially reflects changes. Message-ID: <20130306140332.F0A6A47898@hg.openjdk.java.net> Changeset: ed8f9c83d575 Author: Paru Somashekar Date: 2013-03-06 06:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ed8f9c83d575 RT-26633 ColorPicker setValue partially reflects changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java From hang.vo at oracle.com Wed Mar 6 07:03:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 15:03:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28790 Map/Set null values/keys not handled correctly by listeners Message-ID: <20130306150342.80B574789C@hg.openjdk.java.net> Changeset: 3ec5209e2c07 Author: Martin Sladecek Date: 2013-03-06 15:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3ec5209e2c07 RT-28790 Map/Set null values/keys not handled correctly by listeners ! javafx-beans/src/com/sun/javafx/binding/MapExpressionHelper.java ! javafx-beans/src/com/sun/javafx/binding/SetExpressionHelper.java ! javafx-beans/src/com/sun/javafx/collections/ObservableMapWrapper.java ! javafx-beans/src/com/sun/javafx/collections/ObservableSetWrapper.java ! javafx-beans/test/javafx/collections/ObservableMapTestBase.java ! javafx-beans/test/javafx/collections/ObservableSetTestBase.java From hang.vo at oracle.com Wed Mar 6 07:33:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 15:33:17 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26162 Split ObservableList implementations into RandomAcess and Sequential Message-ID: <20130306153320.C7C114789D@hg.openjdk.java.net> Changeset: df3ce8a3d2aa Author: Martin Sladecek Date: 2013-03-06 16:26 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/df3ce8a3d2aa RT-26162 Split ObservableList implementations into RandomAcess and Sequential ! javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableSequentialListWrapper.java ! javafx-beans/src/javafx/collections/FXCollections.java From hang.vo at oracle.com Wed Mar 6 08:19:13 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 16:19:13 +0000 Subject: hg: openjfx/8/controls/rt: 58 new changesets Message-ID: <20130306162315.8C4FB478A1@hg.openjdk.java.net> Changeset: 26b012b132f9 Author: David Grieve Date: 2013-03-06 11:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/26b012b132f9 RT-20906: add -fx-[min|pref|max]-[width|height] css properties to Region. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 08e1479a4c90 Author: "Jasper Potts" Date: 2013-02-26 14:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/08e1479a4c90 Ensemble 8: Fixed search index creation ! apps/samples/Ensemble8/build.xml ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/EnsembleCompiletimeMain.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/BuildEnsembleSearchIndex.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/DocumentationIndexer.java + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fdt + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fdx + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fnm + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.frq + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.nrm + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.prx + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.tii + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.tis - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdt - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fnm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.frq - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.nrm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.prx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tii - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tis ! apps/samples/Ensemble8/src/generated/ensemble/search/index/listAll.txt ! apps/samples/Ensemble8/src/generated/ensemble/search/index/segments.gen + apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_1 - apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_g Changeset: c573cfbca3d0 Author: rbair Date: 2013-02-26 17:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c573cfbca3d0 Updated Gradle build files ! build.gradle ! generator.gradle ! settings.gradle Changeset: 1ead718a729c Author: Petr Pchelko Date: 2013-02-27 14:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1ead718a729c 28219: Mac: ClassCastException in HelloHTMLEditor Reviewed-by: anthony, anthony ! glass/glass/src/com/sun/glass/ui/mac/MacSystemClipboard.java Changeset: c3b977f54869 Author: Alexander Zvegintsev Date: 2013-02-27 16:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c3b977f54869 RT-28448 Gtk: DnD event.getDragboard().getString() produces crash if dragboard does not contain string ! glass/glass-lib-gtk/src/glass_dnd.cpp ! glass/glass-lib-gtk/src/glass_general.cpp Changeset: 2c1e352e1eed Author: Martin Sladecek Date: 2013-02-27 14:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2c1e352e1eed RT-19020, RT-25996 conversion methods for Properties, ReadOnlyProperties and Expressions. ! javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java ! javafx-beans/src/javafx/beans/binding/BooleanExpression.java ! javafx-beans/src/javafx/beans/binding/DoubleExpression.java ! javafx-beans/src/javafx/beans/binding/FloatExpression.java ! javafx-beans/src/javafx/beans/binding/IntegerExpression.java ! javafx-beans/src/javafx/beans/binding/LongExpression.java ! javafx-beans/src/javafx/beans/property/BooleanProperty.java ! javafx-beans/src/javafx/beans/property/DoubleProperty.java ! javafx-beans/src/javafx/beans/property/FloatProperty.java ! javafx-beans/src/javafx/beans/property/IntegerProperty.java ! javafx-beans/src/javafx/beans/property/LongProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyBooleanProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyDoubleProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyFloatProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyIntegerProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyListProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyLongProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyMapProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyObjectProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlySetProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyStringProperty.java ! javafx-beans/test/javafx/beans/property/BooleanPropertyTest.java ! javafx-beans/test/javafx/beans/property/DoublePropertyTest.java ! javafx-beans/test/javafx/beans/property/FloatPropertyTest.java ! javafx-beans/test/javafx/beans/property/IntegerPropertyTest.java ! javafx-beans/test/javafx/beans/property/LongPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyTest.java ! javafx-beans/test/javafx/binding/expression/BooleanExpressionTest.java ! javafx-beans/test/javafx/binding/expression/DoubleExpressionTest.java ! javafx-beans/test/javafx/binding/expression/FloatExpressionTest.java ! javafx-beans/test/javafx/binding/expression/IntegerExpressionTest.java ! javafx-beans/test/javafx/binding/expression/LongExpressionTest.java Changeset: 60b4700fe623 Author: Martin Sladecek Date: 2013-02-27 14:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/60b4700fe623 merge Changeset: 09a4a2baf5df Author: Martin Sladecek Date: 2013-02-27 15:21 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/09a4a2baf5df [TEST] RT-25012 Switch to typed getChangeListeners() methods in ExpressionHelperUtility ! javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtility.java Changeset: 00b9dfdd1e33 Author: Martin Sladecek Date: 2013-02-27 15:21 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/00b9dfdd1e33 merge Changeset: 1d3c0d307859 Author: rbair Date: 2013-02-27 10:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1d3c0d307859 RT-28690: Remove jfxCssLexer.g and jfxCssParser.g ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java ! javafx-ui-common/src/com/sun/javafx/css/converters/PaintConverter.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 3c85e69bc056 Author: rbair Date: 2013-02-27 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3c85e69bc056 RT-28690: Remove jfxCssLexer.g and jfxCssParser.g Summary: Removed references to these from gradle generator script ! generator.gradle Changeset: 3d1e8caa50f2 Author: "Jasper Potts" Date: 2013-02-27 10:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3d1e8caa50f2 Fixed RT-28628: Ensemble 8 is all messed up on Retina. Which was because Region could not handle @2x images. ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java Changeset: 9bfc15277dcb Author: snorthov Date: 2013-02-27 15:47 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9bfc15277dcb fix .classpath to include Ensemble8 ! .classpath Changeset: df7505a75781 Author: rbair Date: 2013-02-27 13:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/df7505a75781 Fixed javadoc so as not to have trailing > but use > instead. Now builds on b78 of JDK 8. ! deploy/packager/src/com/sun/javafx/tools/ant/Application.java ! deploy/packager/src/com/sun/javafx/tools/ant/Callback.java ! deploy/packager/src/com/sun/javafx/tools/ant/Callbacks.java ! deploy/packager/src/com/sun/javafx/tools/ant/DeployFXTask.java ! deploy/packager/src/com/sun/javafx/tools/ant/FXSignJarTask.java ! deploy/packager/src/com/sun/javafx/tools/ant/FileSet.java ! deploy/packager/src/com/sun/javafx/tools/ant/Info.java ! deploy/packager/src/com/sun/javafx/tools/ant/Platform.java ! deploy/packager/src/com/sun/javafx/tools/ant/Preferences.java ! deploy/packager/src/com/sun/javafx/tools/ant/Resources.java Changeset: 559de95c61e6 Author: rbair Date: 2013-02-27 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/559de95c61e6 Updated Gradle build to build Glass on MacOSX. ! build.gradle ! generator.gradle Changeset: 26b56085a3ff Author: Felipe Heidrich Date: 2013-02-26 13:54 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/26b56085a3ff RT-28215: consider removing cagsrc.float from javafx.geom ! .classpath ! javafx-geom/build-common.xml - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java ! javafx-geom/javafx-geom.iml ! javafx-geom/nbproject/project.xml + javafx-geom/src/com/sun/javafx/geom/Area.java + javafx-geom/src/com/sun/javafx/geom/AreaOp.java + javafx-geom/src/com/sun/javafx/geom/ChainEnd.java + javafx-geom/src/com/sun/javafx/geom/Crossings.java + javafx-geom/src/com/sun/javafx/geom/Curve.java + javafx-geom/src/com/sun/javafx/geom/CurveLink.java + javafx-geom/src/com/sun/javafx/geom/Edge.java + javafx-geom/src/com/sun/javafx/geom/Order0.java + javafx-geom/src/com/sun/javafx/geom/Order1.java + javafx-geom/src/com/sun/javafx/geom/Order2.java + javafx-geom/src/com/sun/javafx/geom/Order3.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: 1b9af0a9c0eb Author: rbair Date: 2013-02-27 14:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1b9af0a9c0eb Removed work item in gradle build about cagsrc.float since Felipe has just removed it. ! generator.gradle Changeset: 74087bbd8a66 Author: ddehaven Date: 2013-02-27 15:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74087bbd8a66 Do RT-27054: Finish implementing changes to JavaFX launcher implementation ! javafx-ui-common/src/com/sun/javafx/application/LauncherImpl.java Changeset: 3cb91bf37590 Author: rbair Date: 2013-02-27 16:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3cb91bf37590 More updates to the Gradle scripts. Now copying & building FXML. Also moving over some of the apps and the deploy code (though neither is being built yet). ! build.gradle ! generator.gradle Changeset: da85b16b48d5 Author: rbair Date: 2013-02-27 17:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/da85b16b48d5 Fixed trailing , on a couple lines ! generator.gradle Changeset: d3a31551b59d Author: "Jasper Potts" Date: 2013-02-27 18:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d3a31551b59d Fixed RT-28628: Ensemble 8 is all messed up on Retina. Couple little clean ups of fix code. ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java Changeset: e422efa819f2 Author: rbair Date: 2013-02-27 22:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e422efa819f2 Numerous Gradle build fixes. Improved rules for which files are copied to src/main/java vs. src/main/resources. Implemented the construction of artifacts. Verified that all the right files are there, and none of the wrong ones (although there are some questionable empty directories). Oh, and the manifest isn't right yet. Otherwise looking pretty good. ! build.gradle ! generator.gradle Changeset: e0e6f8c374ef Author: Rafi Tayar Date: 2013-02-28 14:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e0e6f8c374ef Work on RT-24542: EGLFB: Some touch screens report implausibly frequent taps; we need to filter out the noise in these events ! glass/glass-lib-lens/src/input/udev/udevInput.c ! glass/glass-lib-lens/src/wm/LensWindowManager.c ! glass/glass/src/com/sun/glass/ui/lens/LensApplication.java ! glass/glass/src/com/sun/glass/ui/lens/LensTouchInputSupport.java Changeset: 75ec6f520c51 Author: Rafi Tayar Date: 2013-02-28 14:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/75ec6f520c51 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: b0ed493aa5ee Author: Alexander Zvegintsev Date: 2013-02-28 18:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b0ed493aa5ee RT-28561 Gtk: DnD dragboard content is unavailable in source.setOnDragDone ! glass/glass-lib-gtk/src/GlassDnDClipboard.cpp ! glass/glass-lib-gtk/src/glass_dnd.cpp Changeset: bb428b8c662a Author: David Hill Date: 2013-02-28 10:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bb428b8c662a Netbeans project for glass. + glass/glass/nbproject/project.xml Changeset: 6d472d534474 Author: David Hill Date: 2013-02-28 10:51 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6d472d534474 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: 66efb08464ce Author: snorthov Date: 2013-02-28 12:52 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/66efb08464ce RT-27455: EGLFB: Opening a new window during VKB opened cause a NullPointerException ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassScene.java Changeset: b2a7e34e6f71 Author: Felipe Heidrich Date: 2013-02-28 10:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2a7e34e6f71 RT-28707: Need to revert unintended change in RT-28215 to LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: 9a5af53aed5a Author: snorthov Date: 2013-02-28 14:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9a5af53aed5a RT-19342: SceneBuilder is out of sync with the native OS window size while resizing. ! glass/glass-lib-macosx/src/GlassView.m ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PaintCollector.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PresentingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/UploadingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/WindowStage.java Changeset: 687141cbfbba Author: snorthov Date: 2013-02-28 15:01 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/687141cbfbba RT-19342: SceneBuilder is out of sync with the native OS window size while resizing. [added -Djavafx.live.resize] ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 32cfc88cd5d3 Author: snorthov Date: 2013-02-28 15:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/32cfc88cd5d3 PlaygroundTabs - fix Eclipse compiler cast error ! apps/samples/Ensemble8/src/app/ensemble/samplepage/PlaygroundTabs.java Changeset: 9ecd8e3de269 Author: akouznet at AKOUZNET-LENOVO Date: 2013-02-28 12:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9ecd8e3de269 Ensemble3: Fix for RT-26854 Fix search focus issue ! apps/samples/Ensemble8/src/app/ensemble/SearchPopover.java ! apps/samples/Ensemble8/src/app/ensemble/SearchResultPopoverList.java ! apps/samples/Ensemble8/src/app/ensemble/control/Popover.java Changeset: a5389e8f1b35 Author: Alexander Kouznetsov Date: 2013-02-28 13:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a5389e8f1b35 Ensemble3: Code cleanup. ! apps/samples/Ensemble8/src/app/ensemble/EnsembleApp.java Changeset: 1276629eadb7 Author: dmasada Date: 2013-02-28 13:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1276629eadb7 Ensemble8: fix title ! apps/samples/Ensemble8/src/app/ensemble/EnsembleApp.java Changeset: ecca0fbeebad Author: Alexander Kouznetsov Date: 2013-02-28 15:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ecca0fbeebad Ensemble3: Fixed popover background ! apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesCommon.css Changeset: e2a407dbcfa3 Author: kcr Date: 2013-02-28 16:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e2a407dbcfa3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdt - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fnm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.frq - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.nrm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.prx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tii - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tis - apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_g - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 534729526388 Author: Martin Sladecek Date: 2013-03-01 09:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/534729526388 RT-28198 com.sun.javafx.binding.SelectBinding$SelectBindingHelper has a dependency on javafx.beans ! javafx-beans/src/com/sun/javafx/binding/SelectBinding.java + javafx-beans/src/com/sun/javafx/property/JavaBeanAccessHelper.java ! javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanQuickAccessor.java Changeset: fe1c4d375337 Author: Martin Sladecek Date: 2013-03-01 09:58 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fe1c4d375337 merge Changeset: efc566a46a12 Author: rbair Date: 2013-03-01 13:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/efc566a46a12 Fixed the classpath handling for Gradle build. I think I have it right now. The bootclasspath should be reset so that it only includes rt.jar (and specifically doesn't have jfxrt.jar). I then put jfxrt.jar on the classpath AFTER all the other project dependencies etc, so that it operates appropriately as a binary stub. Also disabled tests until I get them sorted out. ! build.gradle Changeset: 41a9ef3f44e9 Author: Thor johannesson Date: 2013-03-01 15:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/41a9ef3f44e9 Fix RT-20784: Mac: Headless environment issue. Approved by Kevin and Phil ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 520d4cf6f15f Author: snorthov Date: 2013-03-01 19:48 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/520d4cf6f15f fix live resize for SWT ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: d27aceac8d66 Author: Alexander Kouznetsov Date: 2013-03-01 17:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d27aceac8d66 Ensemble3: Fix for RT-28757 Home Page resize bad performance ! apps/samples/Ensemble8/src/app/ensemble/HomePage.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java Changeset: 787376bff0fd Author: rbair Date: 2013-03-01 17:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/787376bff0fd Failed to build on some Java 8 VM, due to long confusion. Likely bug in javac. ! javafx-logging/src/com/sun/javafx/logging/PulseLogger.java Changeset: 6faf8a3c2214 Author: rbair Date: 2013-03-01 18:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6faf8a3c2214 Lots of work on the build script -- the tests now all compile. Abstracted some hardcoded values into settable properties (such as from Hudson). Added some logging. Fixed up the bootclasspath stuff (really hoping I got it this time!). Had to switch to 1.7 source because 1.8 tickles a compiler bug when compiling the tests. ! build.gradle Changeset: 9134330dc4e0 Author: Daniel Blaukopf Date: 2013-03-03 18:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9134330dc4e0 Build GTK in cross builds as well as host builds ! glass/build-common.xml ! glass/glass-lib-gtk/build.xml Changeset: f200832fb53a Author: Milan Kubec Date: 2013-03-04 10:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f200832fb53a RT-25559: Allow event handlers to come from the namespace; better error message, tests added to the suite; minor rename; license update ! javafx-fxml/src/javafx/fxml/FXMLLoader.java - javafx-fxml/test/javafx/fxml/RT_25559.java + javafx-fxml/test/javafx/fxml/RT_25559Test.java ! javafx-fxml/test/javafx/fxml/rt_25559.fxml + javafx-fxml/test/javafx/fxml/rt_25559_err1.fxml Changeset: 3e43e2361e9a Author: Martin Sladecek Date: 2013-03-04 12:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3e43e2361e9a [TEST] new tests for ListChangeListener.Change implementations. + javafx-beans/test/com/sun/javafx/collections/MappingChangeTest.java + javafx-beans/test/com/sun/javafx/collections/NonIterableChangeTest.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java Changeset: 392abf0df66f Author: Martin Sladecek Date: 2013-03-04 12:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/392abf0df66f merge - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 63c947b7d28a Author: Martin Sladecek Date: 2013-03-04 12:03 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/63c947b7d28a merge Changeset: 171ff8b064e2 Author: Milan Kubec Date: 2013-03-04 12:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/171ff8b064e2 RT-27589: JavaFXBuilderFactory has a strong dependency on webnode ! javafx-fxml/nbproject/project.xml ! javafx-fxml/src/javafx/fxml/JavaFXBuilderFactory.java - javafx-fxml/test/javafx/fxml/RT_23519.java + javafx-fxml/test/javafx/fxml/RT_23519Test.java ! javafx-fxml/test/javafx/fxml/rt_23519.fxml Changeset: 29787a06e0de Author: snorthov Date: 2013-03-04 14:04 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/29787a06e0de Ensemble8: don't crash if source file is not available ! apps/samples/Ensemble8/src/app/ensemble/util/Utils.java Changeset: b11664e10c75 Author: rbair Date: 2013-03-04 16:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b11664e10c75 Fixed up tests for Gradle build. Now all the tests run and pass. ! build.gradle ! generator.gradle Changeset: b47611118080 Author: rbair Date: 2013-03-04 17:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b47611118080 Fixed exclude login in stub toolkit tests for Gradle Build ! build.gradle Changeset: cb061795e1f7 Author: Milan Kubec Date: 2013-03-05 12:12 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cb061795e1f7 RT-28784: Accessibility of methods in FXMLLoader unintentionally changed to protected ! javafx-fxml/src/javafx/fxml/FXMLLoader.java Changeset: 4620dab2c1ac Author: dmasada Date: 2013-03-05 08:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4620dab2c1ac RT-28749 Ensemble8: add to internal build + apps/build-defs.xml + apps/build.xml ! apps/samples/Ensemble8/nbproject/project.properties + apps/samples/build.xml Changeset: 008bdab5b9fb Author: Alexander Kouznetsov Date: 2013-03-05 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/008bdab5b9fb Ensemble8: Fix for RT-28796 NPE in Ensemble8 ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java Changeset: 637a0d67106f Author: David Grieve Date: 2013-03-06 11:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/637a0d67106f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties - apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties - apps/experiments/Modena/nbproject/jfx-impl.xml - apps/experiments/Modena/nbproject/jfx-impl_backup.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_2.xml From hang.vo at oracle.com Wed Mar 6 08:48:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 16:48:02 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130306164810.411F9478A5@hg.openjdk.java.net> Changeset: bc78e8b64377 Author: Chien Yang Date: 2013-03-06 08:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bc78e8b64377 Fix to RT-28821: FX 8 3D: AmbientLight isn't implemented. Approved by Kevin ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape3D.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: c6f4b6d77cbb Author: Chien Yang Date: 2013-03-06 08:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c6f4b6d77cbb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt From steve.x.northover at oracle.com Wed Mar 6 09:49:02 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 06 Mar 2013 12:49:02 -0500 Subject: JavaFX Threading Message-ID: <5137818E.4020100@oracle.com> Hi all, One of the great things about JavaFX is that it has a consistent threading model that maps well on to the underlying platforms. There is a single distinguished GUI-thread that is also the GUI-thread for the window system. This makes JavaFX GUI behavior consistent and deterministic. In general, running code in the GUI thread is a good thing for these reasons and others, provided that the code is not long running. In the case of long running code, JavaFX objects may be created in background threads as long are they are not attached to the scene graph. JavaFX applications have a life cycle that includes, construction, init(), start() and stop(). The start() method is the most important and runs in the GUI-thread. The init() method is guaranteed to run in a background thread and is the place where long running creation code can reside. The start() method will always run after init() has completed. With a preloader, the start() of the preloader runs at the same time as the init() of the application. The stop() method is also guaranteed to run in the GUI-thread. What about application construction? Today, this is unspecified and happens in a background thread. We are considering moving this to the GUI-thread. Here is the JIRA that is tracking this work: http://javafx-jira.kenai.com/browse/RT-28754 If you are interested, add yourself, please add yourself to it and comment either there or on this list, Thanks! Steve From hang.vo at oracle.com Wed Mar 6 11:18:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 19:18:01 +0000 Subject: hg: openjfx/8/controls/rt: Modena Test App: added sample naviagation and position rememebering Message-ID: <20130306191809.BC7ED478AC@hg.openjdk.java.net> Changeset: 709356911e3a Author: "Jasper Potts" Date: 2013-03-06 11:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/709356911e3a Modena Test App: added sample naviagation and position rememebering ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/SamplePageNavigation.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/modena/TestApp.css From hang.vo at oracle.com Wed Mar 6 11:48:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 19:48:06 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28749 Add Ensemble8 to internal build (add fxpackager use) Message-ID: <20130306194812.D883E478AD@hg.openjdk.java.net> Changeset: e2f88c00234e Author: dmasada Date: 2013-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e2f88c00234e RT-28749 Add Ensemble8 to internal build (add fxpackager use) + apps/build-tasks.xml ! apps/samples/Ensemble8/build.xml From kevin.rushforth at oracle.com Wed Mar 6 14:18:19 2013 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Wed, 06 Mar 2013 22:18:19 +0000 Subject: hg: openjfx/8/master: RT-28431 Initial support for crossbuilding. Message-ID: <20130306221820.0F39E47A03@hg.openjdk.java.net> Changeset: 0aa99c6657c9 Author: David Hill Date: 2013-03-04 18:43 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rev/0aa99c6657c9 RT-28431 Initial support for crossbuilding. ! .hgignore ! build-defs.xml + build-src/build-cross.xml + build-src/platform/raspberry-pi.properties From kevin.rushforth at oracle.com Wed Mar 6 14:17:05 2013 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Wed, 06 Mar 2013 22:17:05 +0000 Subject: hg: openjfx/8/controls: RT-28431 Initial support for crossbuilding. Message-ID: <20130306221705.666EA47A02@hg.openjdk.java.net> Changeset: 0aa99c6657c9 Author: David Hill Date: 2013-03-04 18:43 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rev/0aa99c6657c9 RT-28431 Initial support for crossbuilding. ! .hgignore ! build-defs.xml + build-src/build-cross.xml + build-src/platform/raspberry-pi.properties From alexander.matveev at oracle.com Wed Mar 6 15:07:16 2013 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 06 Mar 2013 15:07:16 -0800 Subject: [API Review]: RT-28817 - Add explicit dispose() method to MediaPlayer Message-ID: <5137CC24.4050905@oracle.com> Hi all, Explicit dispose() method is needed to free native resources used by MediaPlayer. Garbage collector is not reliable enough to free native resources fast enough, thus when MediaPlayers are created fast enough we may run out of native memory. Normally, user does not need to call dispose() method on MediaPlayer if application does not create them often. After dispose() is called MediaPlayer cannot be used again and should be disregarded. Media and MediaView associated with disposed MediaPlayer can be reused. Dispose() will be valid in any states. For example, when player is playing call to dispose() will stop playback and release all resources. JIRA: http://javafx-jira.kenai.com/browse/RT-28817 Thanks, Alexander From hang.vo at oracle.com Wed Mar 6 15:33:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Mar 2013 23:33:23 +0000 Subject: hg: openjfx/8/controls/rt: 6 new changesets Message-ID: <20130306233347.3360747A0F@hg.openjdk.java.net> Changeset: 66330d32d59f Author: jgiles Date: 2013-03-06 12:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/66330d32d59f RT-27609: [TreeTableView] Scroll bar appears while there is enough space for rendering content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: ad7ab4d353c4 Author: jgiles Date: 2013-03-06 16:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ad7ab4d353c4 RT-28479: [TreeTableView] TreeTableColumn onEditCommit handler not called ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 0251aa01fc7c Author: jgiles Date: 2013-03-07 09:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0251aa01fc7c RT-28637: [ListView, TreeView, TableView, TreeTableView] selectionModel selectedItem returns wrong item. Tests were previously developed and have now been enabled. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 7fad68376811 Author: jgiles Date: 2013-03-07 09:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7fad68376811 Unit tests for RT-28819 ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java Changeset: 90ee146e03e5 Author: jgiles Date: 2013-03-07 12:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/90ee146e03e5 Fixes for failing unit tests related to RT-28637 and RT-21586 ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: 22bc48b746d4 Author: jgiles Date: 2013-03-07 12:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/22bc48b746d4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From ozemale at ozemail.com.au Wed Mar 6 15:45:56 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Thu, 7 Mar 2013 10:45:56 +1100 Subject: JavaFX Threading In-Reply-To: <5137818E.4020100@oracle.com> References: <5137818E.4020100@oracle.com> Message-ID: <00b901ce1ac4$bfa38540$3eea8fc0$@com.au> Is there a document/link that describes in some detail the threading architecture of JavaFX along with things such as defining the "pulse" and the rendering pipeline? Thanks, -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of steve.x.northover at oracle.com Sent: Thursday, 7 March 2013 04:49 To: openjfx-dev at openjdk.java.net Subject: JavaFX Threading Hi all, One of the great things about JavaFX is that it has a consistent threading model that maps well on to the underlying platforms. There is a single distinguished GUI-thread that is also the GUI-thread for the window system. This makes JavaFX GUI behavior consistent and deterministic. In general, running code in the GUI thread is a good thing for these reasons and others, provided that the code is not long running. In the case of long running code, JavaFX objects may be created in background threads as long are they are not attached to the scene graph. JavaFX applications have a life cycle that includes, construction, init(), start() and stop(). The start() method is the most important and runs in the GUI-thread. The init() method is guaranteed to run in a background thread and is the place where long running creation code can reside. The start() method will always run after init() has completed. With a preloader, the start() of the preloader runs at the same time as the init() of the application. The stop() method is also guaranteed to run in the GUI-thread. What about application construction? Today, this is unspecified and happens in a background thread. We are considering moving this to the GUI-thread. Here is the JIRA that is tracking this work: http://javafx-jira.kenai.com/browse/RT-28754 If you are interested, add yourself, please add yourself to it and comment either there or on this list, Thanks! Steve From hang.vo at oracle.com Wed Mar 6 16:18:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 00:18:35 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-28843: TableView header overlaps TableView Border Message-ID: <20130307001838.40CDE47A96@hg.openjdk.java.net> Changeset: 9dd0e3c584b6 Author: "Jasper Potts" Date: 2013-03-06 16:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9dd0e3c584b6 Fixed RT-28843: TableView header overlaps TableView Border ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java From djfranken at gmx.de Wed Mar 6 16:32:59 2013 From: djfranken at gmx.de (Dennis Franken) Date: Thu, 07 Mar 2013 01:32:59 +0100 Subject: Decora <> Open Shading Language? In-Reply-To: <511D6885.6010800@oracle.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> <511D6885.6010800@oracle.com> Message-ID: <5137E03B.2010306@gmx.de> Hello, just as an idea, maybe the angle project can be used to simply translate GLSL vertex and fragment shader code to HLSL. GLSL would be the source shading language. This project provides a GLES2 / WebGL runtime translation environment used in google chrome and firefox, so it seems to be compliant, fast and well maintained. I have no experiences with the angle project whatsoever though, but webGL on chrome seems to work great. https://code.google.com/p/angleproject/ This could provide a simple way to include resources like WebGL shaders from e.g. shadertoy.com for interactive backgrounds. JavaFX could supply a "ShaderNode" where you can set glsl code, add properties in subclasses that get automagically mapped to shader uniforms. Alternativly, the translator could only be available for development and copies both glsl/hlsl versions into a file as a deployable resource. Kind Regards, Dennis On 14.02.2013 23:43, Jim Graham wrote: > Rich's analysis is spot on from my perspective. I don't have much time > to work on Decora these days and most of my plans for what I would do > are more tweaking and fixing issues that cause us headaches for our > current usage. For example, it was originally written to be a > standalone package that could be integrated into Swing apps or any other > infrastructure out there, but we've since broken just about any > generalized mechanism in it through disuse and lack of maintenance. > Since we don't really believe that it would ever be a standalone module > any more, it would integrate a whole lot more directly and simply if we > redid the interface to it to be Prism-specific. > > The only "marketing bullet point" advantages to switching from Decora > would likely be possibly enabling user-supplied shaders, and also using > it for the greater needs of 3D apps that go beyond basic pixel-shaders. > > We'd love to be able to leverage Decora at runtime for user-supplied > shaders, but that is a daunting amount of work since much of its actions > rely on being able to use javac and/or a native C, GSL, or HLSL compiler > to finish the work after the "decora compiler" does the translations - > i.e. it translates form HSL into various other forms of source code and > then runs other compilers on those. What we would probably have to do > is to provide a way for a developer to run the decora compiler alongside > his FX app and then include the various compiled alternative results, > but that would require building on multiple platforms to produce all of > the necessary files that are needed on an arbitrary target computer > (minimally, building on Windows could net a GLS, an HLSL, and a Java > version of the shader so that may be enough, but Mac developers would be > out of luck for producing Win-specific output). We'd also have to do a > security analysis of accepting compiled GSL and HLSL shaders in a > non-privileged deployment (the least common denominator work around > would be to only allow the Java-compiled versions of the shaders in the > absence of a signed app, but the performance on those would likely be > lower than something that the developer wrote themselves in hand-tuned > Java). So, there are a lot of issues to consider and work on there > before we could use Decora to provide user-supplied shaders. > > It may be less work to provide the GPU plugins for OSL than to figure > out a workaround for the need for a compiler in Decora. We'd also > leverage a larger development community for the more common parts of it. > But, we'd also have to do a large security review of it every single > time we brought over a new source drop from it and the complexity of > that security review would involve analyzing the byte-code they produce > and all elements of their runtime to make sure that a hostile OSL > byte-code file couldn't break us. Using this "off the shelf" technology > sounds attractive, but integrating a 3rd party solution often has its > own headaches that you don't see when you are in the honeymoon phase > after having read all of the marketing bullet points. :( > > I think a first task should be to get to the point where "Jim" isn't the > only engineer with more than a passing understanding of what goes on > with Decora under the hood - particularly since I don't have much time > to do a more indepth analysis of competing technologies like this. Any > volunteers that are fascinated by the world of shaders? > > ...jim > > On 2/14/13 1:52 PM, Richard Bair wrote: >> Hi Philip, >> >> Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially. >> >> Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html). >> >> Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those). >> >> There are Pros / Cons to each: >> >> OSL: >> Pros: >> - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget. >> - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc) >> - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs >> Cons: >> - Different design center -- doesn't yet support GPUs for instance >> - Lack of tooling >> >> Pixel Bender: >> Pros: >> - Great tooling support >> - Same design center -- shaders for 2D / 3D applications >> - Robust >> - Leverage Adobe's investment >> Cons: >> - License is proprietary according to wikipedia, not sure myself >> - Not sure of the runtime size >> - Needs to be vetted for security risks >> >> Decora: >> Pros: >> - Does exactly what we need -- no more >> - Small size (no features we don't need) >> Cons: >> - No time to invest in serious upgrades >> - No tooling support >> >> I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work. >> >> However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs. >> >> Richard >> >> >> On Feb 14, 2013, at 1:49 AM, Philipp D?rfler wrote: >> >>> Here is the link: >>> [1] http://opensource.imageworks.com/?p=osl >>> >>> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : >>> >>>> Greetings, >>>> >>>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >>>> >>>> Cheers and thanks in advance >>>> ~ Philipp From kevin.rushforth at oracle.com Wed Mar 6 17:03:15 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 06 Mar 2013 17:03:15 -0800 Subject: JavaFX Threading In-Reply-To: <5137818E.4020100@oracle.com> References: <5137818E.4020100@oracle.com> Message-ID: <5137E753.8020503@oracle.com> Does anyone think we shouldn't make this change? While it is a behavioral change, I doubt it will cause problems for applications. On the contrary, naive applications will be less likely to run into problems after this change. Sophisticated applications can still do background loading in the init() method for long-running initialization. One slight correction to what Steve wrote: > What about application construction? > > Today, this is unspecified ... Actually, this is specified today. The javadoc for the Application class says this: * The Application constructor and {@code init} method are called on * the launcher thread, not on the JavaFX Application Thread. * This means that an application must not construct a {@link Scene} * or a {@link Stage} in either the constructor or in the {@code init} * method. So we will need to change the docs as part of this JIRA. -- Kevin steve.x.northover at oracle.com wrote: > Hi all, > > One of the great things about JavaFX is that it has a consistent > threading model that maps well on to the underlying platforms. There > is a single distinguished GUI-thread that is also the GUI-thread for > the window system. This makes JavaFX GUI behavior consistent and > deterministic. In general, running code in the GUI thread is a good > thing for these reasons and others, provided that the code is not long > running. In the case of long running code, JavaFX objects may be > created in background threads as long are they are not attached to the > scene graph. > > JavaFX applications have a life cycle that includes, construction, > init(), start() and stop(). The start() method is the most important > and runs in the GUI-thread. The init() method is guaranteed to run in > a background thread and is the place where long running creation code > can reside. The start() method will always run after init() has > completed. With a preloader, the start() of the preloader runs at the > same time as the init() of the application. The stop() method is also > guaranteed to run in the GUI-thread. > > What about application construction? > > Today, this is unspecified and happens in a background thread. We are > considering moving this to the GUI-thread. Here is the JIRA that is > tracking this work: > > http://javafx-jira.kenai.com/browse/RT-28754 > > If you are interested, add yourself, please add yourself to it and > comment either there or on this list, > > Thanks! > Steve > > From hang.vo at oracle.com Wed Mar 6 18:03:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 02:03:44 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130307020352.4633647D85@hg.openjdk.java.net> Changeset: 4110414745eb Author: "Jasper Potts" Date: 2013-03-06 17:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4110414745eb Modena Fixed RT-28227: Modena: Table and TreeTable are not refined, Also fixed toolbar gradients for mid grey base colors. Consitant Checkbox sizing for font size changes. Medium text color tweek.Bunch of other CSS cleanup. Modena Test app added more tests for Table and TreeTables. ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/modena/SamplePageTreeTableHelper.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: fd5419fef373 Author: "Jasper Potts" Date: 2013-03-06 18:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fd5419fef373 Modena Test App added test case for RT-28410 ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java From hang.vo at oracle.com Wed Mar 6 18:33:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 02:33:03 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: fixing comments Message-ID: <20130307023317.4299347D92@hg.openjdk.java.net> Changeset: 1a825fa0340f Author: dmasada Date: 2013-03-06 18:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1a825fa0340f Ensemble8: fixing comments ! apps/samples/Ensemble8/src/app/ensemble/EmbeddedApplication.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/PieChartDataVisualizer.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/XYDataVisualizer.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/DocumentationIndexer.java From tom.schindl at bestsolution.at Thu Mar 7 02:24:33 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 07 Mar 2013 11:24:33 +0100 Subject: Make Fullscreen Warning overlay none-mandatory Message-ID: <51386AE1.6030409@bestsolution.at> Hi, Before I file a JIRA-Ticket I'd like to start a dicussion here to find out if my point of view is completely wrong. If you currently put a Stage into Fullscreen mode it displays the message "Press ESC to exit full-screen mode.". The first problem with the overlay presented is that while the Group is big enough for the English-Text it looks like nobody ever checked this with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus zu beenden.") - I'll file a JIRA for it anyways. Still this is not my problem. What I'd like to suggest is that I as a developer can turn of the forced overlay. I could think of multiple possibilities: a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) b) through an API on the Stage What do you think about a) or b) is there a chance to get something like this in FX8, or is it too late already? Do you see any reason turning of the overlay could cause problems? Since the quantum sources are now available I'd be able to implement a desired feature using a) or b) and provide a patch. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From phdoerfler at gmail.com Thu Mar 7 02:35:21 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 7 Mar 2013 11:35:21 +0100 Subject: JavaFX Threading In-Reply-To: <5137E753.8020503@oracle.com> References: <5137818E.4020100@oracle.com> <5137E753.8020503@oracle.com> Message-ID: +1 for the change ~ philipp Am 07.03.2013 um 02:03 schrieb Kevin Rushforth : > Does anyone think we shouldn't make this change? While it is a behavioral change, I doubt it will cause problems for applications. On the contrary, naive applications will be less likely to run into problems after this change. Sophisticated applications can still do background loading in the init() method for long-running initialization. > > One slight correction to what Steve wrote: > >> What about application construction? >> >> Today, this is unspecified ... > > Actually, this is specified today. The javadoc for the Application class says this: > > * The Application constructor and {@code init} method are called on > * the launcher thread, not on the JavaFX Application Thread. > * This means that an application must not construct a {@link Scene} > * or a {@link Stage} in either the constructor or in the {@code init} > * method. > > So we will need to change the docs as part of this JIRA. > > -- Kevin > > > steve.x.northover at oracle.com wrote: >> Hi all, >> >> One of the great things about JavaFX is that it has a consistent threading model that maps well on to the underlying platforms. There is a single distinguished GUI-thread that is also the GUI-thread for the window system. This makes JavaFX GUI behavior consistent and deterministic. In general, running code in the GUI thread is a good thing for these reasons and others, provided that the code is not long running. In the case of long running code, JavaFX objects may be created in background threads as long are they are not attached to the scene graph. >> >> JavaFX applications have a life cycle that includes, construction, init(), start() and stop(). The start() method is the most important and runs in the GUI-thread. The init() method is guaranteed to run in a background thread and is the place where long running creation code can reside. The start() method will always run after init() has completed. With a preloader, the start() of the preloader runs at the same time as the init() of the application. The stop() method is also guaranteed to run in the GUI-thread. >> >> What about application construction? >> >> Today, this is unspecified and happens in a background thread. We are considering moving this to the GUI-thread. Here is the JIRA that is tracking this work: >> >> http://javafx-jira.kenai.com/browse/RT-28754 >> >> If you are interested, add yourself, please add yourself to it and comment either there or on this list, >> >> Thanks! >> Steve >> >> From phdoerfler at gmail.com Thu Mar 7 02:50:34 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 7 Mar 2013 11:50:34 +0100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <51386AE1.6030409@bestsolution.at> References: <51386AE1.6030409@bestsolution.at> Message-ID: <078E1539-A352-466E-9290-50CD5098C884@gmail.com> Hi, Yes please! Make the fullscreen hint optional. The warning might be warranted for JavaFX applications running in the browser (if there is still somebody out there with an enabled Java Plug-in *hint hint*, sorry :p ). For desktop applications it is quite unnecessary IMO and in addition to the warning, the keybinding (ESC) hurts, too: Games for instance usually show a menu and pause the game when pressing ESC. In addition to the options outlined by Tom (from which I would choose "b)", I would like to throw in an additional one: c) If the JavaFX app is running from within the browser keep the current behavior. If it is running as a stand alone app, enter fullscreen silently, don't show a warning and don't associate ESC with setFullScreen(false) Cheers, ~ Philipp Am 07.03.2013 um 11:24 schrieb Tom Schindl : > Hi, > > Before I file a JIRA-Ticket I'd like to start a dicussion here to find > out if my point of view is completely wrong. > > If you currently put a Stage into Fullscreen mode it displays the > message "Press ESC to exit full-screen mode.". > > The first problem with the overlay presented is that while the Group is > big enough for the English-Text it looks like nobody ever checked this > with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus > zu beenden.") - I'll file a JIRA for it anyways. > > Still this is not my problem. What I'd like to suggest is that I as a > developer can turn of the forced overlay. > > I could think of multiple possibilities: > a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) > b) through an API on the Stage > > What do you think about a) or b) is there a chance to get something like > this in FX8, or is it too late already? Do you see any reason turning of > the overlay could cause problems? > > Since the quantum sources are now available I'd be able to implement a > desired feature using a) or b) and provide a patch. > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From hendrik.ebbers at me.com Thu Mar 7 03:00:00 2013 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Thu, 07 Mar 2013 12:00:00 +0100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <078E1539-A352-466E-9290-50CD5098C884@gmail.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> Message-ID: +1 Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : > Hi, > > Yes please! Make the fullscreen hint optional. The warning might be warranted for JavaFX applications running in the browser (if there is still somebody out there with an enabled Java Plug-in *hint hint*, sorry :p ). For desktop applications it is quite unnecessary IMO and in addition to the warning, the keybinding (ESC) hurts, too: Games for instance usually show a menu and pause the game when pressing ESC. > > In addition to the options outlined by Tom (from which I would choose "b)", I would like to throw in an additional one: > > c) If the JavaFX app is running from within the browser keep the current behavior. > If it is running as a stand alone app, enter fullscreen silently, don't show a warning and don't associate ESC with setFullScreen(false) > > Cheers, > ~ Philipp > > Am 07.03.2013 um 11:24 schrieb Tom Schindl : > >> Hi, >> >> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >> out if my point of view is completely wrong. >> >> If you currently put a Stage into Fullscreen mode it displays the >> message "Press ESC to exit full-screen mode.". >> >> The first problem with the overlay presented is that while the Group is >> big enough for the English-Text it looks like nobody ever checked this >> with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus >> zu beenden.") - I'll file a JIRA for it anyways. >> >> Still this is not my problem. What I'd like to suggest is that I as a >> developer can turn of the forced overlay. >> >> I could think of multiple possibilities: >> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >> b) through an API on the Stage >> >> What do you think about a) or b) is there a chance to get something like >> this in FX8, or is it too late already? Do you see any reason turning of >> the overlay could cause problems? >> >> Since the quantum sources are now available I'd be able to implement a >> desired feature using a) or b) and provide a patch. >> >> Tom >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > From randahl at rockit.dk Thu Mar 7 03:05:33 2013 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 7 Mar 2013 12:05:33 +0100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> Message-ID: <0A6D5B98-01C9-456E-BDC6-BE540CBDC765@rockit.dk> +1 On Mar 7, 2013, at 12:00 , Hendrik Ebbers wrote: > +1 > > Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : > >> Hi, >> >> Yes please! Make the fullscreen hint optional. The warning might be warranted for JavaFX applications running in the browser (if there is still somebody out there with an enabled Java Plug-in *hint hint*, sorry :p ). For desktop applications it is quite unnecessary IMO and in addition to the warning, the keybinding (ESC) hurts, too: Games for instance usually show a menu and pause the game when pressing ESC. >> >> In addition to the options outlined by Tom (from which I would choose "b)", I would like to throw in an additional one: >> >> c) If the JavaFX app is running from within the browser keep the current behavior. >> If it is running as a stand alone app, enter fullscreen silently, don't show a warning and don't associate ESC with setFullScreen(false) >> >> Cheers, >> ~ Philipp >> >> Am 07.03.2013 um 11:24 schrieb Tom Schindl : >> >>> Hi, >>> >>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>> out if my point of view is completely wrong. >>> >>> If you currently put a Stage into Fullscreen mode it displays the >>> message "Press ESC to exit full-screen mode.". >>> >>> The first problem with the overlay presented is that while the Group is >>> big enough for the English-Text it looks like nobody ever checked this >>> with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus >>> zu beenden.") - I'll file a JIRA for it anyways. >>> >>> Still this is not my problem. What I'd like to suggest is that I as a >>> developer can turn of the forced overlay. >>> >>> I could think of multiple possibilities: >>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>> b) through an API on the Stage >>> >>> What do you think about a) or b) is there a chance to get something like >>> this in FX8, or is it too late already? Do you see any reason turning of >>> the overlay could cause problems? >>> >>> Since the quantum sources are now available I'd be able to implement a >>> desired feature using a) or b) and provide a patch. >>> >>> Tom >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >> From Claus.Luethje at osys.ch Thu Mar 7 03:09:58 2013 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Thu, 7 Mar 2013 11:09:58 +0000 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <51386AE1.6030409@bestsolution.at> References: <51386AE1.6030409@bestsolution.at> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D23AE11ED@Jeri.osys.ch> Hi Tom I think this is a very valid point and a feature, which should be in FX8. I had several discussions with customers about this and we had to work around this every time. I'd prefer b) any day, because I don't want to leave this decision to the one running my app. Just my 0.02$ Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl Sent: Donnerstag, 7. M?rz 2013 11:25 To: openjfx-dev at openjdk.java.net Subject: Make Fullscreen Warning overlay none-mandatory Hi, Before I file a JIRA-Ticket I'd like to start a dicussion here to find out if my point of view is completely wrong. If you currently put a Stage into Fullscreen mode it displays the message "Press ESC to exit full-screen mode.". The first problem with the overlay presented is that while the Group is big enough for the English-Text it looks like nobody ever checked this with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus zu beenden.") - I'll file a JIRA for it anyways. Still this is not my problem. What I'd like to suggest is that I as a developer can turn of the forced overlay. I could think of multiple possibilities: a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) b) through an API on the Stage What do you think about a) or b) is there a chance to get something like this in FX8, or is it too late already? Do you see any reason turning of the overlay could cause problems? Since the quantum sources are now available I'd be able to implement a desired feature using a) or b) and provide a patch. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From rk at ziemsky.com Thu Mar 7 03:23:35 2013 From: rk at ziemsky.com (Rafal Kocinski) Date: Thu, 7 Mar 2013 11:23:35 +0000 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <0A6D5B98-01C9-456E-BDC6-BE540CBDC765@rockit.dk> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <0A6D5B98-01C9-456E-BDC6-BE540CBDC765@rockit.dk> Message-ID: +1 for making it optional and for a choice of the toggle key/key combination On Mar 7, 2013 11:15 AM, "Randahl Fink Isaksen" wrote: > +1 > > On Mar 7, 2013, at 12:00 , Hendrik Ebbers wrote: > > > +1 > > > > Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : > > > >> Hi, > >> > >> Yes please! Make the fullscreen hint optional. The warning might be > warranted for JavaFX applications running in the browser (if there is still > somebody out there with an enabled Java Plug-in *hint hint*, sorry :p ). > For desktop applications it is quite unnecessary IMO and in addition to the > warning, the keybinding (ESC) hurts, too: Games for instance usually show a > menu and pause the game when pressing ESC. > >> > >> In addition to the options outlined by Tom (from which I would choose > "b)", I would like to throw in an additional one: > >> > >> c) If the JavaFX app is running from within the browser keep the > current behavior. > >> If it is running as a stand alone app, enter fullscreen silently, don't > show a warning and don't associate ESC with setFullScreen(false) > >> > >> Cheers, > >> ~ Philipp > >> > >> Am 07.03.2013 um 11:24 schrieb Tom Schindl >: > >> > >>> Hi, > >>> > >>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find > >>> out if my point of view is completely wrong. > >>> > >>> If you currently put a Stage into Fullscreen mode it displays the > >>> message "Press ESC to exit full-screen mode.". > >>> > >>> The first problem with the overlay presented is that while the Group is > >>> big enough for the English-Text it looks like nobody ever checked this > >>> with the german translation ("Dr\u00FCcken Sie ESC, um den > Vollbildmodus > >>> zu beenden.") - I'll file a JIRA for it anyways. > >>> > >>> Still this is not my problem. What I'd like to suggest is that I as a > >>> developer can turn of the forced overlay. > >>> > >>> I could think of multiple possibilities: > >>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) > >>> b) through an API on the Stage > >>> > >>> What do you think about a) or b) is there a chance to get something > like > >>> this in FX8, or is it too late already? Do you see any reason turning > of > >>> the overlay could cause problems? > >>> > >>> Since the quantum sources are now available I'd be able to implement a > >>> desired feature using a) or b) and provide a patch. > >>> > >>> Tom > >>> > >>> -- > >>> B e s t S o l u t i o n . a t EDV Systemhaus > GmbH > >>> > ------------------------------------------------------------------------ > >>> tom schindl gesch?ftsf?hrer/CEO > >>> > ------------------------------------------------------------------------ > >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 > 935833 > >>> http://www.BestSolution.at phone ++43 512 > 935834 > >> > > From hang.vo at oracle.com Thu Mar 7 03:48:25 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 11:48:25 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28283 and RT-28284: HiDPI robot support Message-ID: <20130307114834.3C79247DE0@hg.openjdk.java.net> Changeset: 05ce1a10c53f Author: Anthony Petrov Date: 2013-03-07 15:35 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/05ce1a10c53f RT-28283 and RT-28284: HiDPI robot support ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass-lib-macosx/src/GlassRobot.m ! glass/glass-lib-macosx/src/GlassStatics.h ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/Pixels.java ! glass/glass/src/com/sun/glass/ui/Robot.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkApplication.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkPixels.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkRobot.java ! glass/glass/src/com/sun/glass/ui/ios/IosApplication.java ! glass/glass/src/com/sun/glass/ui/ios/IosPixels.java ! glass/glass/src/com/sun/glass/ui/ios/IosRobot.java ! glass/glass/src/com/sun/glass/ui/lens/LensApplication.java ! glass/glass/src/com/sun/glass/ui/lens/LensPixels.java ! glass/glass/src/com/sun/glass/ui/lens/LensRobot.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java ! glass/glass/src/com/sun/glass/ui/mac/MacPixels.java ! glass/glass/src/com/sun/glass/ui/mac/MacRobot.java ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java ! glass/glass/src/com/sun/glass/ui/swt/SWTPixels.java ! glass/glass/src/com/sun/glass/ui/swt/SWTRobot.java ! glass/glass/src/com/sun/glass/ui/win/WinApplication.java ! glass/glass/src/com/sun/glass/ui/win/WinPixels.java ! glass/glass/src/com/sun/glass/ui/win/WinRobot.java From hang.vo at oracle.com Thu Mar 7 05:18:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 13:18:05 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28493 Gtk: calling stage.setResizable(false) does not work on Ubuntu Linux Message-ID: <20130307131812.BE3F847DEC@hg.openjdk.java.net> Changeset: 8e27b105aa5f Author: Alexander Zvegintsev Date: 2013-03-07 16:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8e27b105aa5f RT-28493 Gtk: calling stage.setResizable(false) does not work on Ubuntu Linux ! glass/glass-lib-gtk/src/GlassApplication.cpp ! glass/glass-lib-gtk/src/glass_window.cpp ! glass/glass-lib-gtk/src/glass_window.h From kevin.rushforth at oracle.com Thu Mar 7 06:25:27 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 07 Mar 2013 06:25:27 -0800 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> Message-ID: <5138A357.7010308@oracle.com> There is already a JIRA filed for this: http://javafx-jira.kenai.com/browse/RT-15314 -- Kevin Hendrik Ebbers wrote: > +1 > > Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : > > >> Hi, >> >> Yes please! Make the fullscreen hint optional. The warning might be warranted for JavaFX applications running in the browser (if there is still somebody out there with an enabled Java Plug-in *hint hint*, sorry :p ). For desktop applications it is quite unnecessary IMO and in addition to the warning, the keybinding (ESC) hurts, too: Games for instance usually show a menu and pause the game when pressing ESC. >> >> In addition to the options outlined by Tom (from which I would choose "b)", I would like to throw in an additional one: >> >> c) If the JavaFX app is running from within the browser keep the current behavior. >> If it is running as a stand alone app, enter fullscreen silently, don't show a warning and don't associate ESC with setFullScreen(false) >> >> Cheers, >> ~ Philipp >> >> Am 07.03.2013 um 11:24 schrieb Tom Schindl : >> >> >>> Hi, >>> >>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>> out if my point of view is completely wrong. >>> >>> If you currently put a Stage into Fullscreen mode it displays the >>> message "Press ESC to exit full-screen mode.". >>> >>> The first problem with the overlay presented is that while the Group is >>> big enough for the English-Text it looks like nobody ever checked this >>> with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus >>> zu beenden.") - I'll file a JIRA for it anyways. >>> >>> Still this is not my problem. What I'd like to suggest is that I as a >>> developer can turn of the forced overlay. >>> >>> I could think of multiple possibilities: >>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>> b) through an API on the Stage >>> >>> What do you think about a) or b) is there a chance to get something like >>> this in FX8, or is it too late already? Do you see any reason turning of >>> the overlay could cause problems? >>> >>> Since the quantum sources are now available I'd be able to implement a >>> desired feature using a) or b) and provide a patch. >>> >>> Tom >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >>> From tom.schindl at bestsolution.at Thu Mar 7 06:57:15 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 07 Mar 2013 15:57:15 +0100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138A357.7010308@oracle.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> Message-ID: <5138AACB.5020200@bestsolution.at> Hi Kevin, So because it is not scheduled for a release I guess there's no chance it gets included in JFX8 (although it has 42 votes as of now) because we are post API freeze. Like I said because the source is now open I'm happy to work on a patch but for this I'd first like to know if it could be in any circumstance considered for FX8 or it simply is too late. Tom Am 07.03.13 15:25, schrieb Kevin Rushforth: > There is already a JIRA filed for this: > http://javafx-jira.kenai.com/browse/RT-15314 > > -- Kevin > > > Hendrik Ebbers wrote: >> +1 >> >> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : >> >> >>> Hi, >>> >>> Yes please! Make the fullscreen hint optional. The warning might be >>> warranted for JavaFX applications running in the browser (if there is >>> still somebody out there with an enabled Java Plug-in *hint hint*, >>> sorry :p ). For desktop applications it is quite unnecessary IMO and >>> in addition to the warning, the keybinding (ESC) hurts, too: Games >>> for instance usually show a menu and pause the game when pressing ESC. >>> >>> In addition to the options outlined by Tom (from which I would choose >>> "b)", I would like to throw in an additional one: >>> >>> c) If the JavaFX app is running from within the browser keep the >>> current behavior. >>> If it is running as a stand alone app, enter fullscreen silently, >>> don't show a warning and don't associate ESC with setFullScreen(false) >>> >>> Cheers, >>> ~ Philipp >>> >>> Am 07.03.2013 um 11:24 schrieb Tom Schindl >>> : >>> >>> >>>> Hi, >>>> >>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>>> out if my point of view is completely wrong. >>>> >>>> If you currently put a Stage into Fullscreen mode it displays the >>>> message "Press ESC to exit full-screen mode.". >>>> >>>> The first problem with the overlay presented is that while the Group is >>>> big enough for the English-Text it looks like nobody ever checked this >>>> with the german translation ("Dr\u00FCcken Sie ESC, um den >>>> Vollbildmodus >>>> zu beenden.") - I'll file a JIRA for it anyways. >>>> >>>> Still this is not my problem. What I'd like to suggest is that I as a >>>> developer can turn of the forced overlay. >>>> >>>> I could think of multiple possibilities: >>>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>>> b) through an API on the Stage >>>> >>>> What do you think about a) or b) is there a chance to get something >>>> like >>>> this in FX8, or is it too late already? Do you see any reason >>>> turning of >>>> the overlay could cause problems? >>>> >>>> Since the quantum sources are now available I'd be able to implement a >>>> desired feature using a) or b) and provide a patch. >>>> >>>> Tom >>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>> GmbH >>>> ------------------------------------------------------------------------ >>>> >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>> 935833 >>>> http://www.BestSolution.at phone ++43 512 >>>> 935834 >>>> -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Thu Mar 7 07:01:27 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Mar 2013 07:01:27 -0800 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138A357.7010308@oracle.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> Message-ID: I don't see any reason why it ought not be replaceable. Of course if there is a security manager installed we need to check for permissions before doing it. I guess just "showFullscreenOverlay" boolean? On Mar 7, 2013, at 6:25 AM, Kevin Rushforth wrote: > There is already a JIRA filed for this: http://javafx-jira.kenai.com/browse/RT-15314 > > -- Kevin > > > Hendrik Ebbers wrote: >> +1 >> >> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : >> >> >>> Hi, >>> >>> Yes please! Make the fullscreen hint optional. The warning might be warranted for JavaFX applications running in the browser (if there is still somebody out there with an enabled Java Plug-in *hint hint*, sorry :p ). For desktop applications it is quite unnecessary IMO and in addition to the warning, the keybinding (ESC) hurts, too: Games for instance usually show a menu and pause the game when pressing ESC. >>> >>> In addition to the options outlined by Tom (from which I would choose "b)", I would like to throw in an additional one: >>> >>> c) If the JavaFX app is running from within the browser keep the current behavior. >>> If it is running as a stand alone app, enter fullscreen silently, don't show a warning and don't associate ESC with setFullScreen(false) >>> >>> Cheers, >>> ~ Philipp >>> >>> Am 07.03.2013 um 11:24 schrieb Tom Schindl : >>> >>> >>>> Hi, >>>> >>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>>> out if my point of view is completely wrong. >>>> >>>> If you currently put a Stage into Fullscreen mode it displays the >>>> message "Press ESC to exit full-screen mode.". >>>> >>>> The first problem with the overlay presented is that while the Group is >>>> big enough for the English-Text it looks like nobody ever checked this >>>> with the german translation ("Dr\u00FCcken Sie ESC, um den Vollbildmodus >>>> zu beenden.") - I'll file a JIRA for it anyways. >>>> >>>> Still this is not my problem. What I'd like to suggest is that I as a >>>> developer can turn of the forced overlay. >>>> >>>> I could think of multiple possibilities: >>>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>>> b) through an API on the Stage >>>> >>>> What do you think about a) or b) is there a chance to get something like >>>> this in FX8, or is it too late already? Do you see any reason turning of >>>> the overlay could cause problems? >>>> >>>> Since the quantum sources are now available I'd be able to implement a >>>> desired feature using a) or b) and provide a patch. >>>> >>>> Tom >>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>> ------------------------------------------------------------------------ >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>> http://www.BestSolution.at phone ++43 512 935834 >>>> From richard.bair at oracle.com Thu Mar 7 07:01:58 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Mar 2013 07:01:58 -0800 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138AACB.5020200@bestsolution.at> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> <5138AACB.5020200@bestsolution.at> Message-ID: If you send a patch we'll take it. On Mar 7, 2013, at 6:57 AM, Tom Schindl wrote: > Hi Kevin, > > So because it is not scheduled for a release I guess there's no chance > it gets included in JFX8 (although it has 42 votes as of now) because we > are post API freeze. > > Like I said because the source is now open I'm happy to work on a patch > but for this I'd first like to know if it could be in any circumstance > considered for FX8 or it simply is too late. > > Tom > > Am 07.03.13 15:25, schrieb Kevin Rushforth: >> There is already a JIRA filed for this: >> http://javafx-jira.kenai.com/browse/RT-15314 >> >> -- Kevin >> >> >> Hendrik Ebbers wrote: >>> +1 >>> >>> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : >>> >>> >>>> Hi, >>>> >>>> Yes please! Make the fullscreen hint optional. The warning might be >>>> warranted for JavaFX applications running in the browser (if there is >>>> still somebody out there with an enabled Java Plug-in *hint hint*, >>>> sorry :p ). For desktop applications it is quite unnecessary IMO and >>>> in addition to the warning, the keybinding (ESC) hurts, too: Games >>>> for instance usually show a menu and pause the game when pressing ESC. >>>> >>>> In addition to the options outlined by Tom (from which I would choose >>>> "b)", I would like to throw in an additional one: >>>> >>>> c) If the JavaFX app is running from within the browser keep the >>>> current behavior. >>>> If it is running as a stand alone app, enter fullscreen silently, >>>> don't show a warning and don't associate ESC with setFullScreen(false) >>>> >>>> Cheers, >>>> ~ Philipp >>>> >>>> Am 07.03.2013 um 11:24 schrieb Tom Schindl >>>> : >>>> >>>> >>>>> Hi, >>>>> >>>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>>>> out if my point of view is completely wrong. >>>>> >>>>> If you currently put a Stage into Fullscreen mode it displays the >>>>> message "Press ESC to exit full-screen mode.". >>>>> >>>>> The first problem with the overlay presented is that while the Group is >>>>> big enough for the English-Text it looks like nobody ever checked this >>>>> with the german translation ("Dr\u00FCcken Sie ESC, um den >>>>> Vollbildmodus >>>>> zu beenden.") - I'll file a JIRA for it anyways. >>>>> >>>>> Still this is not my problem. What I'd like to suggest is that I as a >>>>> developer can turn of the forced overlay. >>>>> >>>>> I could think of multiple possibilities: >>>>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>>>> b) through an API on the Stage >>>>> >>>>> What do you think about a) or b) is there a chance to get something >>>>> like >>>>> this in FX8, or is it too late already? Do you see any reason >>>>> turning of >>>>> the overlay could cause problems? >>>>> >>>>> Since the quantum sources are now available I'd be able to implement a >>>>> desired feature using a) or b) and provide a patch. >>>>> >>>>> Tom >>>>> >>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>> GmbH >>>>> ------------------------------------------------------------------------ >>>>> >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------------------------------------------------ >>>>> >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>> 935833 >>>>> http://www.BestSolution.at phone ++43 512 >>>>> 935834 > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From David.Hill at Oracle.com Thu Mar 7 07:12:59 2013 From: David.Hill at Oracle.com (David Hill) Date: Thu, 07 Mar 2013 10:12:59 -0500 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138AACB.5020200@bestsolution.at> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> <5138AACB.5020200@bestsolution.at> Message-ID: <5138AE7B.90902@Oracle.com> On 3/7/13 Mar 7, 9:57 AM, Tom Schindl wrote: > Hi Kevin, > > So because it is not scheduled for a release I guess there's no chance > it gets included in JFX8 (although it has 42 votes as of now) because we > are post API freeze. > > Like I said because the source is now open I'm happy to work on a patch > but for this I'd first like to know if it could be in any circumstance > considered for FX8 or it simply is too late. The Embedded team has a related issue ( RT-25018 ) that will need to be addressed before SE8, so I think this likely to be resolved with that. Our problem is that in a touch only situation, the extra insult is that there is no ESC key to press.... Also - our target market is one which the apps will generally be fullscreen. Dave > > Tom > > Am 07.03.13 15:25, schrieb Kevin Rushforth: >> There is already a JIRA filed for this: >> http://javafx-jira.kenai.com/browse/RT-15314 >> >> -- Kevin >> >> >> Hendrik Ebbers wrote: >>> +1 >>> >>> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler : >>> >>> >>>> Hi, >>>> >>>> Yes please! Make the fullscreen hint optional. The warning might be >>>> warranted for JavaFX applications running in the browser (if there is >>>> still somebody out there with an enabled Java Plug-in *hint hint*, >>>> sorry :p ). For desktop applications it is quite unnecessary IMO and >>>> in addition to the warning, the keybinding (ESC) hurts, too: Games >>>> for instance usually show a menu and pause the game when pressing ESC. >>>> >>>> In addition to the options outlined by Tom (from which I would choose >>>> "b)", I would like to throw in an additional one: >>>> >>>> c) If the JavaFX app is running from within the browser keep the >>>> current behavior. >>>> If it is running as a stand alone app, enter fullscreen silently, >>>> don't show a warning and don't associate ESC with setFullScreen(false) >>>> >>>> Cheers, >>>> ~ Philipp >>>> >>>> Am 07.03.2013 um 11:24 schrieb Tom Schindl >>>> : >>>> >>>> >>>>> Hi, >>>>> >>>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>>>> out if my point of view is completely wrong. >>>>> >>>>> If you currently put a Stage into Fullscreen mode it displays the >>>>> message "Press ESC to exit full-screen mode.". >>>>> >>>>> The first problem with the overlay presented is that while the Group is >>>>> big enough for the English-Text it looks like nobody ever checked this >>>>> with the german translation ("Dr\u00FCcken Sie ESC, um den >>>>> Vollbildmodus >>>>> zu beenden.") - I'll file a JIRA for it anyways. >>>>> >>>>> Still this is not my problem. What I'd like to suggest is that I as a >>>>> developer can turn of the forced overlay. >>>>> >>>>> I could think of multiple possibilities: >>>>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>>>> b) through an API on the Stage >>>>> >>>>> What do you think about a) or b) is there a chance to get something >>>>> like >>>>> this in FX8, or is it too late already? Do you see any reason >>>>> turning of >>>>> the overlay could cause problems? >>>>> >>>>> Since the quantum sources are now available I'd be able to implement a >>>>> desired feature using a) or b) and provide a patch. >>>>> >>>>> Tom >>>>> >>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>> GmbH >>>>> ------------------------------------------------------------------------ >>>>> >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------------------------------------------------ >>>>> >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>> 935833 >>>>> http://www.BestSolution.at phone ++43 512 >>>>> 935834 >>>>> > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From steve.x.northover at oracle.com Thu Mar 7 08:15:27 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 07 Mar 2013 11:15:27 -0500 Subject: JavaFX Threading In-Reply-To: <00b901ce1ac4$bfa38540$3eea8fc0$@com.au> References: <5137818E.4020100@oracle.com> <00b901ce1ac4$bfa38540$3eea8fc0$@com.au> Message-ID: <5138BD1F.8010308@oracle.com> Here is a link that describes the current architecture: http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm Steve On 06/03/2013 6:45 PM, John C. Turnbull wrote: > Is there a document/link that describes in some detail the threading architecture of JavaFX along with things such as defining the "pulse" and the rendering pipeline? > > Thanks, > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of steve.x.northover at oracle.com > Sent: Thursday, 7 March 2013 04:49 > To: openjfx-dev at openjdk.java.net > Subject: JavaFX Threading > > Hi all, > > One of the great things about JavaFX is that it has a consistent threading model that maps well on to the underlying platforms. There is a single distinguished GUI-thread that is also the GUI-thread for the window system. This makes JavaFX GUI behavior consistent and deterministic. In general, running code in the GUI thread is a good thing for these reasons and others, provided that the code is not long running. In the case of long running code, JavaFX objects may be created in background threads as long are they are not attached to the scene graph. > > JavaFX applications have a life cycle that includes, construction, init(), start() and stop(). The start() method is the most important and runs in the GUI-thread. The init() method is guaranteed to run in a background thread and is the place where long running creation code can reside. The start() method will always run after init() has completed. > With a preloader, the start() of the preloader runs at the same time as the init() of the application. The stop() method is also guaranteed to run in the GUI-thread. > > What about application construction? > > Today, this is unspecified and happens in a background thread. We are considering moving this to the GUI-thread. Here is the JIRA that is tracking this work: > > http://javafx-jira.kenai.com/browse/RT-28754 > > If you are interested, add yourself, please add yourself to it and comment either there or on this list, > > Thanks! > Steve > > From hang.vo at oracle.com Thu Mar 7 08:33:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 16:33:36 +0000 Subject: hg: openjfx/8/graphics/rt: 50 new changesets Message-ID: <20130307163650.60ABE47E03@hg.openjdk.java.net> Changeset: c74b831540ef Author: Paru Somashekar Date: 2013-02-26 13:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c74b831540ef RT-23116 BarChart issue with additional category is added. ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 3955b0ebae71 Author: David Grieve Date: 2013-02-26 17:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3955b0ebae71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 405afceac406 Author: Paru Somashekar Date: 2013-02-26 16:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/405afceac406 RT-23141 : MenuBar focused state is not displayed ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java Changeset: a3e606ef6ead Author: jgiles Date: 2013-02-27 14:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a3e606ef6ead RT-28659: Replace ComboBox.emptyText with ListView.placeholder and ComboBox.placeholder API ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: fde1462f251b Author: jgiles Date: 2013-02-27 15:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fde1462f251b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: beb98f6c0fb0 Author: jgiles Date: 2013-02-27 15:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/beb98f6c0fb0 Backing out a part of the RT-24916 changeset, in particular the addition of ScrollPane.scrollTo(Node) as we are not ready to commit to public API yet. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java Changeset: fbd0b103d3a4 Author: Paru Somashekar Date: 2013-02-26 19:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbd0b103d3a4 fixed broken BarChart unit test ! javafx-ui-charts/test/javafx/scene/chart/BarChartTest.java Changeset: 4b27cc4bf069 Author: Felipe Heidrich Date: 2013-02-27 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4b27cc4bf069 RT-27762: Text not centered vertically in bounds for windows default 12px ! javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextBoundsType.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java Changeset: eae1d1d854f8 Author: jgiles Date: 2013-02-28 11:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eae1d1d854f8 Back out a performance optimisation in TreeCell due to a functional regression where a cell index could be unchanged yet the TreeItem it was representing has changed. This has already been done for TreeTableView. ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: ccc6cd50dfd2 Author: jgiles Date: 2013-02-28 11:01 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ccc6cd50dfd2 Backout small portion of RT-24725 as it does not seem necessary and it led to performance regressions in certain situations. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: f77e1803a0ee Author: jgiles Date: 2013-02-28 14:35 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f77e1803a0ee RT-28556: [TreeView] Alignment after sorting is incorrect. ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java + javafx-ui-controls/test/com/sun/javafx/scene/control/test/Employee.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: f2f7919df9c2 Author: jgiles Date: 2013-03-01 09:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f2f7919df9c2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: f4084b9ecd79 Author: David Grieve Date: 2013-02-28 15:54 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4084b9ecd79 RT-28660: use arrays to hold cache entries for faster access ! javafx-ui-common/src/com/sun/javafx/css/BitSet.java ! javafx-ui-common/src/com/sun/javafx/css/StyleCache.java ! javafx-ui-common/src/com/sun/javafx/css/StyleCacheEntry.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: 927188e77e2c Author: Daniel Blaukopf Date: 2013-03-01 03:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/927188e77e2c Touch stylesheet for Modena, copied from Caspian ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/touch.css Changeset: 7a6a30b004c8 Author: David Grieve Date: 2013-03-01 11:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a6a30b004c8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 39bb41c52de5 Author: "Jasper Potts" Date: 2013-03-01 10:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/39bb41c52de5 Modena app, changed to Java project from FX project. Moved fonts to menu rather than button. ! apps/experiments/Modena/build.xml ! apps/experiments/Modena/nbproject/build-impl.xml - apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties - apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties ! apps/experiments/Modena/nbproject/genfiles.properties - apps/experiments/Modena/nbproject/jfx-impl.xml - apps/experiments/Modena/nbproject/jfx-impl_backup.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_2.xml ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/nbproject/project.xml ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java Changeset: 1908325045af Author: "Jasper Potts" Date: 2013-03-01 11:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1908325045af Fixed RT-28223: Fix controls heights to be consistent. reviewed by Jonathan and Rich. This includeds fixes to controls to utilize new API from RT-27762 also fixes for padding snapping to pixel in consitant way. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabelSkinTest.java Changeset: fe536d52fcd7 Author: "Jasper Potts" Date: 2013-03-01 12:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe536d52fcd7 Modena test app, fixed project. Updated alignment page to move lines to match font size. ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SameHeightTest.fxml + apps/experiments/Modena/src/modena/SameHeightTest.fxml.bak + apps/experiments/Modena/src/modena/SameHeightTestController.java ! apps/experiments/Modena/src/modena/SamplePage.java Changeset: c33368d498fd Author: "Jasper Potts" Date: 2013-03-01 17:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c33368d498fd Added Modena to intellij project + apps/experiments/Modena/Modena.iml Changeset: 43c640c06b87 Author: "Jasper Potts" Date: 2013-03-01 17:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/43c640c06b87 Modena test app, enlarged vertical tab examples so can see more than one tab ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java Changeset: 3ffac5400582 Author: "Jasper Potts" Date: 2013-03-01 18:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3ffac5400582 Fixed RT-28758: REGRESSION: ComboBoxes are much wider by default ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 8ee27ba99e2a Author: "Jasper Potts" Date: 2013-03-01 18:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8ee27ba99e2a Modena CSS cleanup of file. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 7f9c1f256882 Author: Paru Somashekar Date: 2013-03-02 23:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7f9c1f256882 RT-28367 Clean up AccessibleList, AccessibleListItem; RT-28419 Slider knob rendered outside RT-26025 ChoiceBox right click opens both popup and context menu. ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleList.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleListItem.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: 7a0dc6ed9c7b Author: Paru Somashekar Date: 2013-03-03 01:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a0dc6ed9c7b RT-26025, removed debug output left behind by accident. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java Changeset: 0eb24b573aec Author: David Grieve Date: 2013-03-04 16:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0eb24b573aec RT-28768: when looking up parent cache entry for inherited font, if parent cache entry's font is null, find the font to use. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: f4857dbc5287 Author: David Grieve Date: 2013-03-04 16:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4857dbc5287 RT-28769: check for null styleHelper in impl_getStyleMap and impl_setStyleMap ! javafx-ui-common/src/javafx/scene/Node.java Changeset: c99b1563212f Author: "Jasper Potts" Date: 2013-03-04 11:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c99b1563212f Modena test app, added pill buttons same text example ! apps/experiments/Modena/src/modena/SamplePage.java Changeset: 6d47b9a930db Author: "Jasper Potts" Date: 2013-03-04 11:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6d47b9a930db Modena UI tweeks ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: f4c5ee1d15b1 Author: "Jasper Potts" Date: 2013-03-04 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4c5ee1d15b1 Modena make chart legened more subtle. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 044e79cda8fe Author: "Jasper Potts" Date: 2013-03-04 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/044e79cda8fe MERGE AFTER : Modena make chart legened more subtle. Changeset: 13c375a722d0 Author: David Grieve Date: 2013-03-04 17:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/13c375a722d0 RT-28760: list of ua stylesheets might contain nulls ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 6240fcb97940 Author: David Grieve Date: 2013-03-04 17:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6240fcb97940 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: fd3743c5c84d Author: "Jasper Potts" Date: 2013-03-04 15:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fd3743c5c84d Modena chart gridlines making dashed in both H and V as feels better ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 649ecc9fc736 Author: "Jasper Potts" Date: 2013-03-04 15:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/649ecc9fc736 Merge Changeset: 0973fa2d0c6f Author: "Jasper Potts" Date: 2013-03-04 17:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0973fa2d0c6f Modena: fix toolbars anding support for right and bottom styleclasses for special cases. Added spacing for overflow arrow when vertical. Modena app added test cases for RIGHT and BOTTOM toolbars. Modena App added refresh support for stylesheet when running from IntelliJ ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 959641c9fede Author: jgiles Date: 2013-03-01 09:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/959641c9fede RT-28668: Ensemble tree arrow disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 19a14723a52d Author: jgiles Date: 2013-03-02 19:11 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19a14723a52d RT-22463: It should be possible to clear a TableView items list, and subsequently set a new items list in a TableView where the contents are considered equal (that is, equals() returns true), with the expectation that the new text is displayed rather than the old text (by the fact that the old items were first cleared out - if they weren't then we would still likely see the old items). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: 8a3b4ebaa2be Author: jgiles Date: 2013-03-02 19:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8a3b4ebaa2be Slight update for RT-28668: Ensemble tree arrow disappears (plays nicer with the CSS engine now). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: c3376fd7fd9a Author: jgiles Date: 2013-03-05 11:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c3376fd7fd9a Finishing off unit tests for RT-22463 for ListView, TreeView, TableView and TreeTableView ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java + javafx-ui-controls/test/com/sun/javafx/scene/control/test/RT_22463_Person.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: f77115aa3398 Author: jgiles Date: 2013-03-05 11:19 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f77115aa3398 Added (currently @Ignore'd) unit tests for RT-28637: [ListView, TreeView, TableView, TreeTableView] selectionModel selectedItem returns wrong item. ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: d50ad13e2f3c Author: jgiles Date: 2013-03-05 19:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d50ad13e2f3c Adding (currently @Ignore'd) unit tests for RT-28615: ListChangeListener on MultipleSelectionModel selectedItems does not always report correct item added. ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java Changeset: ece1fe2f059b Author: jgiles Date: 2013-03-05 19:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ece1fe2f059b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: ab59ba026313 Author: Paru Somashekar Date: 2013-03-05 06:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab59ba026313 RT-28773 : BarChart empty space on axis ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 3e08d75e32a1 Author: mickf Date: 2013-03-05 19:05 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e08d75e32a1 RT-28052 : optimise converters ! javafx-ui-common/src/com/sun/javafx/css/ParsedValueImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/converters/EnumConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/RepeatStructConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java Changeset: 9170500c6400 Author: David Grieve Date: 2013-03-05 17:32 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9170500c6400 RT-28022: fix url resolution for @font-face ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: f4bbc8b8b78c Author: David Grieve Date: 2013-03-05 17:32 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4bbc8b8b78c RT-28769: follow on fixes after feedback from scene builder folks. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: ed8f9c83d575 Author: Paru Somashekar Date: 2013-03-06 06:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ed8f9c83d575 RT-26633 ColorPicker setValue partially reflects changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 26b012b132f9 Author: David Grieve Date: 2013-03-06 11:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26b012b132f9 RT-20906: add -fx-[min|pref|max]-[width|height] css properties to Region. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 637a0d67106f Author: David Grieve Date: 2013-03-06 11:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/637a0d67106f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties - apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties - apps/experiments/Modena/nbproject/jfx-impl.xml - apps/experiments/Modena/nbproject/jfx-impl_backup.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_2.xml Changeset: 7ab5cc8ac4a7 Author: jgodinez Date: 2013-03-07 08:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7ab5cc8ac4a7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java From ozemale at ozemail.com.au Thu Mar 7 09:02:15 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 8 Mar 2013 04:02:15 +1100 Subject: JavaFX Threading In-Reply-To: <5138BD1F.8010308@oracle.com> References: <5137818E.4020100@oracle.com> <00b901ce1ac4$bfa38540$3eea8fc0$@com.au> <5138BD1F.8010308@oracle.com> Message-ID: Perfect! Thanks Steve. On 08/03/2013, at 3:15, steve.x.northover at oracle.com wrote: > Here is a link that describes the current architecture: http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm > > Steve > > On 06/03/2013 6:45 PM, John C. Turnbull wrote: >> Is there a document/link that describes in some detail the threading architecture of JavaFX along with things such as defining the "pulse" and the rendering pipeline? >> >> Thanks, >> >> -jct >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of steve.x.northover at oracle.com >> Sent: Thursday, 7 March 2013 04:49 >> To: openjfx-dev at openjdk.java.net >> Subject: JavaFX Threading >> >> Hi all, >> >> One of the great things about JavaFX is that it has a consistent threading model that maps well on to the underlying platforms. There is a single distinguished GUI-thread that is also the GUI-thread for the window system. This makes JavaFX GUI behavior consistent and deterministic. In general, running code in the GUI thread is a good thing for these reasons and others, provided that the code is not long running. In the case of long running code, JavaFX objects may be created in background threads as long are they are not attached to the scene graph. >> >> JavaFX applications have a life cycle that includes, construction, init(), start() and stop(). The start() method is the most important and runs in the GUI-thread. The init() method is guaranteed to run in a background thread and is the place where long running creation code can reside. The start() method will always run after init() has completed. >> With a preloader, the start() of the preloader runs at the same time as the init() of the application. The stop() method is also guaranteed to run in the GUI-thread. >> >> What about application construction? >> >> Today, this is unspecified and happens in a background thread. We are considering moving this to the GUI-thread. Here is the JIRA that is tracking this work: >> >> http://javafx-jira.kenai.com/browse/RT-28754 >> >> If you are interested, add yourself, please add yourself to it and comment either there or on this list, >> >> Thanks! >> Steve >> >> From David.Hill at Oracle.com Thu Mar 7 09:06:39 2013 From: David.Hill at Oracle.com (David Hill) Date: Thu, 07 Mar 2013 12:06:39 -0500 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138AE7B.90902@Oracle.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> <5138AACB.5020200@bestsolution.at> <5138AE7B.90902@Oracle.com> Message-ID: <5138C91F.1060702@Oracle.com> On 3/7/13 Mar 7, 10:12 AM, David Hill wrote: > On 3/7/13 Mar 7, 9:57 AM, Tom Schindl wrote: >> Hi Kevin, >> >> So because it is not scheduled for a release I guess there's no chance >> it gets included in JFX8 (although it has 42 votes as of now) because we >> are post API freeze. >> >> Like I said because the source is now open I'm happy to work on a patch >> but for this I'd first like to know if it could be in any circumstance >> considered for FX8 or it simply is too late. > > The Embedded team has a related issue ( RT-25018 ) that will need to be addressed before SE8, so I think this likely to be resolved with that. Our problem is that in a touch only situation, the extra insult is that there is no ESC key to press.... Also - our target market is one which the apps will generally be fullscreen. Tom, if you would like to work on this, I would be happy to help and get it committed. There are a couple of ways we would want to make it so that we could disable the ESC message: A Stage API Detect when there is no keyboard present (likely in many Embedded applications). The Stage API would allow dedicated applications (like in a kiosk) to declare their dislike of the message. What should we use for a name though ? Nothing I have thought of so far is very pleasant. Stage.setDisableFullScreenWarning() (ick) Kevin suggested to me: Stage.setEnableFullScreenWarning(boolean) with a default of true. Dave Hill > > Dave >> Tom >> >> Am 07.03.13 15:25, schrieb Kevin Rushforth: >>> There is already a JIRA filed for this: >>> http://javafx-jira.kenai.com/browse/RT-15314 >>> >>> -- Kevin >>> >>> >>> Hendrik Ebbers wrote: >>>> +1 >>>> >>>> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler: >>>> >>>> >>>>> Hi, >>>>> >>>>> Yes please! Make the fullscreen hint optional. The warning might be >>>>> warranted for JavaFX applications running in the browser (if there is >>>>> still somebody out there with an enabled Java Plug-in *hint hint*, >>>>> sorry :p ). For desktop applications it is quite unnecessary IMO and >>>>> in addition to the warning, the keybinding (ESC) hurts, too: Games >>>>> for instance usually show a menu and pause the game when pressing ESC. >>>>> >>>>> In addition to the options outlined by Tom (from which I would choose >>>>> "b)", I would like to throw in an additional one: >>>>> >>>>> c) If the JavaFX app is running from within the browser keep the >>>>> current behavior. >>>>> If it is running as a stand alone app, enter fullscreen silently, >>>>> don't show a warning and don't associate ESC with setFullScreen(false) >>>>> >>>>> Cheers, >>>>> ~ Philipp >>>>> >>>>> Am 07.03.2013 um 11:24 schrieb Tom Schindl >>>>> : >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>>>>> out if my point of view is completely wrong. >>>>>> >>>>>> If you currently put a Stage into Fullscreen mode it displays the >>>>>> message "Press ESC to exit full-screen mode.". >>>>>> >>>>>> The first problem with the overlay presented is that while the Group is >>>>>> big enough for the English-Text it looks like nobody ever checked this >>>>>> with the german translation ("Dr\u00FCcken Sie ESC, um den >>>>>> Vollbildmodus >>>>>> zu beenden.") - I'll file a JIRA for it anyways. >>>>>> >>>>>> Still this is not my problem. What I'd like to suggest is that I as a >>>>>> developer can turn of the forced overlay. >>>>>> >>>>>> I could think of multiple possibilities: >>>>>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>>>>> b) through an API on the Stage >>>>>> >>>>>> What do you think about a) or b) is there a chance to get something >>>>>> like >>>>>> this in FX8, or is it too late already? Do you see any reason >>>>>> turning of >>>>>> the overlay could cause problems? >>>>>> >>>>>> Since the quantum sources are now available I'd be able to implement a >>>>>> desired feature using a) or b) and provide a patch. >>>>>> >>>>>> Tom >>>>>> >>>>>> -- >>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>> GmbH >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>> 935833 >>>>>> http://www.BestSolution.at phone ++43 512 >>>>>> 935834 >>>>>> > > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey the world." > -- George Santayana (1863 - 1952) -- David Hill Java Embedded Development "Hell, there are no rules here-- we're trying to accomplish something." -- Thomas A. Edison (1847 - 1931) From ozemale at ozemail.com.au Thu Mar 7 09:38:02 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 8 Mar 2013 04:38:02 +1100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138C91F.1060702@Oracle.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> <5138AACB.5020200@bestsolution.at> <5138AE7B.90902@Oracle.com> <5138C91F.1060702@Oracle.com> Message-ID: <4D448AF0-8915-4063-938F-673BC1E33963@ozemail.com.au> I think you need to be able to set whether or not the warning appears but also the text of the warning. The default text of the warning may not be suitable for all situations so it would be helpful to have it customisable. On 08/03/2013, at 4:06, David Hill wrote: > On 3/7/13 Mar 7, 10:12 AM, David Hill wrote: >> On 3/7/13 Mar 7, 9:57 AM, Tom Schindl wrote: >>> Hi Kevin, >>> >>> So because it is not scheduled for a release I guess there's no chance >>> it gets included in JFX8 (although it has 42 votes as of now) because we >>> are post API freeze. >>> >>> Like I said because the source is now open I'm happy to work on a patch >>> but for this I'd first like to know if it could be in any circumstance >>> considered for FX8 or it simply is too late. >> >> The Embedded team has a related issue ( RT-25018 ) that will need to be addressed before SE8, so I think this likely to be resolved with that. Our problem is that in a touch only situation, the extra insult is that there is no ESC key to press.... Also - our target market is one which the apps will generally be fullscreen. > Tom, > if you would like to work on this, I would be happy to help and get it committed. > > There are a couple of ways we would want to make it so that we could disable the ESC message: > A Stage API > Detect when there is no keyboard present (likely in many Embedded applications). > > The Stage API would allow dedicated applications (like in a kiosk) to declare their dislike of the message. > What should we use for a name though ? Nothing I have thought of so far is very pleasant. > Stage.setDisableFullScreenWarning() (ick) > Kevin suggested to me: > Stage.setEnableFullScreenWarning(boolean) with a default of true. > > > Dave Hill >> >> Dave >>> Tom >>> >>> Am 07.03.13 15:25, schrieb Kevin Rushforth: >>>> There is already a JIRA filed for this: >>>> http://javafx-jira.kenai.com/browse/RT-15314 >>>> >>>> -- Kevin >>>> >>>> >>>> Hendrik Ebbers wrote: >>>>> +1 >>>>> >>>>> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Yes please! Make the fullscreen hint optional. The warning might be >>>>>> warranted for JavaFX applications running in the browser (if there is >>>>>> still somebody out there with an enabled Java Plug-in *hint hint*, >>>>>> sorry :p ). For desktop applications it is quite unnecessary IMO and >>>>>> in addition to the warning, the keybinding (ESC) hurts, too: Games >>>>>> for instance usually show a menu and pause the game when pressing ESC. >>>>>> >>>>>> In addition to the options outlined by Tom (from which I would choose >>>>>> "b)", I would like to throw in an additional one: >>>>>> >>>>>> c) If the JavaFX app is running from within the browser keep the >>>>>> current behavior. >>>>>> If it is running as a stand alone app, enter fullscreen silently, >>>>>> don't show a warning and don't associate ESC with setFullScreen(false) >>>>>> >>>>>> Cheers, >>>>>> ~ Philipp >>>>>> >>>>>> Am 07.03.2013 um 11:24 schrieb Tom Schindl >>>>>> : >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to find >>>>>>> out if my point of view is completely wrong. >>>>>>> >>>>>>> If you currently put a Stage into Fullscreen mode it displays the >>>>>>> message "Press ESC to exit full-screen mode.". >>>>>>> >>>>>>> The first problem with the overlay presented is that while the Group is >>>>>>> big enough for the English-Text it looks like nobody ever checked this >>>>>>> with the german translation ("Dr\u00FCcken Sie ESC, um den >>>>>>> Vollbildmodus >>>>>>> zu beenden.") - I'll file a JIRA for it anyways. >>>>>>> >>>>>>> Still this is not my problem. What I'd like to suggest is that I as a >>>>>>> developer can turn of the forced overlay. >>>>>>> >>>>>>> I could think of multiple possibilities: >>>>>>> a) through a System-Property (-Djavafx.quantum.fullscreenwarning=false) >>>>>>> b) through an API on the Stage >>>>>>> >>>>>>> What do you think about a) or b) is there a chance to get something >>>>>>> like >>>>>>> this in FX8, or is it too late already? Do you see any reason >>>>>>> turning of >>>>>>> the overlay could cause problems? >>>>>>> >>>>>>> Since the quantum sources are now available I'd be able to implement a >>>>>>> desired feature using a) or b) and provide a patch. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> -- >>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>>> GmbH >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>>> 935833 >>>>>>> http://www.BestSolution.at phone ++43 512 >>>>>>> 935834 >> >> >> -- >> David Hill >> Java Embedded Development >> >> "A man's feet should be planted in his country, but his eyes should survey the world." >> -- George Santayana (1863 - 1952) > > > -- > David Hill > Java Embedded Development > > "Hell, there are no rules here-- we're trying to accomplish something." > -- Thomas A. Edison (1847 - 1931) > From hang.vo at oracle.com Thu Mar 7 12:48:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 20:48:33 +0000 Subject: hg: openjfx/8/graphics/rt: Updated gradle build script to build on windows. Testing is not working yet on windows for Graphics project. Message-ID: <20130307204840.4A62C47E38@hg.openjdk.java.net> Changeset: a52bbebbcdb8 Author: rbair Date: 2013-03-07 12:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a52bbebbcdb8 Updated gradle build script to build on windows. Testing is not working yet on windows for Graphics project. ! build.gradle From hang.vo at oracle.com Thu Mar 7 14:04:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 22:04:10 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 Message-ID: <20130307220418.52D3147E3E@hg.openjdk.java.net> Changeset: 87b6bc4d05c2 Author: Yao Wang Date: 2013-03-07 13:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/87b6bc4d05c2 RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java + javafx-sg-prism/test/com/sun/javafx/sg/prism/NGTriangleMeshTest.java ! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java + javafx-ui-common/test/unit/javafx/scene/shape/TriangleMeshTest.java From hang.vo at oracle.com Thu Mar 7 14:04:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Mar 2013 22:04:10 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130307220428.3C59847E41@hg.openjdk.java.net> Changeset: 5cb29e82fed6 Author: "Jasper Potts" Date: 2013-03-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5cb29e82fed6 Intellij Project: Added Ensmeble 8 + apps/samples/Ensemble8/Ensemble8.iml Changeset: 180026bf2fca Author: "Jasper Potts" Date: 2013-03-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/180026bf2fca Modena: ComboBox menus were broken by yesterdays list view changes, fixed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From richard.bair at oracle.com Thu Mar 7 14:08:13 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Mar 2013 14:08:13 -0800 Subject: [API Review]: RT-28817 - Add explicit dispose() method to MediaPlayer In-Reply-To: <5137CC24.4050905@oracle.com> References: <5137CC24.4050905@oracle.com> Message-ID: <8DA2F1B7-7383-4901-AAFE-F4F5E0D15E4D@oracle.com> Hi Alexander, Sounds good. For reference, Skin also has a method called 'dispose' so I think we have the right name here. Note: http://docs.oracle.com/javafx/2/api/javafx/scene/control/Skin.html Be sure to spec in the JavaDoc for MediaPlayer & MediaView what it means when a MediaPlayer has been disposed. For example, if I dispose a MediaPlayer and then set it on a MediaView, what happens? I would suggest that nothing bad should happen (along the lines of Skin). However maybe we want to have an isDisposed method on MediaPlayer so developers can inspect a media player and know whether they should create a new one (in which case having a read only disposedProperty is also a good idea). All methods on the MediaPlayer need to specify their behavior when invoked on a disposed MediaPlayer. I think you're on the right path that dispose() can be called no matter what state the media player is in. Be sure to specify what state the player will be in after dispose is called. Also we need to have tests that ensure that the state transitions work correctly. Thanks! Richard On Mar 6, 2013, at 3:07 PM, Alexander Matveev wrote: > Hi all, > > Explicit dispose() method is needed to free native resources used by MediaPlayer. Garbage collector is not reliable enough to free native resources fast enough, thus when MediaPlayers are created fast enough we may run out of native memory. Normally, user does not need to call dispose() method on MediaPlayer if application does not create them often. After dispose() is called MediaPlayer cannot be used again and should be disregarded. Media and MediaView associated with disposed MediaPlayer can be reused. Dispose() will be valid in any states. For example, when player is playing call to dispose() will stop playback and release all resources. > > JIRA: > http://javafx-jira.kenai.com/browse/RT-28817 > > Thanks, > Alexander From richard.bair at oracle.com Thu Mar 7 14:10:04 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Mar 2013 14:10:04 -0800 Subject: [API Review]: RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes In-Reply-To: <51373EAF.9050709@oracle.com> References: <51373EAF.9050709@oracle.com> Message-ID: <7A30C9E3-917A-42B5-8582-5F2445A06EF6@oracle.com> Sounds good. Make sure we also have a selectedExtensionFilterProperty method that is a readonly property (unless we want the developer to be able to pre-select what the selected filter should be. Shouldn't that be supported? In which case, we need selectedExtensionFilterProperty to be writable and have a setSelectedExtensionFilter method as well?) Richard On Mar 6, 2013, at 5:03 AM, Alexander Zvegintsev wrote: > Hi all, > > In order to fix > http://javafx-jira.kenai.com/browse/RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes > we need to extend API of FileChooser: > > public final ExtensionFilter getSelectedExtensionFilter() > > Returns selected ExtensionFilter of last displayed file dialog. > It may be null if not supported by platform or dialog canceled. > > -- > Thanks, > > Alexander. > From tom.schindl at bestsolution.at Thu Mar 7 14:52:48 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 07 Mar 2013 23:52:48 +0100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138C91F.1060702@Oracle.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> <5138AACB.5020200@bestsolution.at> <5138AE7B.90902@Oracle.com> <5138C91F.1060702@Oracle.com> Message-ID: <51391A40.5050200@bestsolution.at> Hi David, That sounds great I'll writeup a proposal and will work on a patch. Tom Am 07.03.13 18:06, schrieb David Hill: > On 3/7/13 Mar 7, 10:12 AM, David Hill wrote: >> On 3/7/13 Mar 7, 9:57 AM, Tom Schindl wrote: >>> Hi Kevin, >>> >>> So because it is not scheduled for a release I guess there's no chance >>> it gets included in JFX8 (although it has 42 votes as of now) because we >>> are post API freeze. >>> >>> Like I said because the source is now open I'm happy to work on a patch >>> but for this I'd first like to know if it could be in any circumstance >>> considered for FX8 or it simply is too late. >> >> The Embedded team has a related issue ( RT-25018 >> ) that will need to be >> addressed before SE8, so I think this likely to be resolved with that. >> Our problem is that in a touch only situation, the extra insult is >> that there is no ESC key to press.... Also - our target market is one >> which the apps will generally be fullscreen. > Tom, > if you would like to work on this, I would be happy to help and get > it committed. > > There are a couple of ways we would want to make it so that we could > disable the ESC message: > A Stage API > Detect when there is no keyboard present (likely in many Embedded > applications). > > The Stage API would allow dedicated applications (like in a kiosk) to > declare their dislike of the message. > What should we use for a name though ? Nothing I have thought of so far > is very pleasant. > Stage.setDisableFullScreenWarning() (ick) > Kevin suggested to me: > Stage.setEnableFullScreenWarning(boolean) with a default of true. > > > Dave Hill >> >> Dave >>> Tom >>> >>> Am 07.03.13 15:25, schrieb Kevin Rushforth: >>>> There is already a JIRA filed for this: >>>> http://javafx-jira.kenai.com/browse/RT-15314 >>>> >>>> -- Kevin >>>> >>>> >>>> Hendrik Ebbers wrote: >>>>> +1 >>>>> >>>>> Am 07.03.2013 um 11:50 schrieb Philipp D?rfler: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Yes please! Make the fullscreen hint optional. The warning might be >>>>>> warranted for JavaFX applications running in the browser (if there is >>>>>> still somebody out there with an enabled Java Plug-in *hint hint*, >>>>>> sorry :p ). For desktop applications it is quite unnecessary IMO and >>>>>> in addition to the warning, the keybinding (ESC) hurts, too: Games >>>>>> for instance usually show a menu and pause the game when pressing >>>>>> ESC. >>>>>> >>>>>> In addition to the options outlined by Tom (from which I would choose >>>>>> "b)", I would like to throw in an additional one: >>>>>> >>>>>> c) If the JavaFX app is running from within the browser keep the >>>>>> current behavior. >>>>>> If it is running as a stand alone app, enter fullscreen silently, >>>>>> don't show a warning and don't associate ESC with >>>>>> setFullScreen(false) >>>>>> >>>>>> Cheers, >>>>>> ~ Philipp >>>>>> >>>>>> Am 07.03.2013 um 11:24 schrieb Tom Schindl >>>>>> : >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Before I file a JIRA-Ticket I'd like to start a dicussion here to >>>>>>> find >>>>>>> out if my point of view is completely wrong. >>>>>>> >>>>>>> If you currently put a Stage into Fullscreen mode it displays the >>>>>>> message "Press ESC to exit full-screen mode.". >>>>>>> >>>>>>> The first problem with the overlay presented is that while the >>>>>>> Group is >>>>>>> big enough for the English-Text it looks like nobody ever checked >>>>>>> this >>>>>>> with the german translation ("Dr\u00FCcken Sie ESC, um den >>>>>>> Vollbildmodus >>>>>>> zu beenden.") - I'll file a JIRA for it anyways. >>>>>>> >>>>>>> Still this is not my problem. What I'd like to suggest is that I >>>>>>> as a >>>>>>> developer can turn of the forced overlay. >>>>>>> >>>>>>> I could think of multiple possibilities: >>>>>>> a) through a System-Property >>>>>>> (-Djavafx.quantum.fullscreenwarning=false) >>>>>>> b) through an API on the Stage >>>>>>> >>>>>>> What do you think about a) or b) is there a chance to get something >>>>>>> like >>>>>>> this in FX8, or is it too late already? Do you see any reason >>>>>>> turning of >>>>>>> the overlay could cause problems? >>>>>>> >>>>>>> Since the quantum sources are now available I'd be able to >>>>>>> implement a >>>>>>> desired feature using a) or b) and provide a patch. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> -- >>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>>> GmbH >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>>> 935833 >>>>>>> http://www.BestSolution.at phone ++43 512 >>>>>>> 935834 >>>>>>> >> >> >> -- >> David Hill >> Java Embedded Development >> >> "A man's feet should be planted in his country, but his eyes should >> survey the world." >> -- George Santayana (1863 - 1952) > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From alexander.matveev at oracle.com Thu Mar 7 16:14:07 2013 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 07 Mar 2013 16:14:07 -0800 Subject: [API Review]: RT-28817 - Add explicit dispose() method to MediaPlayer In-Reply-To: <8DA2F1B7-7383-4901-AAFE-F4F5E0D15E4D@oracle.com> References: <5137CC24.4050905@oracle.com> <8DA2F1B7-7383-4901-AAFE-F4F5E0D15E4D@oracle.com> Message-ID: <51392D4F.1020608@oracle.com> Hi Richard, To let developers know that MediaPlayer is disposed, I will suggest to add new status to MediaPlayer called DISPOSED. http://docs.oracle.com/javafx/2/api/javafx/scene/media/MediaPlayer.Status.html Transition to this state will be allowed from any other states that we have. I will NOT add to MediaPlayer runnable onDisposed similar to onReady or onPlaying, since disposed in synchronous. Also, keeping MediaPlayer in any other valid status after disposed will be confusing for developers. We have HALTED status that similar to DISPOSED, except DISPOSED is triggered by user. All behavior in DISPOSED status will be same or similar as in HALTED status, since in both cases MediaPlayer is unusable. Thanks, Alexander > Hi Alexander, > > Sounds good. For reference, Skin also has a method called 'dispose' so I think we have the right name here. Note: > > http://docs.oracle.com/javafx/2/api/javafx/scene/control/Skin.html > > Be sure to spec in the JavaDoc for MediaPlayer & MediaView what it means when a MediaPlayer has been disposed. For example, if I dispose a MediaPlayer and then set it on a MediaView, what happens? I would suggest that nothing bad should happen (along the lines of Skin). However maybe we want to have an isDisposed method on MediaPlayer so developers can inspect a media player and know whether they should create a new one (in which case having a read only disposedProperty is also a good idea). All methods on the MediaPlayer need to specify their behavior when invoked on a disposed MediaPlayer. > > I think you're on the right path that dispose() can be called no matter what state the media player is in. Be sure to specify what state the player will be in after dispose is called. Also we need to have tests that ensure that the state transitions work correctly. > > Thanks! > Richard > > On Mar 6, 2013, at 3:07 PM, Alexander Matveev wrote: > >> Hi all, >> >> Explicit dispose() method is needed to free native resources used by MediaPlayer. Garbage collector is not reliable enough to free native resources fast enough, thus when MediaPlayers are created fast enough we may run out of native memory. Normally, user does not need to call dispose() method on MediaPlayer if application does not create them often. After dispose() is called MediaPlayer cannot be used again and should be disregarded. Media and MediaView associated with disposed MediaPlayer can be reused. Dispose() will be valid in any states. For example, when player is playing call to dispose() will stop playback and release all resources. >> >> JIRA: >> http://javafx-jira.kenai.com/browse/RT-28817 >> >> Thanks, >> Alexander From richard.bair at oracle.com Thu Mar 7 16:08:44 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Mar 2013 16:08:44 -0800 Subject: [API Review]: RT-28817 - Add explicit dispose() method to MediaPlayer In-Reply-To: <51392D4F.1020608@oracle.com> References: <5137CC24.4050905@oracle.com> <8DA2F1B7-7383-4901-AAFE-F4F5E0D15E4D@oracle.com> <51392D4F.1020608@oracle.com> Message-ID: <748ED6E2-B062-42DB-8C73-4FA6AFC12E4C@oracle.com> That seems good. So DISPOSED is only ever reached if the developer explicitly calls dispose (that is, it has nothing to do with whether the native resources have been released, but rather, whether the dispose() method was called). I like that. Richard On Mar 7, 2013, at 4:14 PM, Alexander Matveev wrote: > Hi Richard, > > To let developers know that MediaPlayer is disposed, I will suggest to add new status to MediaPlayer called DISPOSED. > http://docs.oracle.com/javafx/2/api/javafx/scene/media/MediaPlayer.Status.html > Transition to this state will be allowed from any other states that we have. I will NOT add to MediaPlayer runnable onDisposed similar to onReady or onPlaying, since disposed in synchronous. Also, keeping MediaPlayer in any other valid status after disposed will be confusing for developers. > > We have HALTED status that similar to DISPOSED, except DISPOSED is triggered by user. All behavior in DISPOSED status will be same or similar as in HALTED status, since in both cases MediaPlayer is unusable. > > Thanks, > Alexander > >> Hi Alexander, >> >> Sounds good. For reference, Skin also has a method called 'dispose' so I think we have the right name here. Note: >> >> http://docs.oracle.com/javafx/2/api/javafx/scene/control/Skin.html >> >> Be sure to spec in the JavaDoc for MediaPlayer & MediaView what it means when a MediaPlayer has been disposed. For example, if I dispose a MediaPlayer and then set it on a MediaView, what happens? I would suggest that nothing bad should happen (along the lines of Skin). However maybe we want to have an isDisposed method on MediaPlayer so developers can inspect a media player and know whether they should create a new one (in which case having a read only disposedProperty is also a good idea). All methods on the MediaPlayer need to specify their behavior when invoked on a disposed MediaPlayer. >> >> I think you're on the right path that dispose() can be called no matter what state the media player is in. Be sure to specify what state the player will be in after dispose is called. Also we need to have tests that ensure that the state transitions work correctly. >> >> Thanks! >> Richard >> >> On Mar 6, 2013, at 3:07 PM, Alexander Matveev wrote: >> >>> Hi all, >>> >>> Explicit dispose() method is needed to free native resources used by MediaPlayer. Garbage collector is not reliable enough to free native resources fast enough, thus when MediaPlayers are created fast enough we may run out of native memory. Normally, user does not need to call dispose() method on MediaPlayer if application does not create them often. After dispose() is called MediaPlayer cannot be used again and should be disregarded. Media and MediaView associated with disposed MediaPlayer can be reused. Dispose() will be valid in any states. For example, when player is playing call to dispose() will stop playback and release all resources. >>> >>> JIRA: >>> http://javafx-jira.kenai.com/browse/RT-28817 >>> >>> Thanks, >>> Alexander > From hang.vo at oracle.com Thu Mar 7 16:09:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 00:09:57 +0000 Subject: hg: openjfx/8/master/rt: 106 new changesets Message-ID: <20130308001600.53EE247E67@hg.openjdk.java.net> Changeset: 08e1479a4c90 Author: "Jasper Potts" Date: 2013-02-26 14:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/08e1479a4c90 Ensemble 8: Fixed search index creation ! apps/samples/Ensemble8/build.xml ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/EnsembleCompiletimeMain.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/BuildEnsembleSearchIndex.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/DocumentationIndexer.java + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fdt + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fdx + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fnm + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.frq + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.nrm + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.prx + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.tii + apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.tis - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdt - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fnm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.frq - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.nrm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.prx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tii - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tis ! apps/samples/Ensemble8/src/generated/ensemble/search/index/listAll.txt ! apps/samples/Ensemble8/src/generated/ensemble/search/index/segments.gen + apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_1 - apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_g Changeset: c573cfbca3d0 Author: rbair Date: 2013-02-26 17:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c573cfbca3d0 Updated Gradle build files ! build.gradle ! generator.gradle ! settings.gradle Changeset: 1ead718a729c Author: Petr Pchelko Date: 2013-02-27 14:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1ead718a729c 28219: Mac: ClassCastException in HelloHTMLEditor Reviewed-by: anthony, anthony ! glass/glass/src/com/sun/glass/ui/mac/MacSystemClipboard.java Changeset: c3b977f54869 Author: Alexander Zvegintsev Date: 2013-02-27 16:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c3b977f54869 RT-28448 Gtk: DnD event.getDragboard().getString() produces crash if dragboard does not contain string ! glass/glass-lib-gtk/src/glass_dnd.cpp ! glass/glass-lib-gtk/src/glass_general.cpp Changeset: 2c1e352e1eed Author: Martin Sladecek Date: 2013-02-27 14:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2c1e352e1eed RT-19020, RT-25996 conversion methods for Properties, ReadOnlyProperties and Expressions. ! javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java ! javafx-beans/src/javafx/beans/binding/BooleanExpression.java ! javafx-beans/src/javafx/beans/binding/DoubleExpression.java ! javafx-beans/src/javafx/beans/binding/FloatExpression.java ! javafx-beans/src/javafx/beans/binding/IntegerExpression.java ! javafx-beans/src/javafx/beans/binding/LongExpression.java ! javafx-beans/src/javafx/beans/property/BooleanProperty.java ! javafx-beans/src/javafx/beans/property/DoubleProperty.java ! javafx-beans/src/javafx/beans/property/FloatProperty.java ! javafx-beans/src/javafx/beans/property/IntegerProperty.java ! javafx-beans/src/javafx/beans/property/LongProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyBooleanProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyDoubleProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyFloatProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyIntegerProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyListProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyLongProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyMapProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyObjectProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlySetProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyStringProperty.java ! javafx-beans/test/javafx/beans/property/BooleanPropertyTest.java ! javafx-beans/test/javafx/beans/property/DoublePropertyTest.java ! javafx-beans/test/javafx/beans/property/FloatPropertyTest.java ! javafx-beans/test/javafx/beans/property/IntegerPropertyTest.java ! javafx-beans/test/javafx/beans/property/LongPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyTest.java ! javafx-beans/test/javafx/binding/expression/BooleanExpressionTest.java ! javafx-beans/test/javafx/binding/expression/DoubleExpressionTest.java ! javafx-beans/test/javafx/binding/expression/FloatExpressionTest.java ! javafx-beans/test/javafx/binding/expression/IntegerExpressionTest.java ! javafx-beans/test/javafx/binding/expression/LongExpressionTest.java Changeset: 60b4700fe623 Author: Martin Sladecek Date: 2013-02-27 14:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/60b4700fe623 merge Changeset: 09a4a2baf5df Author: Martin Sladecek Date: 2013-02-27 15:21 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/09a4a2baf5df [TEST] RT-25012 Switch to typed getChangeListeners() methods in ExpressionHelperUtility ! javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtility.java Changeset: 00b9dfdd1e33 Author: Martin Sladecek Date: 2013-02-27 15:21 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/00b9dfdd1e33 merge Changeset: 1d3c0d307859 Author: rbair Date: 2013-02-27 10:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1d3c0d307859 RT-28690: Remove jfxCssLexer.g and jfxCssParser.g ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java ! javafx-ui-common/src/com/sun/javafx/css/converters/PaintConverter.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 3c85e69bc056 Author: rbair Date: 2013-02-27 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3c85e69bc056 RT-28690: Remove jfxCssLexer.g and jfxCssParser.g Summary: Removed references to these from gradle generator script ! generator.gradle Changeset: 3d1e8caa50f2 Author: "Jasper Potts" Date: 2013-02-27 10:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3d1e8caa50f2 Fixed RT-28628: Ensemble 8 is all messed up on Retina. Which was because Region could not handle @2x images. ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java Changeset: 9bfc15277dcb Author: snorthov Date: 2013-02-27 15:47 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9bfc15277dcb fix .classpath to include Ensemble8 ! .classpath Changeset: df7505a75781 Author: rbair Date: 2013-02-27 13:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/df7505a75781 Fixed javadoc so as not to have trailing > but use > instead. Now builds on b78 of JDK 8. ! deploy/packager/src/com/sun/javafx/tools/ant/Application.java ! deploy/packager/src/com/sun/javafx/tools/ant/Callback.java ! deploy/packager/src/com/sun/javafx/tools/ant/Callbacks.java ! deploy/packager/src/com/sun/javafx/tools/ant/DeployFXTask.java ! deploy/packager/src/com/sun/javafx/tools/ant/FXSignJarTask.java ! deploy/packager/src/com/sun/javafx/tools/ant/FileSet.java ! deploy/packager/src/com/sun/javafx/tools/ant/Info.java ! deploy/packager/src/com/sun/javafx/tools/ant/Platform.java ! deploy/packager/src/com/sun/javafx/tools/ant/Preferences.java ! deploy/packager/src/com/sun/javafx/tools/ant/Resources.java Changeset: 559de95c61e6 Author: rbair Date: 2013-02-27 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/559de95c61e6 Updated Gradle build to build Glass on MacOSX. ! build.gradle ! generator.gradle Changeset: 26b56085a3ff Author: Felipe Heidrich Date: 2013-02-26 13:54 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26b56085a3ff RT-28215: consider removing cagsrc.float from javafx.geom ! .classpath ! javafx-geom/build-common.xml - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java ! javafx-geom/javafx-geom.iml ! javafx-geom/nbproject/project.xml + javafx-geom/src/com/sun/javafx/geom/Area.java + javafx-geom/src/com/sun/javafx/geom/AreaOp.java + javafx-geom/src/com/sun/javafx/geom/ChainEnd.java + javafx-geom/src/com/sun/javafx/geom/Crossings.java + javafx-geom/src/com/sun/javafx/geom/Curve.java + javafx-geom/src/com/sun/javafx/geom/CurveLink.java + javafx-geom/src/com/sun/javafx/geom/Edge.java + javafx-geom/src/com/sun/javafx/geom/Order0.java + javafx-geom/src/com/sun/javafx/geom/Order1.java + javafx-geom/src/com/sun/javafx/geom/Order2.java + javafx-geom/src/com/sun/javafx/geom/Order3.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: 1b9af0a9c0eb Author: rbair Date: 2013-02-27 14:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1b9af0a9c0eb Removed work item in gradle build about cagsrc.float since Felipe has just removed it. ! generator.gradle Changeset: 74087bbd8a66 Author: ddehaven Date: 2013-02-27 15:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74087bbd8a66 Do RT-27054: Finish implementing changes to JavaFX launcher implementation ! javafx-ui-common/src/com/sun/javafx/application/LauncherImpl.java Changeset: 3cb91bf37590 Author: rbair Date: 2013-02-27 16:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3cb91bf37590 More updates to the Gradle scripts. Now copying & building FXML. Also moving over some of the apps and the deploy code (though neither is being built yet). ! build.gradle ! generator.gradle Changeset: da85b16b48d5 Author: rbair Date: 2013-02-27 17:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/da85b16b48d5 Fixed trailing , on a couple lines ! generator.gradle Changeset: d3a31551b59d Author: "Jasper Potts" Date: 2013-02-27 18:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d3a31551b59d Fixed RT-28628: Ensemble 8 is all messed up on Retina. Couple little clean ups of fix code. ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java Changeset: e422efa819f2 Author: rbair Date: 2013-02-27 22:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e422efa819f2 Numerous Gradle build fixes. Improved rules for which files are copied to src/main/java vs. src/main/resources. Implemented the construction of artifacts. Verified that all the right files are there, and none of the wrong ones (although there are some questionable empty directories). Oh, and the manifest isn't right yet. Otherwise looking pretty good. ! build.gradle ! generator.gradle Changeset: e0e6f8c374ef Author: Rafi Tayar Date: 2013-02-28 14:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e0e6f8c374ef Work on RT-24542: EGLFB: Some touch screens report implausibly frequent taps; we need to filter out the noise in these events ! glass/glass-lib-lens/src/input/udev/udevInput.c ! glass/glass-lib-lens/src/wm/LensWindowManager.c ! glass/glass/src/com/sun/glass/ui/lens/LensApplication.java ! glass/glass/src/com/sun/glass/ui/lens/LensTouchInputSupport.java Changeset: 75ec6f520c51 Author: Rafi Tayar Date: 2013-02-28 14:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/75ec6f520c51 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: b0ed493aa5ee Author: Alexander Zvegintsev Date: 2013-02-28 18:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b0ed493aa5ee RT-28561 Gtk: DnD dragboard content is unavailable in source.setOnDragDone ! glass/glass-lib-gtk/src/GlassDnDClipboard.cpp ! glass/glass-lib-gtk/src/glass_dnd.cpp Changeset: bb428b8c662a Author: David Hill Date: 2013-02-28 10:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bb428b8c662a Netbeans project for glass. + glass/glass/nbproject/project.xml Changeset: 6d472d534474 Author: David Hill Date: 2013-02-28 10:51 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6d472d534474 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: 66efb08464ce Author: snorthov Date: 2013-02-28 12:52 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/66efb08464ce RT-27455: EGLFB: Opening a new window during VKB opened cause a NullPointerException ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassScene.java Changeset: b2a7e34e6f71 Author: Felipe Heidrich Date: 2013-02-28 10:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b2a7e34e6f71 RT-28707: Need to revert unintended change in RT-28215 to LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: 9a5af53aed5a Author: snorthov Date: 2013-02-28 14:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9a5af53aed5a RT-19342: SceneBuilder is out of sync with the native OS window size while resizing. ! glass/glass-lib-macosx/src/GlassView.m ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PaintCollector.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PresentingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/UploadingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/WindowStage.java Changeset: 687141cbfbba Author: snorthov Date: 2013-02-28 15:01 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/687141cbfbba RT-19342: SceneBuilder is out of sync with the native OS window size while resizing. [added -Djavafx.live.resize] ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 32cfc88cd5d3 Author: snorthov Date: 2013-02-28 15:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/32cfc88cd5d3 PlaygroundTabs - fix Eclipse compiler cast error ! apps/samples/Ensemble8/src/app/ensemble/samplepage/PlaygroundTabs.java Changeset: 9ecd8e3de269 Author: akouznet at AKOUZNET-LENOVO Date: 2013-02-28 12:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9ecd8e3de269 Ensemble3: Fix for RT-26854 Fix search focus issue ! apps/samples/Ensemble8/src/app/ensemble/SearchPopover.java ! apps/samples/Ensemble8/src/app/ensemble/SearchResultPopoverList.java ! apps/samples/Ensemble8/src/app/ensemble/control/Popover.java Changeset: a5389e8f1b35 Author: Alexander Kouznetsov Date: 2013-02-28 13:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a5389e8f1b35 Ensemble3: Code cleanup. ! apps/samples/Ensemble8/src/app/ensemble/EnsembleApp.java Changeset: 1276629eadb7 Author: dmasada Date: 2013-02-28 13:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1276629eadb7 Ensemble8: fix title ! apps/samples/Ensemble8/src/app/ensemble/EnsembleApp.java Changeset: ecca0fbeebad Author: Alexander Kouznetsov Date: 2013-02-28 15:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ecca0fbeebad Ensemble3: Fixed popover background ! apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesCommon.css Changeset: e2a407dbcfa3 Author: kcr Date: 2013-02-28 16:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e2a407dbcfa3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdt - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fdx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.fnm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.frq - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.nrm - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.prx - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tii - apps/samples/Ensemble8/src/generated/ensemble/search/index/_f.tis - apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_g - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 534729526388 Author: Martin Sladecek Date: 2013-03-01 09:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/534729526388 RT-28198 com.sun.javafx.binding.SelectBinding$SelectBindingHelper has a dependency on javafx.beans ! javafx-beans/src/com/sun/javafx/binding/SelectBinding.java + javafx-beans/src/com/sun/javafx/property/JavaBeanAccessHelper.java ! javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanQuickAccessor.java Changeset: fe1c4d375337 Author: Martin Sladecek Date: 2013-03-01 09:58 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe1c4d375337 merge Changeset: efc566a46a12 Author: rbair Date: 2013-03-01 13:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/efc566a46a12 Fixed the classpath handling for Gradle build. I think I have it right now. The bootclasspath should be reset so that it only includes rt.jar (and specifically doesn't have jfxrt.jar). I then put jfxrt.jar on the classpath AFTER all the other project dependencies etc, so that it operates appropriately as a binary stub. Also disabled tests until I get them sorted out. ! build.gradle Changeset: 41a9ef3f44e9 Author: Thor johannesson Date: 2013-03-01 15:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/41a9ef3f44e9 Fix RT-20784: Mac: Headless environment issue. Approved by Kevin and Phil ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 520d4cf6f15f Author: snorthov Date: 2013-03-01 19:48 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/520d4cf6f15f fix live resize for SWT ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: d27aceac8d66 Author: Alexander Kouznetsov Date: 2013-03-01 17:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d27aceac8d66 Ensemble3: Fix for RT-28757 Home Page resize bad performance ! apps/samples/Ensemble8/src/app/ensemble/HomePage.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java Changeset: 787376bff0fd Author: rbair Date: 2013-03-01 17:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/787376bff0fd Failed to build on some Java 8 VM, due to long confusion. Likely bug in javac. ! javafx-logging/src/com/sun/javafx/logging/PulseLogger.java Changeset: 6faf8a3c2214 Author: rbair Date: 2013-03-01 18:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6faf8a3c2214 Lots of work on the build script -- the tests now all compile. Abstracted some hardcoded values into settable properties (such as from Hudson). Added some logging. Fixed up the bootclasspath stuff (really hoping I got it this time!). Had to switch to 1.7 source because 1.8 tickles a compiler bug when compiling the tests. ! build.gradle Changeset: 9134330dc4e0 Author: Daniel Blaukopf Date: 2013-03-03 18:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9134330dc4e0 Build GTK in cross builds as well as host builds ! glass/build-common.xml ! glass/glass-lib-gtk/build.xml Changeset: f200832fb53a Author: Milan Kubec Date: 2013-03-04 10:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f200832fb53a RT-25559: Allow event handlers to come from the namespace; better error message, tests added to the suite; minor rename; license update ! javafx-fxml/src/javafx/fxml/FXMLLoader.java - javafx-fxml/test/javafx/fxml/RT_25559.java + javafx-fxml/test/javafx/fxml/RT_25559Test.java ! javafx-fxml/test/javafx/fxml/rt_25559.fxml + javafx-fxml/test/javafx/fxml/rt_25559_err1.fxml Changeset: 3e43e2361e9a Author: Martin Sladecek Date: 2013-03-04 12:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3e43e2361e9a [TEST] new tests for ListChangeListener.Change implementations. + javafx-beans/test/com/sun/javafx/collections/MappingChangeTest.java + javafx-beans/test/com/sun/javafx/collections/NonIterableChangeTest.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java Changeset: 392abf0df66f Author: Martin Sladecek Date: 2013-03-04 12:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/392abf0df66f merge - javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.double/com/sun/javafx/geom/Order3.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Area.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/AreaOp.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/ChainEnd.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Crossings.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Curve.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/CurveLink.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Edge.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order0.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order1.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order2.java - javafx-geom/cagsrc.float/com/sun/javafx/geom/Order3.java - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssLexer.g - javafx-ui-common/src/com/sun/javafx/css/parser/jfxCssParser.g Changeset: 63c947b7d28a Author: Martin Sladecek Date: 2013-03-04 12:03 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/63c947b7d28a merge Changeset: 171ff8b064e2 Author: Milan Kubec Date: 2013-03-04 12:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/171ff8b064e2 RT-27589: JavaFXBuilderFactory has a strong dependency on webnode ! javafx-fxml/nbproject/project.xml ! javafx-fxml/src/javafx/fxml/JavaFXBuilderFactory.java - javafx-fxml/test/javafx/fxml/RT_23519.java + javafx-fxml/test/javafx/fxml/RT_23519Test.java ! javafx-fxml/test/javafx/fxml/rt_23519.fxml Changeset: 29787a06e0de Author: snorthov Date: 2013-03-04 14:04 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/29787a06e0de Ensemble8: don't crash if source file is not available ! apps/samples/Ensemble8/src/app/ensemble/util/Utils.java Changeset: b11664e10c75 Author: rbair Date: 2013-03-04 16:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b11664e10c75 Fixed up tests for Gradle build. Now all the tests run and pass. ! build.gradle ! generator.gradle Changeset: b47611118080 Author: rbair Date: 2013-03-04 17:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b47611118080 Fixed exclude login in stub toolkit tests for Gradle Build ! build.gradle Changeset: cb061795e1f7 Author: Milan Kubec Date: 2013-03-05 12:12 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cb061795e1f7 RT-28784: Accessibility of methods in FXMLLoader unintentionally changed to protected ! javafx-fxml/src/javafx/fxml/FXMLLoader.java Changeset: 4620dab2c1ac Author: dmasada Date: 2013-03-05 08:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4620dab2c1ac RT-28749 Ensemble8: add to internal build + apps/build-defs.xml + apps/build.xml ! apps/samples/Ensemble8/nbproject/project.properties + apps/samples/build.xml Changeset: 008bdab5b9fb Author: Alexander Kouznetsov Date: 2013-03-05 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/008bdab5b9fb Ensemble8: Fix for RT-28796 NPE in Ensemble8 ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java Changeset: c74b831540ef Author: Paru Somashekar Date: 2013-02-26 13:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c74b831540ef RT-23116 BarChart issue with additional category is added. ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 3955b0ebae71 Author: David Grieve Date: 2013-02-26 17:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3955b0ebae71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 405afceac406 Author: Paru Somashekar Date: 2013-02-26 16:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/405afceac406 RT-23141 : MenuBar focused state is not displayed ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java Changeset: a3e606ef6ead Author: jgiles Date: 2013-02-27 14:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a3e606ef6ead RT-28659: Replace ComboBox.emptyText with ListView.placeholder and ComboBox.placeholder API ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: fde1462f251b Author: jgiles Date: 2013-02-27 15:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fde1462f251b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: beb98f6c0fb0 Author: jgiles Date: 2013-02-27 15:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/beb98f6c0fb0 Backing out a part of the RT-24916 changeset, in particular the addition of ScrollPane.scrollTo(Node) as we are not ready to commit to public API yet. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java Changeset: fbd0b103d3a4 Author: Paru Somashekar Date: 2013-02-26 19:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fbd0b103d3a4 fixed broken BarChart unit test ! javafx-ui-charts/test/javafx/scene/chart/BarChartTest.java Changeset: 4b27cc4bf069 Author: Felipe Heidrich Date: 2013-02-27 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4b27cc4bf069 RT-27762: Text not centered vertically in bounds for windows default 12px ! javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextBoundsType.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java Changeset: eae1d1d854f8 Author: jgiles Date: 2013-02-28 11:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eae1d1d854f8 Back out a performance optimisation in TreeCell due to a functional regression where a cell index could be unchanged yet the TreeItem it was representing has changed. This has already been done for TreeTableView. ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: ccc6cd50dfd2 Author: jgiles Date: 2013-02-28 11:01 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ccc6cd50dfd2 Backout small portion of RT-24725 as it does not seem necessary and it led to performance regressions in certain situations. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: f77e1803a0ee Author: jgiles Date: 2013-02-28 14:35 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f77e1803a0ee RT-28556: [TreeView] Alignment after sorting is incorrect. ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java + javafx-ui-controls/test/com/sun/javafx/scene/control/test/Employee.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: f2f7919df9c2 Author: jgiles Date: 2013-03-01 09:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f2f7919df9c2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: f4084b9ecd79 Author: David Grieve Date: 2013-02-28 15:54 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f4084b9ecd79 RT-28660: use arrays to hold cache entries for faster access ! javafx-ui-common/src/com/sun/javafx/css/BitSet.java ! javafx-ui-common/src/com/sun/javafx/css/StyleCache.java ! javafx-ui-common/src/com/sun/javafx/css/StyleCacheEntry.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: 927188e77e2c Author: Daniel Blaukopf Date: 2013-03-01 03:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/927188e77e2c Touch stylesheet for Modena, copied from Caspian ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/touch.css Changeset: 7a6a30b004c8 Author: David Grieve Date: 2013-03-01 11:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a6a30b004c8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 39bb41c52de5 Author: "Jasper Potts" Date: 2013-03-01 10:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/39bb41c52de5 Modena app, changed to Java project from FX project. Moved fonts to menu rather than button. ! apps/experiments/Modena/build.xml ! apps/experiments/Modena/nbproject/build-impl.xml - apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties - apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties ! apps/experiments/Modena/nbproject/genfiles.properties - apps/experiments/Modena/nbproject/jfx-impl.xml - apps/experiments/Modena/nbproject/jfx-impl_backup.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_2.xml ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/nbproject/project.xml ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java Changeset: 1908325045af Author: "Jasper Potts" Date: 2013-03-01 11:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1908325045af Fixed RT-28223: Fix controls heights to be consistent. reviewed by Jonathan and Rich. This includeds fixes to controls to utilize new API from RT-27762 also fixes for padding snapping to pixel in consitant way. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabelSkinTest.java Changeset: fe536d52fcd7 Author: "Jasper Potts" Date: 2013-03-01 12:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe536d52fcd7 Modena test app, fixed project. Updated alignment page to move lines to match font size. ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SameHeightTest.fxml + apps/experiments/Modena/src/modena/SameHeightTest.fxml.bak + apps/experiments/Modena/src/modena/SameHeightTestController.java ! apps/experiments/Modena/src/modena/SamplePage.java Changeset: c33368d498fd Author: "Jasper Potts" Date: 2013-03-01 17:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c33368d498fd Added Modena to intellij project + apps/experiments/Modena/Modena.iml Changeset: 43c640c06b87 Author: "Jasper Potts" Date: 2013-03-01 17:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/43c640c06b87 Modena test app, enlarged vertical tab examples so can see more than one tab ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java Changeset: 3ffac5400582 Author: "Jasper Potts" Date: 2013-03-01 18:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3ffac5400582 Fixed RT-28758: REGRESSION: ComboBoxes are much wider by default ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 8ee27ba99e2a Author: "Jasper Potts" Date: 2013-03-01 18:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8ee27ba99e2a Modena CSS cleanup of file. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 7f9c1f256882 Author: Paru Somashekar Date: 2013-03-02 23:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7f9c1f256882 RT-28367 Clean up AccessibleList, AccessibleListItem; RT-28419 Slider knob rendered outside RT-26025 ChoiceBox right click opens both popup and context menu. ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleList.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleListItem.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: 7a0dc6ed9c7b Author: Paru Somashekar Date: 2013-03-03 01:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a0dc6ed9c7b RT-26025, removed debug output left behind by accident. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java Changeset: 0eb24b573aec Author: David Grieve Date: 2013-03-04 16:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0eb24b573aec RT-28768: when looking up parent cache entry for inherited font, if parent cache entry's font is null, find the font to use. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: f4857dbc5287 Author: David Grieve Date: 2013-03-04 16:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f4857dbc5287 RT-28769: check for null styleHelper in impl_getStyleMap and impl_setStyleMap ! javafx-ui-common/src/javafx/scene/Node.java Changeset: c99b1563212f Author: "Jasper Potts" Date: 2013-03-04 11:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c99b1563212f Modena test app, added pill buttons same text example ! apps/experiments/Modena/src/modena/SamplePage.java Changeset: 6d47b9a930db Author: "Jasper Potts" Date: 2013-03-04 11:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6d47b9a930db Modena UI tweeks ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: f4c5ee1d15b1 Author: "Jasper Potts" Date: 2013-03-04 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f4c5ee1d15b1 Modena make chart legened more subtle. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 044e79cda8fe Author: "Jasper Potts" Date: 2013-03-04 14:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/044e79cda8fe MERGE AFTER : Modena make chart legened more subtle. Changeset: 13c375a722d0 Author: David Grieve Date: 2013-03-04 17:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/13c375a722d0 RT-28760: list of ua stylesheets might contain nulls ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 6240fcb97940 Author: David Grieve Date: 2013-03-04 17:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6240fcb97940 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: fd3743c5c84d Author: "Jasper Potts" Date: 2013-03-04 15:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fd3743c5c84d Modena chart gridlines making dashed in both H and V as feels better ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 649ecc9fc736 Author: "Jasper Potts" Date: 2013-03-04 15:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/649ecc9fc736 Merge Changeset: 0973fa2d0c6f Author: "Jasper Potts" Date: 2013-03-04 17:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0973fa2d0c6f Modena: fix toolbars anding support for right and bottom styleclasses for special cases. Added spacing for overflow arrow when vertical. Modena app added test cases for RIGHT and BOTTOM toolbars. Modena App added refresh support for stylesheet when running from IntelliJ ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 959641c9fede Author: jgiles Date: 2013-03-01 09:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/959641c9fede RT-28668: Ensemble tree arrow disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 19a14723a52d Author: jgiles Date: 2013-03-02 19:11 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/19a14723a52d RT-22463: It should be possible to clear a TableView items list, and subsequently set a new items list in a TableView where the contents are considered equal (that is, equals() returns true), with the expectation that the new text is displayed rather than the old text (by the fact that the old items were first cleared out - if they weren't then we would still likely see the old items). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: 8a3b4ebaa2be Author: jgiles Date: 2013-03-02 19:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8a3b4ebaa2be Slight update for RT-28668: Ensemble tree arrow disappears (plays nicer with the CSS engine now). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: c3376fd7fd9a Author: jgiles Date: 2013-03-05 11:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c3376fd7fd9a Finishing off unit tests for RT-22463 for ListView, TreeView, TableView and TreeTableView ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java + javafx-ui-controls/test/com/sun/javafx/scene/control/test/RT_22463_Person.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: f77115aa3398 Author: jgiles Date: 2013-03-05 11:19 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f77115aa3398 Added (currently @Ignore'd) unit tests for RT-28637: [ListView, TreeView, TableView, TreeTableView] selectionModel selectedItem returns wrong item. ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: d50ad13e2f3c Author: jgiles Date: 2013-03-05 19:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d50ad13e2f3c Adding (currently @Ignore'd) unit tests for RT-28615: ListChangeListener on MultipleSelectionModel selectedItems does not always report correct item added. ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java Changeset: ece1fe2f059b Author: jgiles Date: 2013-03-05 19:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ece1fe2f059b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: ab59ba026313 Author: Paru Somashekar Date: 2013-03-05 06:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ab59ba026313 RT-28773 : BarChart empty space on axis ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 3e08d75e32a1 Author: mickf Date: 2013-03-05 19:05 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3e08d75e32a1 RT-28052 : optimise converters ! javafx-ui-common/src/com/sun/javafx/css/ParsedValueImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/converters/EnumConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/RepeatStructConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java Changeset: 9170500c6400 Author: David Grieve Date: 2013-03-05 17:32 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9170500c6400 RT-28022: fix url resolution for @font-face ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: f4bbc8b8b78c Author: David Grieve Date: 2013-03-05 17:32 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f4bbc8b8b78c RT-28769: follow on fixes after feedback from scene builder folks. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: ed8f9c83d575 Author: Paru Somashekar Date: 2013-03-06 06:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ed8f9c83d575 RT-26633 ColorPicker setValue partially reflects changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 26b012b132f9 Author: David Grieve Date: 2013-03-06 11:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26b012b132f9 RT-20906: add -fx-[min|pref|max]-[width|height] css properties to Region. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 637a0d67106f Author: David Grieve Date: 2013-03-06 11:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/637a0d67106f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties - apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties - apps/experiments/Modena/nbproject/jfx-impl.xml - apps/experiments/Modena/nbproject/jfx-impl_backup.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml - apps/experiments/Modena/nbproject/jfx-impl_backup_2.xml Changeset: 3bf53096ec0a Author: hudson Date: 2013-03-07 14:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3bf53096ec0a Added tag 8.0-b80 for changeset 637a0d67106f ! .hgtags From alexander.matveev at oracle.com Thu Mar 7 16:38:39 2013 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 07 Mar 2013 16:38:39 -0800 Subject: [API Review]: RT-28817 - Add explicit dispose() method to MediaPlayer In-Reply-To: <748ED6E2-B062-42DB-8C73-4FA6AFC12E4C@oracle.com> References: <5137CC24.4050905@oracle.com> <8DA2F1B7-7383-4901-AAFE-F4F5E0D15E4D@oracle.com> <51392D4F.1020608@oracle.com> <748ED6E2-B062-42DB-8C73-4FA6AFC12E4C@oracle.com> Message-ID: <5139330F.9030209@oracle.com> Hi Richard, Yes, DISPOSED is only ever reached if dispose() is called and DISPOSED status will be set before dispose() returns. Thanks, Alexander > That seems good. So DISPOSED is only ever reached if the developer explicitly calls dispose (that is, it has nothing to do with whether the native resources have been released, but rather, whether the dispose() method was called). > > I like that. > > Richard > > On Mar 7, 2013, at 4:14 PM, Alexander Matveev wrote: > >> Hi Richard, >> >> To let developers know that MediaPlayer is disposed, I will suggest to add new status to MediaPlayer called DISPOSED. >> http://docs.oracle.com/javafx/2/api/javafx/scene/media/MediaPlayer.Status.html >> Transition to this state will be allowed from any other states that we have. I will NOT add to MediaPlayer runnable onDisposed similar to onReady or onPlaying, since disposed in synchronous. Also, keeping MediaPlayer in any other valid status after disposed will be confusing for developers. >> >> We have HALTED status that similar to DISPOSED, except DISPOSED is triggered by user. All behavior in DISPOSED status will be same or similar as in HALTED status, since in both cases MediaPlayer is unusable. >> >> Thanks, >> Alexander >> >>> Hi Alexander, >>> >>> Sounds good. For reference, Skin also has a method called 'dispose' so I think we have the right name here. Note: >>> >>> http://docs.oracle.com/javafx/2/api/javafx/scene/control/Skin.html >>> >>> Be sure to spec in the JavaDoc for MediaPlayer & MediaView what it means when a MediaPlayer has been disposed. For example, if I dispose a MediaPlayer and then set it on a MediaView, what happens? I would suggest that nothing bad should happen (along the lines of Skin). However maybe we want to have an isDisposed method on MediaPlayer so developers can inspect a media player and know whether they should create a new one (in which case having a read only disposedProperty is also a good idea). All methods on the MediaPlayer need to specify their behavior when invoked on a disposed MediaPlayer. >>> >>> I think you're on the right path that dispose() can be called no matter what state the media player is in. Be sure to specify what state the player will be in after dispose is called. Also we need to have tests that ensure that the state transitions work correctly. >>> >>> Thanks! >>> Richard >>> >>> On Mar 6, 2013, at 3:07 PM, Alexander Matveev wrote: >>> >>>> Hi all, >>>> >>>> Explicit dispose() method is needed to free native resources used by MediaPlayer. Garbage collector is not reliable enough to free native resources fast enough, thus when MediaPlayers are created fast enough we may run out of native memory. Normally, user does not need to call dispose() method on MediaPlayer if application does not create them often. After dispose() is called MediaPlayer cannot be used again and should be disregarded. Media and MediaView associated with disposed MediaPlayer can be reused. Dispose() will be valid in any states. For example, when player is playing call to dispose() will stop playback and release all resources. >>>> >>>> JIRA: >>>> http://javafx-jira.kenai.com/browse/RT-28817 >>>> >>>> Thanks, >>>> Alexander From hang.vo at oracle.com Thu Mar 7 17:18:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 01:18:16 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130308011833.7677147E6A@hg.openjdk.java.net> Changeset: d79881867641 Author: "Jasper Potts" Date: 2013-03-07 17:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d79881867641 Fixed RT-28870:ProgressIndicator ignores padding and has no way to scale done tick mark ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 627e2260bc52 Author: Paru Somashekar Date: 2013-03-07 17:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/627e2260bc52 RT-13672 CategoryAxis diff animated property for diff constructors ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 53284fc129a4 Author: Paru Somashekar Date: 2013-03-07 17:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/53284fc129a4 RT-20110 StackedBarChart - stack does not move down on remove data ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java From hang.vo at oracle.com Thu Mar 7 17:48:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 01:48:02 +0000 Subject: hg: openjfx/8/controls/rt: Modena CSS, progress indicator indeterminate the SVG paths were too complex. Message-ID: <20130308014805.A700F47E70@hg.openjdk.java.net> Changeset: a671a5f72fe9 Author: "Jasper Potts" Date: 2013-03-07 17:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a671a5f72fe9 Modena CSS, progress indicator indeterminate the SVG paths were too complex. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Thu Mar 7 18:48:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 02:48:11 +0000 Subject: hg: openjfx/8/controls/rt: Fixed Modena Pagination to scale with ems. Also made pagination buttons smaller Message-ID: <20130308024820.D984747E7A@hg.openjdk.java.net> Changeset: 67fbda7cbc0a Author: "Jasper Potts" Date: 2013-03-07 18:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/67fbda7cbc0a Fixed Modena Pagination to scale with ems. Also made pagination buttons smaller ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Thu Mar 7 19:04:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 03:04:01 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130308030410.6AD0447E7D@hg.openjdk.java.net> Changeset: 65ab9f40d9ca Author: jgiles Date: 2013-03-08 15:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/65ab9f40d9ca Improved sorting APIs for TableView and TreeTableView, including: RT-17550: onSort event for TableColumn RT-19482: TableView: make sort() (or similar) methods public Also includes a number of new unit tests for the new API. ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java + javafx-ui-controls/src/javafx/scene/control/SortEvent.java ! javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java Changeset: 91f71d5a4918 Author: jgiles Date: 2013-03-08 15:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/91f71d5a4918 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Thu Mar 7 20:03:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 04:03:36 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130308040347.2125647E80@hg.openjdk.java.net> Changeset: 3f60345c322a Author: David Grieve Date: 2013-03-07 22:47 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3f60345c322a RT-28635: if no style in current state, but there was a style in previous state, revert to initial value ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 3bf53096ec0a Author: hudson Date: 2013-03-07 14:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3bf53096ec0a Added tag 8.0-b80 for changeset 637a0d67106f ! .hgtags Changeset: 81f83507079b Author: David Grieve Date: 2013-03-07 22:53 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/81f83507079b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Thu Mar 7 20:03:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 04:03:55 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130308040405.3EA7747E83@hg.openjdk.java.net> Changeset: 3465e08c8a3a Author: rbair Date: 2013-03-07 19:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3465e08c8a3a Added ability to designate the build dir instead of inferring it, so that I could make this work with Gradle ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java Changeset: 86c6c588c7a7 Author: rbair Date: 2013-03-07 19:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/86c6c588c7a7 Upated Gradle build & generation scripts ! build.gradle ! generator.gradle From hang.vo at oracle.com Thu Mar 7 20:47:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 04:47:46 +0000 Subject: hg: openjfx/8/graphics/rt: Last change to this test broke it for normal ant builds -- fixed it up. Message-ID: <20130308044752.9967B47EB8@hg.openjdk.java.net> Changeset: a359928812d1 Author: rbair Date: 2013-03-07 20:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a359928812d1 Last change to this test broke it for normal ant builds -- fixed it up. ! build.gradle ! generator.gradle ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java From hang.vo at oracle.com Thu Mar 7 22:03:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 06:03:10 +0000 Subject: hg: openjfx/8/graphics/rt: The test target was wrong, attempting to test projects that either didn't exist, or that didn't have any tests! It wouldn't even run. Message-ID: <20130308060315.4358047EED@hg.openjdk.java.net> Changeset: ccb70bfec745 Author: rbair Date: 2013-03-07 21:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ccb70bfec745 The test target was wrong, attempting to test projects that either didn't exist, or that didn't have any tests! It wouldn't even run. ! build.xml From lehmann at media-interactive.de Fri Mar 8 02:06:09 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 8 Mar 2013 11:06:09 +0100 Subject: Make Fullscreen Warning overlay none-mandatory In-Reply-To: <5138C91F.1060702@Oracle.com> References: <51386AE1.6030409@bestsolution.at> <078E1539-A352-466E-9290-50CD5098C884@gmail.com> <5138A357.7010308@oracle.com> <5138AACB.5020200@bestsolution.at> <5138AE7B.90902@Oracle.com> <5138C91F.1060702@Oracle.com> Message-ID: <5139B811.9030609@media-interactive.de> I vote for setEnableFullScreenWarning(). I know we already have Node.disable but I always found this to be odd - especially with (read only) Node.disabled right beside it. If you are used to X.setEnabled(false) it easy to fall into the Node.setDisabled(true) trap... Werner On 07.03.2013 18:06, David Hill wrote: > What should we use for a name though ? Nothing I have thought of so far is very pleasant. > Stage.setDisableFullScreenWarning() (ick) > Kevin suggested to me: > Stage.setEnableFullScreenWarning(boolean) with a default of true. From sven.reimers at gmail.com Fri Mar 8 04:12:40 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 8 Mar 2013 13:12:40 +0100 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart Message-ID: Hi all AreaChart and StackedAreaChart are missing an API to simply disable the creation of symbols. At the moment this is only possible by complex css style acrobatics. LineChart on the other hand already provides a simple way to do this. The proposed tweak takes the existing API from LineChart and adds this to AreaChart and StackedAreaChart. Desired API change: /** * Indicates whether symbols for data points will be created or not. * * @return true if symbols for data points will be created and false otherwise. */ public final boolean getCreateSymbols() { return createSymbols.getValue(); } public final void setCreateSymbols(boolean value) { createSymbols.setValue(value); } public final BooleanProperty createSymbolsProperty() { return createSymbols; } Desired additional CSS property (incldues additional StyleableProperty): -fx-create-symbols JIRA: http://javafx-jira.kenai.com/browse/RT-28148 Thank -Sven P.S. An updated patch will hopefully be available there too. -- 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 * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * 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 Fri Mar 8 07:47:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 15:47:47 +0000 Subject: hg: openjfx/8/controls/rt: RT-19089: reset property to initial value if no style and current value was set by css Message-ID: <20130308154757.0801C4800A@hg.openjdk.java.net> Changeset: 811c33cc3302 Author: David Grieve Date: 2013-03-08 10:44 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/811c33cc3302 RT-19089: reset property to initial value if no style and current value was set by css ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java From parvathi.somashekar at oracle.com Fri Mar 8 10:08:09 2013 From: parvathi.somashekar at oracle.com (Paru Somashekar) Date: Fri, 08 Mar 2013 10:08:09 -0800 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: References: Message-ID: <513A2909.9070204@oracle.com> There is a request for adding the createSymbols flag at the XYChart's Series level instead of on Chart. JIRA : http://javafx-jira.kenai.com/browse/RT-21539 I think it might be a good idea to add it at the Series level so that one can turn ON / OFF symbols per Series rather than for all the series of a chart. The API could continue to be the same - except live at the Series level. Each chart can then create symbols for each of its Series only if this flag is turned on. This might however not make much sense for Scatter, Bubble and BarCharts. What do you think Jasper? -Paru. On 3/8/13 4:12 AM, Sven Reimers wrote: > Hi all > > AreaChart and StackedAreaChart are missing an API to simply disable the > creation of symbols. At the moment this is only possible by complex css > style acrobatics. LineChart on the other hand already provides a simple way > to do this. The proposed tweak takes the existing API from LineChart and > adds this to AreaChart and StackedAreaChart. > > Desired API change: > > /** > * Indicates whether symbols for data points will be created or not. > * > * @return true if symbols for data points will be created and false > otherwise. > */ > public final boolean getCreateSymbols() { return > createSymbols.getValue(); } > public final void setCreateSymbols(boolean value) { > createSymbols.setValue(value); } > public final BooleanProperty createSymbolsProperty() { return > createSymbols; } > > Desired additional CSS property (incldues additional StyleableProperty): > > -fx-create-symbols > > > JIRA: > http://javafx-jira.kenai.com/browse/RT-28148 > > Thank > > -Sven > > P.S. An updated patch will hopefully be available there too. > From richard.bair at oracle.com Fri Mar 8 12:02:05 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 8 Mar 2013 12:02:05 -0800 Subject: Anybody looking for a quick patch to contribute? Message-ID: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> I just filed http://javafx-jira.kenai.com/browse/RT-28886 which is a pretty straightforward fix, and for anybody looking to get their feet wet in making a contribution it should be a pretty good one to ease into the process :-) Richard From hang.vo at oracle.com Fri Mar 8 12:18:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 20:18:06 +0000 Subject: hg: openjfx/8/controls/rt: RT-24516: simple cache for Images loaded from stylesheets. Message-ID: <20130308201821.B1A8B48017@hg.openjdk.java.net> Changeset: 929a589c869f Author: David Grieve Date: 2013-03-08 15:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/929a589c869f RT-24516: simple cache for Images loaded from stylesheets. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/converters/PaintConverter.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java From jeff at reportmill.com Fri Mar 8 13:35:06 2013 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 8 Mar 2013 15:35:06 -0600 Subject: PopupWindow on Macosx causes KeyEvents to go AWOL In-Reply-To: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> Message-ID: When my app opens a PopupWindow and the user switches to another app, my app no longer receives KeyEvents (for that window). The rub is that this only happens on Macosx, and only when run via Web Start (and probably only in a JFXPanel). I suspect the PopupWindow is failing to remove its EventDispatcher when it AutoHides this way. Any ideas on way to work around this? Sorry for the lame report - I thought I'd see if anyone had any information on this before I spend a few hours figuring out how to create a formal example and filing a bug. jeff PS: The app is at http://reportmill.com/javi . It happens when you hit the pull down menu button in the tool bar then click on another app. From hang.vo at oracle.com Fri Mar 8 13:48:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Mar 2013 21:48:14 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130308214826.D2AD74801C@hg.openjdk.java.net> Changeset: 199a494a54e0 Author: David Grieve Date: 2013-03-08 16:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/199a494a54e0 RT-28888: conditions for setting LabeledText's text fill via -fx-fill did not work with RT-19089 fixes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: ffd70842a48d Author: David Grieve Date: 2013-03-08 16:43 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ffd70842a48d RT-28447: set popup window scene stylesheet to that of the owner window's scene ! javafx-ui-common/src/javafx/stage/PopupWindow.java From hang.vo at oracle.com Sun Mar 10 20:03:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 03:03:58 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130311030417.C17304805A@hg.openjdk.java.net> Changeset: ddb3874aa103 Author: jgiles Date: 2013-03-11 15:09 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ddb3874aa103 RT-28893: ListView PlaceHolder is removed only after second item is added to item list Contributed-by: Sven Reimers Reviewed-by: jgiles ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java Changeset: 7680e1b9d790 Author: jgiles Date: 2013-03-11 15:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7680e1b9d790 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 1e8ef92fe45a Author: jgiles Date: 2013-03-11 15:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1e8ef92fe45a Re-enabling the keyboard input tests for ListView, TreeView, TableView and TreeTableView. Hopefully they don't bring the test infrastructure down again (either by failing on certain platforms or by causing OOME). In any case, if they fail to work they can be @Ignored again, but ideally they would be kept intact and running as they cover a lot of finicky keyboard interaction issues and will help prevent regressions (and I have to write a bunch more tests in the coming weeks for this area too). ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 02a668fbc3b6 Author: jgiles Date: 2013-03-11 15:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/02a668fbc3b6 Fixing a stack overflow issue in VirtualFlow that was identified by the keyboard navigation tests. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Mon Mar 11 02:04:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 09:04:57 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130311090514.BE1224805F@hg.openjdk.java.net> Changeset: cbc4c527bc8a Author: Martin Soch Date: 2013-03-11 09:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cbc4c527bc8a SW pipeline: large glyphs weren't rendered (RT-27789) ! prism-sw/src/com/sun/prism/sw/SWGraphics.java Changeset: c176fd6cd024 Author: Martin Soch Date: 2013-03-11 09:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c176fd6cd024 SW pipeline: was failing with assertion in debug mode, on Windows (RT-28767) ! prism-sw-native/include/PiscesRenderer.inl ! prism-sw-native/src/PiscesBlit.c ! prism-sw-native/src/PiscesPaint.c From hang.vo at oracle.com Mon Mar 11 08:04:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 15:04:31 +0000 Subject: hg: openjfx/8/controls/rt: RT-23427 : [ScrollBar] NPE in mouse event processing. Message-ID: <20130311150440.72E9848063@hg.openjdk.java.net> Changeset: fd29ff6315e7 Author: mickf Date: 2013-03-11 15:01 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fd29ff6315e7 RT-23427 : [ScrollBar] NPE in mouse event processing. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java From hang.vo at oracle.com Mon Mar 11 10:04:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 17:04:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28914: Remove unneeded classes in Animation and unused methods Message-ID: <20130311170500.64EFB48070@hg.openjdk.java.net> Changeset: c77fa8b03077 Author: Richard Bair Date: 2013-03-11 09:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c77fa8b03077 RT-28914: Remove unneeded classes in Animation and unused methods Summary: Removed methods that are unused, and trimmed out 8 Java files that aren't needed. Also moved StandaloneAccessor to test code. ! javafx-anim/src/com/sun/javafx/animation/TickCalculation.java - javafx-anim/src/com/sun/javafx/animation/TimingTarget.java ! javafx-anim/src/com/sun/scenario/DelayedRunnable.java ! javafx-anim/src/com/sun/scenario/Settings.java - javafx-anim/src/com/sun/scenario/StandaloneAccessor.java ! javafx-anim/src/com/sun/scenario/ToolkitAccessor.java ! javafx-anim/src/com/sun/scenario/animation/AbstractMasterTimer.java ! javafx-anim/src/com/sun/scenario/animation/AnimationPulse.java ! javafx-anim/src/com/sun/scenario/animation/AnimationPulseMBean.java - javafx-anim/src/com/sun/scenario/animation/FixedPulseTime.java - javafx-anim/src/com/sun/scenario/animation/MilliCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/NanoCurrentTime.java ! javafx-anim/src/com/sun/scenario/animation/SplineInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/AnimationAccessor.java - javafx-anim/src/com/sun/scenario/animation/shared/AnimationPulseReceiver.java ! javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelope.java - javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelopeFactory.java ! javafx-anim/src/com/sun/scenario/animation/shared/ClipInterpolator.java - javafx-anim/src/com/sun/scenario/animation/shared/CurrentTime.java ! javafx-anim/src/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/GeneralClipInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/InterpolationInterval.java ! javafx-anim/src/com/sun/scenario/animation/shared/PulseReceiver.java ! javafx-anim/src/com/sun/scenario/animation/shared/SimpleClipInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/TimelineClipCore.java ! javafx-anim/src/javafx/animation/Animation.java ! javafx-anim/src/javafx/animation/AnimationAccessorImpl.java + javafx-anim/test/unit/com/sun/scenario/StandaloneAccessor.java - javafx-anim/test/unit/com/sun/scenario/ToolkitAccessorStub.java ! javafx-anim/test/unit/com/sun/scenario/animation/AbstractMasterTimerMock.java ! javafx-anim/test/unit/com/sun/scenario/animation/AbstractMasterTimerTest.java - javafx-anim/test/unit/com/sun/scenario/animation/shared/AnimationPulseReceiverTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/FiniteClipEnvelopeTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/InfiniteClipEnvelopeTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeTest.java ! javafx-anim/test/unit/javafx/animation/AnimationImpl.java ! javafx-anim/test/unit/javafx/animation/AnimationMock.java + javafx-anim/test/unit/javafx/animation/AnimationPulseReceiverTest.java ! javafx-anim/test/unit/javafx/animation/AnimationSetRateTest.java ! javafx-anim/test/unit/javafx/animation/AnimationTest.java ! javafx-ui-common/build-closed.xml ! javafx-ui-common/project.properties ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Cursor.java ! javafx-ui-common/test/unit/javafx/animation/AbstractMasterTimerMock.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformOperationsTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubMasterTimer.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Mon Mar 11 10:18:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 17:18:56 +0000 Subject: hg: openjfx/8/graphics/rt: Backout accidentally committed change to StubToolkit Message-ID: <20130311171902.01D5148072@hg.openjdk.java.net> Changeset: 90056a34a341 Author: Richard Bair Date: 2013-03-11 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/90056a34a341 Backout accidentally committed change to StubToolkit ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Mon Mar 11 11:48:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 18:48:26 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28816: PhongMaterial.toString() method produces StackOverflowError Message-ID: <20130311184833.60B6448074@hg.openjdk.java.net> Changeset: 26c3a8370c80 Author: kcr Date: 2013-03-11 11:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26c3a8370c80 RT-28816: PhongMaterial.toString() method produces StackOverflowError ! javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java + javafx-ui-common/test/unit/javafx/scene/paint/PhongMaterialTest.java From hang.vo at oracle.com Mon Mar 11 12:49:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 19:49:39 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130311195002.6FAB448077@hg.openjdk.java.net> Changeset: ced0a6e6f8b4 Author: David Grieve Date: 2013-03-11 13:47 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ced0a6e6f8b4 RT-28292 [TEST-ONLY]: remove @Ignore from Node_effectiveOrientation_Css_Test and replace Toolkit.getToolkit().firePulse(); with root.impl_processCSS(true) ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: a7abdf74e155 Author: David Grieve Date: 2013-03-11 15:34 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a7abdf74e155 RT-28447: backout changeset ffd70842a48d. Causes issues with Modena ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: 36fcf9f812ed Author: David Grieve Date: 2013-03-11 15:38 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/36fcf9f812ed Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt From hang.vo at oracle.com Mon Mar 11 14:04:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 21:04:22 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130311210432.B440048079@hg.openjdk.java.net> Changeset: 479e1c3e1371 Author: "Jasper Potts" Date: 2013-03-07 18:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/479e1c3e1371 Modena Progress Indicator default size was huge after last fix. Now fixed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 636b8f96d38a Author: "Jasper Potts" Date: 2013-03-11 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/636b8f96d38a Merge From hang.vo at oracle.com Mon Mar 11 14:04:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 21:04:22 +0000 Subject: hg: openjfx/8/graphics/rt: Removed build-closed reference to tests classpath. It looks like the project.properties, which is not used during the closed build, is used during closed test. Message-ID: <20130311210430.7D15148078@hg.openjdk.java.net> Changeset: 782bdba1a80a Author: rbair Date: 2013-03-11 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/782bdba1a80a Removed build-closed reference to tests classpath. It looks like the project.properties, which is not used during the closed build, is used during closed test. ! javafx-ui-common/build-closed.xml From hang.vo at oracle.com Mon Mar 11 14:19:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 21:19:15 +0000 Subject: hg: openjfx/8/controls/rt: Modena : Pagination added spacing between content. Message-ID: <20130311211921.A6B6C4807B@hg.openjdk.java.net> Changeset: c0cc2ab04805 Author: "Jasper Potts" Date: 2013-03-11 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c0cc2ab04805 Modena : Pagination added spacing between content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Mon Mar 11 14:33:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 21:33:59 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130311213408.3A7F44807C@hg.openjdk.java.net> Changeset: b2461430c343 Author: David Grieve Date: 2013-03-11 17:23 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2461430c343 RT-28447: set popup window scene stylesheet to that of the owner window's scene - this time with better checks on whether or not to clear style cache. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: d7a4237233a4 Author: "Jasper Potts" Date: 2013-03-11 14:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d7a4237233a4 Modena - tweek TableView sort arrows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From fbrunnerlist at gmx.ch Mon Mar 11 15:23:17 2013 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 11 Mar 2013 23:23:17 +0100 Subject: [API Review]: RT-28817 - Add explicit dispose() method to MediaPlayer In-Reply-To: <5137CC24.4050905@oracle.com> References: <5137CC24.4050905@oracle.com> Message-ID: <2084659.9Ni4BOz9r1@shire> Consider to implement AutoCloseable instead, which would it make compatible with the new Automatic Resource Management, if needed. http://docs.oracle.com/javase/7/docs/api/java/lang/AutoCloseable.html http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html -Florian Am Mittwoch, 6. M?rz 2013, 15.07:16 schrieb Alexander Matveev: > Hi all, > > Explicit dispose() method is needed to free native resources used by > MediaPlayer. Garbage collector is not reliable enough to free native > resources fast enough, thus when MediaPlayers are created fast enough we > may run out of native memory. Normally, user does not need to call > dispose() method on MediaPlayer if application does not create them > often. After dispose() is called MediaPlayer cannot be used again and > should be disregarded. Media and MediaView associated with disposed > MediaPlayer can be reused. Dispose() will be valid in any states. For > example, when player is playing call to dispose() will stop playback and > release all resources. > > JIRA: > http://javafx-jira.kenai.com/browse/RT-28817 > > Thanks, > Alexander From jasper.potts at oracle.com Mon Mar 11 15:25:40 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Mon, 11 Mar 2013 15:25:40 -0700 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: <513A2909.9070204@oracle.com> References: <513A2909.9070204@oracle.com> Message-ID: <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> I feel like adding "createSymbols" boolean property to Area, & StackedArea charts makes sense to match LineChart. I don't like the idea of adding API to the series object on XYChart as that is more generic and used by many chart types. If the user needs fine grain control of symbols like in RT-21539 they can turn auto symbol generation off with "createSymbols = false" then create their own symbol nodes for the cases when they do want them. Thanks Jasper On Mar 8, 2013, at 10:08 AM, Paru Somashekar wrote: > There is a request for adding the createSymbols flag at the XYChart's Series level instead of on Chart. > JIRA : http://javafx-jira.kenai.com/browse/RT-21539 > > I think it might be a good idea to add it at the Series level so that one can turn ON / OFF symbols per Series rather than for all the series of a chart. > The API could continue to be the same - except live at the Series level. Each chart can then create symbols for each of its Series only if this flag is turned on. > This might however not make much sense for Scatter, Bubble and BarCharts. > What do you think Jasper? > > -Paru. > > On 3/8/13 4:12 AM, Sven Reimers wrote: >> Hi all >> >> AreaChart and StackedAreaChart are missing an API to simply disable the >> creation of symbols. At the moment this is only possible by complex css >> style acrobatics. LineChart on the other hand already provides a simple way >> to do this. The proposed tweak takes the existing API from LineChart and >> adds this to AreaChart and StackedAreaChart. >> >> Desired API change: >> >> /** >> * Indicates whether symbols for data points will be created or not. >> * >> * @return true if symbols for data points will be created and false >> otherwise. >> */ >> public final boolean getCreateSymbols() { return >> createSymbols.getValue(); } >> public final void setCreateSymbols(boolean value) { >> createSymbols.setValue(value); } >> public final BooleanProperty createSymbolsProperty() { return >> createSymbols; } >> >> Desired additional CSS property (incldues additional StyleableProperty): >> >> -fx-create-symbols >> >> >> JIRA: >> http://javafx-jira.kenai.com/browse/RT-28148 >> >> Thank >> >> -Sven >> >> P.S. An updated patch will hopefully be available there too. >> > From hang.vo at oracle.com Mon Mar 11 15:34:25 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 22:34:25 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130311223444.E4B6848084@hg.openjdk.java.net> Changeset: 9d2b8b3fca1d Author: jgiles Date: 2013-03-12 11:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9d2b8b3fca1d RT-28891: 8.0-controls-scrum-404: Controls.TableView-Sort benchmark is broken ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 70b66196aea6 Author: jgiles Date: 2013-03-12 11:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/70b66196aea6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From parvathi.somashekar at oracle.com Mon Mar 11 15:53:46 2013 From: parvathi.somashekar at oracle.com (Paru Somashekar) Date: Mon, 11 Mar 2013 15:53:46 -0700 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> Message-ID: <513E607A.70103@oracle.com> Ok thanks Jasper. That makes sense. I updated RT-21539 with the our plan of not adding the API at the Series level. thanks, Paru. On 3/11/13 3:25 PM, Jasper Potts wrote: > I feel like adding "createSymbols" boolean property to Area,& StackedArea charts makes sense to match LineChart. > > I don't like the idea of adding API to the series object on XYChart as that is more generic and used by many chart types. If the user needs fine grain control of symbols like in RT-21539 they can turn auto symbol generation off with "createSymbols = false" then create their own symbol nodes for the cases when they do want them. > > Thanks > > Jasper > > On Mar 8, 2013, at 10:08 AM, Paru Somashekar wrote: > >> There is a request for adding the createSymbols flag at the XYChart's Series level instead of on Chart. >> JIRA : http://javafx-jira.kenai.com/browse/RT-21539 >> >> I think it might be a good idea to add it at the Series level so that one can turn ON / OFF symbols per Series rather than for all the series of a chart. >> The API could continue to be the same - except live at the Series level. Each chart can then create symbols for each of its Series only if this flag is turned on. >> This might however not make much sense for Scatter, Bubble and BarCharts. >> What do you think Jasper? >> >> -Paru. >> >> On 3/8/13 4:12 AM, Sven Reimers wrote: >>> Hi all >>> >>> AreaChart and StackedAreaChart are missing an API to simply disable the >>> creation of symbols. At the moment this is only possible by complex css >>> style acrobatics. LineChart on the other hand already provides a simple way >>> to do this. The proposed tweak takes the existing API from LineChart and >>> adds this to AreaChart and StackedAreaChart. >>> >>> Desired API change: >>> >>> /** >>> * Indicates whether symbols for data points will be created or not. >>> * >>> * @return true if symbols for data points will be created and false >>> otherwise. >>> */ >>> public final boolean getCreateSymbols() { return >>> createSymbols.getValue(); } >>> public final void setCreateSymbols(boolean value) { >>> createSymbols.setValue(value); } >>> public final BooleanProperty createSymbolsProperty() { return >>> createSymbols; } >>> >>> Desired additional CSS property (incldues additional StyleableProperty): >>> >>> -fx-create-symbols >>> >>> >>> JIRA: >>> http://javafx-jira.kenai.com/browse/RT-28148 >>> >>> Thank >>> >>> -Sven >>> >>> P.S. An updated patch will hopefully be available there too. >>> From phidias51 at gmail.com Mon Mar 11 16:20:34 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 11 Mar 2013 16:20:34 -0700 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: <513E607A.70103@oracle.com> References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> <513E607A.70103@oracle.com> Message-ID: I recently came across the "createSymbols" property code in the LineChart and was wondering if there was some reason to write it this way rather than simply having a default implementation of some Symbol interface which the user can replace by simply setting the value. For my application, I ended up writing some conditional decorators for the symbol, but as I was doing this I thought how much easier it would be if the symbols had a factory where one could register new implementations, or replace the factory itself to provide some conditional switching logic, etc. Any thoughts on improving the flexibility of the charts? Cheers, Mark On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < parvathi.somashekar at oracle.com> wrote: > Ok thanks Jasper. That makes sense. I updated RT-21539 with the our plan > of not adding the API at the Series level. > > thanks, > Paru. > > On 3/11/13 3:25 PM, Jasper Potts wrote: > >> I feel like adding "createSymbols" boolean property to Area,& >> StackedArea charts makes sense to match LineChart. >> >> >> I don't like the idea of adding API to the series object on XYChart as >> that is more generic and used by many chart types. If the user needs fine >> grain control of symbols like in RT-21539 they can turn auto symbol >> generation off with "createSymbols = false" then create their own symbol >> nodes for the cases when they do want them. >> >> Thanks >> >> Jasper >> >> On Mar 8, 2013, at 10:08 AM, Paru Somashekar> somashekar at oracle.com > wrote: >> >> There is a request for adding the createSymbols flag at the XYChart's >>> Series level instead of on Chart. >>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539 >>> >>> I think it might be a good idea to add it at the Series level so that >>> one can turn ON / OFF symbols per Series rather than for all the series of >>> a chart. >>> The API could continue to be the same - except live at the Series level. >>> Each chart can then create symbols for each of its Series only if this flag >>> is turned on. >>> This might however not make much sense for Scatter, Bubble and BarCharts. >>> What do you think Jasper? >>> >>> -Paru. >>> >>> On 3/8/13 4:12 AM, Sven Reimers wrote: >>> >>>> Hi all >>>> >>>> AreaChart and StackedAreaChart are missing an API to simply disable the >>>> creation of symbols. At the moment this is only possible by complex css >>>> style acrobatics. LineChart on the other hand already provides a simple >>>> way >>>> to do this. The proposed tweak takes the existing API from LineChart and >>>> adds this to AreaChart and StackedAreaChart. >>>> >>>> Desired API change: >>>> >>>> /** >>>> * Indicates whether symbols for data points will be created or >>>> not. >>>> * >>>> * @return true if symbols for data points will be created and >>>> false >>>> otherwise. >>>> */ >>>> public final boolean getCreateSymbols() { return >>>> createSymbols.getValue(); } >>>> public final void setCreateSymbols(boolean value) { >>>> createSymbols.setValue(value); } >>>> public final BooleanProperty createSymbolsProperty() { return >>>> createSymbols; } >>>> >>>> Desired additional CSS property (incldues additional StyleableProperty): >>>> >>>> -fx-create-symbols >>>> >>>> >>>> JIRA: >>>> http://javafx-jira.kenai.com/**browse/RT-28148 >>>> >>>> Thank >>>> >>>> -Sven >>>> >>>> P.S. An updated patch will hopefully be available there too. >>>> >>>> > From jasper.potts at oracle.com Mon Mar 11 16:33:23 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Mon, 11 Mar 2013 16:33:23 -0700 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> <513E607A.70103@oracle.com> Message-ID: A symbol factory would also be a good idea, take in data item and return Node. Jasper On Mar 11, 2013, at 4:20 PM, Mark Fortner wrote: > I recently came across the "createSymbols" property code in the LineChart > and was wondering if there was some reason to write it this way rather than > simply having a default implementation of some Symbol interface which the > user can replace by simply setting the value. > > For my application, I ended up writing some conditional decorators for the > symbol, but as I was doing this I thought how much easier it would be if > the symbols had a factory where one could register new implementations, or > replace the factory itself to provide some conditional switching logic, etc. > > Any thoughts on improving the flexibility of the charts? > > Cheers, > > Mark > > > > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < > parvathi.somashekar at oracle.com> wrote: > >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the our plan >> of not adding the API at the Series level. >> >> thanks, >> Paru. >> >> On 3/11/13 3:25 PM, Jasper Potts wrote: >> >>> I feel like adding "createSymbols" boolean property to Area,& >>> StackedArea charts makes sense to match LineChart. >>> >>> >>> I don't like the idea of adding API to the series object on XYChart as >>> that is more generic and used by many chart types. If the user needs fine >>> grain control of symbols like in RT-21539 they can turn auto symbol >>> generation off with "createSymbols = false" then create their own symbol >>> nodes for the cases when they do want them. >>> >>> Thanks >>> >>> Jasper >>> >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar>> somashekar at oracle.com > wrote: >>> >>> There is a request for adding the createSymbols flag at the XYChart's >>>> Series level instead of on Chart. >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539 >>>> >>>> I think it might be a good idea to add it at the Series level so that >>>> one can turn ON / OFF symbols per Series rather than for all the series of >>>> a chart. >>>> The API could continue to be the same - except live at the Series level. >>>> Each chart can then create symbols for each of its Series only if this flag >>>> is turned on. >>>> This might however not make much sense for Scatter, Bubble and BarCharts. >>>> What do you think Jasper? >>>> >>>> -Paru. >>>> >>>> On 3/8/13 4:12 AM, Sven Reimers wrote: >>>> >>>>> Hi all >>>>> >>>>> AreaChart and StackedAreaChart are missing an API to simply disable the >>>>> creation of symbols. At the moment this is only possible by complex css >>>>> style acrobatics. LineChart on the other hand already provides a simple >>>>> way >>>>> to do this. The proposed tweak takes the existing API from LineChart and >>>>> adds this to AreaChart and StackedAreaChart. >>>>> >>>>> Desired API change: >>>>> >>>>> /** >>>>> * Indicates whether symbols for data points will be created or >>>>> not. >>>>> * >>>>> * @return true if symbols for data points will be created and >>>>> false >>>>> otherwise. >>>>> */ >>>>> public final boolean getCreateSymbols() { return >>>>> createSymbols.getValue(); } >>>>> public final void setCreateSymbols(boolean value) { >>>>> createSymbols.setValue(value); } >>>>> public final BooleanProperty createSymbolsProperty() { return >>>>> createSymbols; } >>>>> >>>>> Desired additional CSS property (incldues additional StyleableProperty): >>>>> >>>>> -fx-create-symbols >>>>> >>>>> >>>>> JIRA: >>>>> http://javafx-jira.kenai.com/**browse/RT-28148 >>>>> >>>>> Thank >>>>> >>>>> -Sven >>>>> >>>>> P.S. An updated patch will hopefully be available there too. >>>>> >>>>> >> From hang.vo at oracle.com Mon Mar 11 16:49:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Mar 2013 23:49:15 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130311234925.4A14D48085@hg.openjdk.java.net> Changeset: 316976bf4b3c Author: jgiles Date: 2013-03-12 12:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/316976bf4b3c RT-28898: [TableView, TreeTableView] When column 'sortable' is set to false the sort node doesn't disappear. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 283da31ead02 Author: jgiles Date: 2013-03-12 12:35 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/283da31ead02 Ignoring unit test based on change for RT-28891 ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java From hang.vo at oracle.com Mon Mar 11 17:48:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 00:48:37 +0000 Subject: hg: openjfx/8/controls/rt: Modena: Tab Pane buttom tabs overflow arrow is not centered. Message-ID: <20130312004844.CD2004808D@hg.openjdk.java.net> Changeset: e4bdba51e3b6 Author: "Jasper Potts" Date: 2013-03-11 17:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e4bdba51e3b6 Modena: Tab Pane buttom tabs overflow arrow is not centered. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Tue Mar 12 00:48:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 07:48:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28550 - Regression: dirtyopts repaint issue in HelloFloodGame Message-ID: <20130312074853.9784948096@hg.openjdk.java.net> Changeset: 98c92b4b238d Author: Radko Najman Date: 2013-03-12 08:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98c92b4b238d RT-28550 - Regression: dirtyopts repaint issue in HelloFloodGame ! javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java + javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionClipTest.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java From sven.reimers at gmail.com Tue Mar 12 03:01:54 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 12 Mar 2013 11:01:54 +0100 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> <513E607A.70103@oracle.com> Message-ID: I like the idea of a symbol factory as well, but it will need to be in some way configured per series, since a data item (XYChart.Data) does not know about its series. Seems this may be a bigger API change though - Should we track this separately? Any further comments? -Sven On Tue, Mar 12, 2013 at 12:33 AM, Jasper Potts wrote: > A symbol factory would also be a good idea, take in data item and return > Node. > > Jasper > > On Mar 11, 2013, at 4:20 PM, Mark Fortner wrote: > > > I recently came across the "createSymbols" property code in the LineChart > > and was wondering if there was some reason to write it this way rather > than > > simply having a default implementation of some Symbol interface which the > > user can replace by simply setting the value. > > > > For my application, I ended up writing some conditional decorators for > the > > symbol, but as I was doing this I thought how much easier it would be if > > the symbols had a factory where one could register new implementations, > or > > replace the factory itself to provide some conditional switching logic, > etc. > > > > Any thoughts on improving the flexibility of the charts? > > > > Cheers, > > > > Mark > > > > > > > > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < > > parvathi.somashekar at oracle.com> wrote: > > > >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the our plan > >> of not adding the API at the Series level. > >> > >> thanks, > >> Paru. > >> > >> On 3/11/13 3:25 PM, Jasper Potts wrote: > >> > >>> I feel like adding "createSymbols" boolean property to Area,& > >>> StackedArea charts makes sense to match LineChart. > >>> > >>> > >>> I don't like the idea of adding API to the series object on XYChart as > >>> that is more generic and used by many chart types. If the user needs > fine > >>> grain control of symbols like in RT-21539 they can turn auto symbol > >>> generation off with "createSymbols = false" then create their own > symbol > >>> nodes for the cases when they do want them. > >>> > >>> Thanks > >>> > >>> Jasper > >>> > >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar >>> somashekar at oracle.com > wrote: > >>> > >>> There is a request for adding the createSymbols flag at the XYChart's > >>>> Series level instead of on Chart. > >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539< > http://javafx-jira.kenai.com/browse/RT-21539> > >>>> > >>>> I think it might be a good idea to add it at the Series level so that > >>>> one can turn ON / OFF symbols per Series rather than for all the > series of > >>>> a chart. > >>>> The API could continue to be the same - except live at the Series > level. > >>>> Each chart can then create symbols for each of its Series only if > this flag > >>>> is turned on. > >>>> This might however not make much sense for Scatter, Bubble and > BarCharts. > >>>> What do you think Jasper? > >>>> > >>>> -Paru. > >>>> > >>>> On 3/8/13 4:12 AM, Sven Reimers wrote: > >>>> > >>>>> Hi all > >>>>> > >>>>> AreaChart and StackedAreaChart are missing an API to simply disable > the > >>>>> creation of symbols. At the moment this is only possible by complex > css > >>>>> style acrobatics. LineChart on the other hand already provides a > simple > >>>>> way > >>>>> to do this. The proposed tweak takes the existing API from LineChart > and > >>>>> adds this to AreaChart and StackedAreaChart. > >>>>> > >>>>> Desired API change: > >>>>> > >>>>> /** > >>>>> * Indicates whether symbols for data points will be created or > >>>>> not. > >>>>> * > >>>>> * @return true if symbols for data points will be created and > >>>>> false > >>>>> otherwise. > >>>>> */ > >>>>> public final boolean getCreateSymbols() { return > >>>>> createSymbols.getValue(); } > >>>>> public final void setCreateSymbols(boolean value) { > >>>>> createSymbols.setValue(value); } > >>>>> public final BooleanProperty createSymbolsProperty() { return > >>>>> createSymbols; } > >>>>> > >>>>> Desired additional CSS property (incldues additional > StyleableProperty): > >>>>> > >>>>> -fx-create-symbols > >>>>> > >>>>> > >>>>> JIRA: > >>>>> http://javafx-jira.kenai.com/**browse/RT-28148< > http://javafx-jira.kenai.com/browse/RT-28148> > >>>>> > >>>>> Thank > >>>>> > >>>>> -Sven > >>>>> > >>>>> P.S. An updated patch will hopefully be available there too. > >>>>> > >>>>> > >> > > -- 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 * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * 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 sdn at interactivemesh.com Tue Mar 12 03:46:17 2013 From: sdn at interactivemesh.com (August Lammersdorf, InteractiveMesh) Date: Tue, 12 Mar 2013 11:46:17 +0100 Subject: hg: openjfx/8/graphics/rt: RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 Message-ID: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> - Which releases will be affected by this restriction? - What are the reasons? Thanks, August From hang.vo at oracle.com Tue Mar 12 04:04:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 11:04:38 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28781 Mac: JVM crashes when screen resolution is changed Message-ID: <20130312110452.95BAD480A0@hg.openjdk.java.net> Changeset: df3b6b3fdef5 Author: Petr Pchelko Date: 2013-03-12 14:59 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/df3b6b3fdef5 RT-28781 Mac: JVM crashes when screen resolution is changed Reviewed-by: Anthomy, Steve ! glass/glass-lib-macosx/src/GlassTimer.m From hang.vo at oracle.com Tue Mar 12 04:33:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 11:33:31 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-19239: Memory leak with Animated images Message-ID: <20130312113337.90535480A2@hg.openjdk.java.net> Changeset: d45b7c33204d Author: Lubomir Nerad Date: 2013-03-12 12:15 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d45b7c33204d Fix for RT-19239: Memory leak with Animated images ! javafx-ui-common/src/javafx/scene/image/Image.java From kevin.rushforth at oracle.com Tue Mar 12 04:40:21 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 12 Mar 2013 04:40:21 -0700 Subject: RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 In-Reply-To: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> References: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> Message-ID: <513F1425.9040305@oracle.com> The restriction of 32 unique smoothing groups was already there. This is just documenting and validating that restriction. -- Kevin August Lammersdorf, InteractiveMesh wrote: > - Which releases will be affected by this restriction? > > - What are the reasons? > > Thanks, August From neugens at redhat.com Tue Mar 12 08:07:38 2013 From: neugens at redhat.com (Mario Torre) Date: Tue, 12 Mar 2013 16:07:38 +0100 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> Message-ID: <1363100858.3303.91.camel@pegasus> Il giorno ven, 08/03/2013 alle 12.02 -0800, Richard Bair ha scritto: > I just filed http://javafx-jira.kenai.com/browse/RT-28886 which is a pretty straightforward fix, and for anybody looking to get their feet wet in making a contribution it should be a pretty good one to ease into the process :-) > > Richard Hi Richard, Maybe I just completely misunderstood your request, since it seems to me that you have included in the report also the actual code to fix it :) Anyway, here is a webrev: http://cr.openjdk.java.net/~neugens/RT-28886/webrev.01/ I tried to compile to test it out, but I'm now stuck on antlr: http://www.fpaste.org/PAKU/ I put the various antlr jars in the master/lib directory, but maybe the version doesn't match exactly the one needed. Do we need those specific antlr jars? Can you point me to a location where I can download them? I would also be interested in performing some test to see if there's any real speed gain here. I tried with ant build, the gradle build fails with more cryptic failures for me... Any help appreciated. Cheers, Mario From hang.vo at oracle.com Tue Mar 12 09:18:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 16:18:46 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: checking input parametrs in Pisces surfaces Message-ID: <20130312161859.1A5A4480AE@hg.openjdk.java.net> Changeset: ca8641b9b0f4 Author: Martin Soch Date: 2013-03-12 17:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ca8641b9b0f4 SW pipeline: checking input parametrs in Pisces surfaces ! prism-sw-native/src/JJavaSurface.c ! prism-sw-native/src/JNativeSurface.c ! prism-sw/src/com/sun/pisces/AbstractSurface.java ! prism-sw/src/com/sun/pisces/JavaSurface.java ! prism-sw/src/com/sun/pisces/NativeSurface.java From hang.vo at oracle.com Tue Mar 12 09:48:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 16:48:39 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130312164854.73B83480B2@hg.openjdk.java.net> Changeset: 3bf53096ec0a Author: hudson Date: 2013-03-07 14:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3bf53096ec0a Added tag 8.0-b80 for changeset 637a0d67106f ! .hgtags Changeset: 9f21025a5563 Author: jgodinez Date: 2013-03-12 09:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9f21025a5563 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-anim/src/com/sun/javafx/animation/TimingTarget.java - javafx-anim/src/com/sun/scenario/StandaloneAccessor.java - javafx-anim/src/com/sun/scenario/animation/FixedPulseTime.java - javafx-anim/src/com/sun/scenario/animation/MilliCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/NanoCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/shared/AnimationPulseReceiver.java - javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelopeFactory.java - javafx-anim/src/com/sun/scenario/animation/shared/CurrentTime.java - javafx-anim/test/unit/com/sun/scenario/ToolkitAccessorStub.java - javafx-anim/test/unit/com/sun/scenario/animation/shared/AnimationPulseReceiverTest.java From richard.bair at oracle.com Tue Mar 12 09:54:02 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 12 Mar 2013 09:54:02 -0700 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <1363100858.3303.91.camel@pegasus> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> Message-ID: <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> Hi Mario! On Mar 12, 2013, at 8:07 AM, Mario Torre wrote: > Il giorno ven, 08/03/2013 alle 12.02 -0800, Richard Bair ha scritto: >> I just filed http://javafx-jira.kenai.com/browse/RT-28886 which is a pretty straightforward fix, and for anybody looking to get their feet wet in making a contribution it should be a pretty good one to ease into the process :-) >> >> Richard > > Hi Richard, > > Maybe I just completely misunderstood your request, since it seems to me > that you have included in the report also the actual code to fix it :) ha, sure enough. I just wrote the description without trying it out, turns out it was just that easy :-) > Anyway, here is a webrev: > > http://cr.openjdk.java.net/~neugens/RT-28886/webrev.01/ > > I tried to compile to test it out, but I'm now stuck on antlr: > > http://www.fpaste.org/PAKU/ > > I put the various antlr jars in the master/lib directory, but maybe the > version doesn't match exactly the one needed. > > Do we need those specific antlr jars? Can you point me to a location > where I can download them? Did you by chance watch the video I hosted here? https://wiki-beta.openjdk.java.net/display/OpenJFX/Building+OpenJFX On minute 7 I download these in the video (it is too long and boring so I doubt you've seen it :-). I will do a new one when the gradle stuff is ready to go that is hopefully a 30 second video!). I'll also update the wiki with a link to the web page. www.antlr3.org/download > I would also be interested in performing some test to see if there's any > real speed gain here. > > I tried with ant build, the gradle build fails with more cryptic > failures for me? I'm guessing you are on Linux? I have worked out windows & mac, about to start on the linux build. I'm guessing it dies on building native code? Richard From hang.vo at oracle.com Tue Mar 12 11:33:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 18:33:49 +0000 Subject: hg: openjfx/8/controls/rt: RT-28907: CSS should only reset properites to initial values if there are no styles to apply to the node after an in-line style or stylesheet change Message-ID: <20130312183404.396B4480B6@hg.openjdk.java.net> Changeset: c9d36dae8a70 Author: David Grieve Date: 2013-03-12 14:04 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c9d36dae8a70 RT-28907: CSS should only reset properites to initial values if there are no styles to apply to the node after an in-line style or stylesheet change ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java From neugens at redhat.com Tue Mar 12 12:25:35 2013 From: neugens at redhat.com (Mario Torre) Date: Tue, 12 Mar 2013 20:25:35 +0100 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> Message-ID: <1363116335.3303.110.camel@pegasus> Il giorno mar, 12/03/2013 alle 09.54 -0700, Richard Bair ha scritto: > Did you by chance watch the video I hosted here? > https://wiki-beta.openjdk.java.net/display/OpenJFX/Building+OpenJFX > On minute 7 I download these in the video (it is too long and boring > so I doubt you've seen it :-). I will do a new one when the gradle > stuff is ready to go that is hopefully a 30 second video!). I'll also > update the wiki with a link to the web page. Yeah, no, I didn't... but it's not boring at all :) > www.antlr3.org/download Great, thanks! Indeed, the build went a bit further. This is a problem though because we need to take care of the version of antlr that is installed on the system... Is there a plan to eventually integration this code into the OpenJDK 8 tree (like nashorn, for instance)? Anyway, back on the build, with OpenJDK 8 or Oracle JDK 8 EA and ant 1.8.4 it fails with this weird message: master/rt/build.xml:87: The following error occurred while executing this line: master/rt/decora-runtime/build-common.xml:109: The following error occurred while executing this line: master/rt/decora-runtime/build-common.xml:24: Class not found: javac1.8 It seems that ant 1.9 is now required to compile OpenJFX, at least on Linux. > I'm guessing you are on Linux? I have worked out windows & mac, about > to start on the linux build. I'm guessing it dies on building native > code? It seems that it fails with the :graphics:effects-jsl:compileBlend task. I just gave it another try and here is the error message: http://www.fpaste.org/9EEH/ But maybe I'm just doing something here, I'm not much of a gradle expert yet. One final question, what other code is still needed to be open sourced? I guess we're mostly done, right? Cheers, Mario From hang.vo at oracle.com Tue Mar 12 12:18:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 19:18:46 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-28939: ScrollBar arrows are rendering with unexpected antialising Message-ID: <20130312191858.5179A480B8@hg.openjdk.java.net> Changeset: ad5cee5bfad6 Author: "Jasper Potts" Date: 2013-03-12 12:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ad5cee5bfad6 Fixed RT-28939: ScrollBar arrows are rendering with unexpected antialising ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java From neugens at redhat.com Tue Mar 12 13:17:55 2013 From: neugens at redhat.com (Mario Torre) Date: Tue, 12 Mar 2013 21:17:55 +0100 Subject: OpenJFX Build [Was Re: Anybody looking for a quick patch to contribute?] In-Reply-To: <1363116335.3303.110.camel@pegasus> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: <1363119475.3303.117.camel@pegasus> Il giorno mar, 12/03/2013 alle 20.25 +0100, Mario Torre ha scritto: > Il giorno mar, 12/03/2013 alle 09.54 -0700, Richard Bair ha scritto: > > > Did you by chance watch the video I hosted here? > > https://wiki-beta.openjdk.java.net/display/OpenJFX/Building+OpenJFX > > On minute 7 I download these in the video (it is too long and boring > > so I doubt you've seen it :-). I will do a new one when the gradle > > stuff is ready to go that is hopefully a 30 second video!). I'll also > > update the wiki with a link to the web page. > > Yeah, no, I didn't... but it's not boring at all :) > > > www.antlr3.org/download > > Great, thanks! > > Indeed, the build went a bit further. This is a problem though because > we need to take care of the version of antlr that is installed on the > system... > > Is there a plan to eventually integration this code into the OpenJDK 8 > tree (like nashorn, for instance)? > > Anyway, back on the build, with OpenJDK 8 or Oracle JDK 8 EA and ant > 1.8.4 it fails with this weird message: > > master/rt/build.xml:87: The following error occurred while executing > this line: > master/rt/decora-runtime/build-common.xml:109: The following error > occurred while executing this line: > master/rt/decora-runtime/build-common.xml:24: Class not found: javac1.8 > > It seems that ant 1.9 is now required to compile OpenJFX, at least on > Linux. > > > I'm guessing you are on Linux? I have worked out windows & mac, about > > to start on the linux build. I'm guessing it dies on building native > > code? > > It seems that it fails with the :graphics:effects-jsl:compileBlend task. > > I just gave it another try and here is the error message: > > http://www.fpaste.org/9EEH/ > > But maybe I'm just doing something here, I'm not much of a gradle expert > yet. > > One final question, what other code is still needed to be open sourced? > I guess we're mostly done, right? I answer myself :) Definitely not much left to open, but the code is still not enough to run the OpenJFX HelloWorld without the closed jars in the classpath [1] I guess I need to wait a bit more to try this out again... But this brings another question (sorry for spamming today!) I remember you had some plans regarding the font subsystem. What happened to that? I didn't see much discussion going on anymore this but I guess this is actually a very good place where we can help out with some non trivial code contribution. Cheers, Mario [1] Exception in thread "main" java.lang.RuntimeException: Application launch error at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:157) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.NoClassDefFoundError: com/sun/javafx/tk/desktop/DesktopToolkit at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:188) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:195) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:166) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:616) at com.sun.javafx.application.LauncherImpl.access $000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:150) ... 1 more Caused by: java.lang.ClassNotFoundException: com.sun.javafx.tk.desktop.DesktopToolkit at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 20 more From hang.vo at oracle.com Tue Mar 12 13:33:21 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 20:33:21 +0000 Subject: hg: openjfx/8/controls/rt: Fix for RT-28506 - Create better icon svg for scrollbar arrows Message-ID: <20130312203329.32556480BD@hg.openjdk.java.net> Changeset: 70612d9f2f28 Author: mo.chicharro Date: 2013-03-12 20:21 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/70612d9f2f28 Fix for RT-28506 - Create better icon svg for scrollbar arrows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Tue Mar 12 14:49:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 21:49:01 +0000 Subject: hg: openjfx/8/controls/rt: RT-21964: Insert null placeholder for stylesheet url when parsing. Substitute actual stylesheet url when declaration is added to the stylesheet Message-ID: <20130312214904.C1332480C2@hg.openjdk.java.net> Changeset: 1ee809c26ddd Author: David Grieve Date: 2013-03-12 17:41 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1ee809c26ddd RT-21964: Insert null placeholder for stylesheet url when parsing. Substitute actual stylesheet url when declaration is added to the stylesheet ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java From hang.vo at oracle.com Tue Mar 12 15:04:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 22:04:43 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130312220455.2BCEB480C3@hg.openjdk.java.net> Changeset: a0a297647a7c Author: "Jasper Potts" Date: 2013-03-12 14:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a0a297647a7c Modena: Fixed scroll arrow centered on TextArea and ScrollPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5634b086feaa Author: "Jasper Potts" Date: 2013-03-12 14:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5634b086feaa Merge From hang.vo at oracle.com Tue Mar 12 15:19:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 22:19:19 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130312221932.E40A0480C4@hg.openjdk.java.net> Changeset: 50811c4425d8 Author: "Jasper Potts" Date: 2013-03-12 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/50811c4425d8 Modena test app, added workaround for snapshot texture size limit. ! apps/experiments/Modena/src/modena/Modena.java Changeset: 6045e676948b Author: David Grieve Date: 2013-03-12 18:05 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6045e676948b RT-21967: if absolute path without a scheme, strip leading / before resolving URL. ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java Changeset: ecc8529fdc5b Author: David Grieve Date: 2013-03-12 18:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ecc8529fdc5b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt From hang.vo at oracle.com Tue Mar 12 16:18:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Mar 2013 23:18:56 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130312231907.97D13480C6@hg.openjdk.java.net> Changeset: fe5a6223ed42 Author: rbair Date: 2013-03-12 09:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe5a6223ed42 RT-28932: TransformChangedEvent TRANSFORM_CHANGED event type has the wrong name Summary: The TransformChangedEvent reused the "ACTION" name, which results in an exception if both the TransformChangedEvent and ActionEvent are used in the same app. Unit test supplied with the fix. ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformChangedEventTest.java Changeset: b93620846ba4 Author: rbair Date: 2013-03-12 16:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b93620846ba4 Merge From hang.vo at oracle.com Tue Mar 12 17:19:20 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 00:19:20 +0000 Subject: hg: openjfx/8/controls/rt: 31 new changesets Message-ID: <20130313002103.3CDAB480CA@hg.openjdk.java.net> Changeset: 14df3baed0f8 Author: Alexander Kouznetsov Date: 2013-03-05 23:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/14df3baed0f8 Ensemble3: Fix for RT-28257 Ensemble3: XYChart Visualization in TreeTableView doesn't update on underlying data update ! apps/samples/Ensemble8/src/app/ensemble/samplepage/XYDataVisualizer.java Changeset: 57f5d847140b Author: Pavel Safrata Date: 2013-03-06 08:10 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/57f5d847140b RT-28797: Fixed NPE when picking node clipped by a node with pickOnBounds set to true. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/PickAndContainsTest.java Changeset: dd17e3699d72 Author: Martin Sladecek Date: 2013-03-06 12:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dd17e3699d72 RT-28636 ObservableLists has wrong order of notification types ! javafx-beans/src/javafx/collections/ListChangeBuilder.java ! javafx-beans/src/javafx/collections/ListChangeListener.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java Changeset: 7fa12f6c2e16 Author: Martin Sladecek Date: 2013-03-06 13:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7fa12f6c2e16 RT-28537 Bidirectional Binding does not maintain the invariant if one of the properties is bound ! javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java ! javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingTest.java Changeset: 3ec5209e2c07 Author: Martin Sladecek Date: 2013-03-06 15:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3ec5209e2c07 RT-28790 Map/Set null values/keys not handled correctly by listeners ! javafx-beans/src/com/sun/javafx/binding/MapExpressionHelper.java ! javafx-beans/src/com/sun/javafx/binding/SetExpressionHelper.java ! javafx-beans/src/com/sun/javafx/collections/ObservableMapWrapper.java ! javafx-beans/src/com/sun/javafx/collections/ObservableSetWrapper.java ! javafx-beans/test/javafx/collections/ObservableMapTestBase.java ! javafx-beans/test/javafx/collections/ObservableSetTestBase.java Changeset: df3ce8a3d2aa Author: Martin Sladecek Date: 2013-03-06 16:26 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/df3ce8a3d2aa RT-26162 Split ObservableList implementations into RandomAcess and Sequential ! javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableSequentialListWrapper.java ! javafx-beans/src/javafx/collections/FXCollections.java Changeset: bc78e8b64377 Author: Chien Yang Date: 2013-03-06 08:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bc78e8b64377 Fix to RT-28821: FX 8 3D: AmbientLight isn't implemented. Approved by Kevin ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape3D.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: c6f4b6d77cbb Author: Chien Yang Date: 2013-03-06 08:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c6f4b6d77cbb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: e2f88c00234e Author: dmasada Date: 2013-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e2f88c00234e RT-28749 Add Ensemble8 to internal build (add fxpackager use) + apps/build-tasks.xml ! apps/samples/Ensemble8/build.xml Changeset: 1a825fa0340f Author: dmasada Date: 2013-03-06 18:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1a825fa0340f Ensemble8: fixing comments ! apps/samples/Ensemble8/src/app/ensemble/EmbeddedApplication.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/PieChartDataVisualizer.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/XYDataVisualizer.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/DocumentationIndexer.java Changeset: 05ce1a10c53f Author: Anthony Petrov Date: 2013-03-07 15:35 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/05ce1a10c53f RT-28283 and RT-28284: HiDPI robot support ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass-lib-macosx/src/GlassRobot.m ! glass/glass-lib-macosx/src/GlassStatics.h ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/Pixels.java ! glass/glass/src/com/sun/glass/ui/Robot.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkApplication.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkPixels.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkRobot.java ! glass/glass/src/com/sun/glass/ui/ios/IosApplication.java ! glass/glass/src/com/sun/glass/ui/ios/IosPixels.java ! glass/glass/src/com/sun/glass/ui/ios/IosRobot.java ! glass/glass/src/com/sun/glass/ui/lens/LensApplication.java ! glass/glass/src/com/sun/glass/ui/lens/LensPixels.java ! glass/glass/src/com/sun/glass/ui/lens/LensRobot.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java ! glass/glass/src/com/sun/glass/ui/mac/MacPixels.java ! glass/glass/src/com/sun/glass/ui/mac/MacRobot.java ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java ! glass/glass/src/com/sun/glass/ui/swt/SWTPixels.java ! glass/glass/src/com/sun/glass/ui/swt/SWTRobot.java ! glass/glass/src/com/sun/glass/ui/win/WinApplication.java ! glass/glass/src/com/sun/glass/ui/win/WinPixels.java ! glass/glass/src/com/sun/glass/ui/win/WinRobot.java Changeset: 8e27b105aa5f Author: Alexander Zvegintsev Date: 2013-03-07 16:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8e27b105aa5f RT-28493 Gtk: calling stage.setResizable(false) does not work on Ubuntu Linux ! glass/glass-lib-gtk/src/GlassApplication.cpp ! glass/glass-lib-gtk/src/glass_window.cpp ! glass/glass-lib-gtk/src/glass_window.h Changeset: 7ab5cc8ac4a7 Author: jgodinez Date: 2013-03-07 08:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7ab5cc8ac4a7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: a52bbebbcdb8 Author: rbair Date: 2013-03-07 12:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a52bbebbcdb8 Updated gradle build script to build on windows. Testing is not working yet on windows for Graphics project. ! build.gradle Changeset: 87b6bc4d05c2 Author: Yao Wang Date: 2013-03-07 13:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/87b6bc4d05c2 RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java + javafx-sg-prism/test/com/sun/javafx/sg/prism/NGTriangleMeshTest.java ! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java + javafx-ui-common/test/unit/javafx/scene/shape/TriangleMeshTest.java Changeset: 3465e08c8a3a Author: rbair Date: 2013-03-07 19:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3465e08c8a3a Added ability to designate the build dir instead of inferring it, so that I could make this work with Gradle ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java Changeset: 86c6c588c7a7 Author: rbair Date: 2013-03-07 19:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/86c6c588c7a7 Upated Gradle build & generation scripts ! build.gradle ! generator.gradle Changeset: a359928812d1 Author: rbair Date: 2013-03-07 20:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a359928812d1 Last change to this test broke it for normal ant builds -- fixed it up. ! build.gradle ! generator.gradle ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java Changeset: ccb70bfec745 Author: rbair Date: 2013-03-07 21:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ccb70bfec745 The test target was wrong, attempting to test projects that either didn't exist, or that didn't have any tests! It wouldn't even run. ! build.xml Changeset: cbc4c527bc8a Author: Martin Soch Date: 2013-03-11 09:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cbc4c527bc8a SW pipeline: large glyphs weren't rendered (RT-27789) ! prism-sw/src/com/sun/prism/sw/SWGraphics.java Changeset: c176fd6cd024 Author: Martin Soch Date: 2013-03-11 09:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c176fd6cd024 SW pipeline: was failing with assertion in debug mode, on Windows (RT-28767) ! prism-sw-native/include/PiscesRenderer.inl ! prism-sw-native/src/PiscesBlit.c ! prism-sw-native/src/PiscesPaint.c Changeset: c77fa8b03077 Author: Richard Bair Date: 2013-03-11 09:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c77fa8b03077 RT-28914: Remove unneeded classes in Animation and unused methods Summary: Removed methods that are unused, and trimmed out 8 Java files that aren't needed. Also moved StandaloneAccessor to test code. ! javafx-anim/src/com/sun/javafx/animation/TickCalculation.java - javafx-anim/src/com/sun/javafx/animation/TimingTarget.java ! javafx-anim/src/com/sun/scenario/DelayedRunnable.java ! javafx-anim/src/com/sun/scenario/Settings.java - javafx-anim/src/com/sun/scenario/StandaloneAccessor.java ! javafx-anim/src/com/sun/scenario/ToolkitAccessor.java ! javafx-anim/src/com/sun/scenario/animation/AbstractMasterTimer.java ! javafx-anim/src/com/sun/scenario/animation/AnimationPulse.java ! javafx-anim/src/com/sun/scenario/animation/AnimationPulseMBean.java - javafx-anim/src/com/sun/scenario/animation/FixedPulseTime.java - javafx-anim/src/com/sun/scenario/animation/MilliCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/NanoCurrentTime.java ! javafx-anim/src/com/sun/scenario/animation/SplineInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/AnimationAccessor.java - javafx-anim/src/com/sun/scenario/animation/shared/AnimationPulseReceiver.java ! javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelope.java - javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelopeFactory.java ! javafx-anim/src/com/sun/scenario/animation/shared/ClipInterpolator.java - javafx-anim/src/com/sun/scenario/animation/shared/CurrentTime.java ! javafx-anim/src/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/GeneralClipInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/InterpolationInterval.java ! javafx-anim/src/com/sun/scenario/animation/shared/PulseReceiver.java ! javafx-anim/src/com/sun/scenario/animation/shared/SimpleClipInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/TimelineClipCore.java ! javafx-anim/src/javafx/animation/Animation.java ! javafx-anim/src/javafx/animation/AnimationAccessorImpl.java + javafx-anim/test/unit/com/sun/scenario/StandaloneAccessor.java - javafx-anim/test/unit/com/sun/scenario/ToolkitAccessorStub.java ! javafx-anim/test/unit/com/sun/scenario/animation/AbstractMasterTimerMock.java ! javafx-anim/test/unit/com/sun/scenario/animation/AbstractMasterTimerTest.java - javafx-anim/test/unit/com/sun/scenario/animation/shared/AnimationPulseReceiverTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/FiniteClipEnvelopeTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/InfiniteClipEnvelopeTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeTest.java ! javafx-anim/test/unit/javafx/animation/AnimationImpl.java ! javafx-anim/test/unit/javafx/animation/AnimationMock.java + javafx-anim/test/unit/javafx/animation/AnimationPulseReceiverTest.java ! javafx-anim/test/unit/javafx/animation/AnimationSetRateTest.java ! javafx-anim/test/unit/javafx/animation/AnimationTest.java ! javafx-ui-common/build-closed.xml ! javafx-ui-common/project.properties ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Cursor.java ! javafx-ui-common/test/unit/javafx/animation/AbstractMasterTimerMock.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformOperationsTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubMasterTimer.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 90056a34a341 Author: Richard Bair Date: 2013-03-11 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/90056a34a341 Backout accidentally committed change to StubToolkit ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 26c3a8370c80 Author: kcr Date: 2013-03-11 11:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/26c3a8370c80 RT-28816: PhongMaterial.toString() method produces StackOverflowError ! javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java + javafx-ui-common/test/unit/javafx/scene/paint/PhongMaterialTest.java Changeset: 782bdba1a80a Author: rbair Date: 2013-03-11 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/782bdba1a80a Removed build-closed reference to tests classpath. It looks like the project.properties, which is not used during the closed build, is used during closed test. ! javafx-ui-common/build-closed.xml Changeset: 98c92b4b238d Author: Radko Najman Date: 2013-03-12 08:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/98c92b4b238d RT-28550 - Regression: dirtyopts repaint issue in HelloFloodGame ! javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java + javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionClipTest.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java Changeset: df3b6b3fdef5 Author: Petr Pchelko Date: 2013-03-12 14:59 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/df3b6b3fdef5 RT-28781 Mac: JVM crashes when screen resolution is changed Reviewed-by: Anthomy, Steve ! glass/glass-lib-macosx/src/GlassTimer.m Changeset: d45b7c33204d Author: Lubomir Nerad Date: 2013-03-12 12:15 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d45b7c33204d Fix for RT-19239: Memory leak with Animated images ! javafx-ui-common/src/javafx/scene/image/Image.java Changeset: ca8641b9b0f4 Author: Martin Soch Date: 2013-03-12 17:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ca8641b9b0f4 SW pipeline: checking input parametrs in Pisces surfaces ! prism-sw-native/src/JJavaSurface.c ! prism-sw-native/src/JNativeSurface.c ! prism-sw/src/com/sun/pisces/AbstractSurface.java ! prism-sw/src/com/sun/pisces/JavaSurface.java ! prism-sw/src/com/sun/pisces/NativeSurface.java Changeset: 9f21025a5563 Author: jgodinez Date: 2013-03-12 09:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9f21025a5563 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-anim/src/com/sun/javafx/animation/TimingTarget.java - javafx-anim/src/com/sun/scenario/StandaloneAccessor.java - javafx-anim/src/com/sun/scenario/animation/FixedPulseTime.java - javafx-anim/src/com/sun/scenario/animation/MilliCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/NanoCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/shared/AnimationPulseReceiver.java - javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelopeFactory.java - javafx-anim/src/com/sun/scenario/animation/shared/CurrentTime.java - javafx-anim/test/unit/com/sun/scenario/ToolkitAccessorStub.java - javafx-anim/test/unit/com/sun/scenario/animation/shared/AnimationPulseReceiverTest.java Changeset: e784a2f6b6a3 Author: David Grieve Date: 2013-03-12 20:00 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e784a2f6b6a3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java From hang.vo at oracle.com Tue Mar 12 18:18:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 01:18:58 +0000 Subject: hg: openjfx/8/controls/rt: [TEST-ONLY] RT-21967 causes failures in URLTypeTest because leading / is stripped from url. Message-ID: <20130313011902.3BB72480CD@hg.openjdk.java.net> Changeset: f114202c0208 Author: David Grieve Date: 2013-03-12 21:16 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f114202c0208 [TEST-ONLY] RT-21967 causes failures in URLTypeTest because leading / is stripped from url. ! javafx-ui-common/test/unit/com/sun/javafx/css/URLTypeTest.java From hang.vo at oracle.com Tue Mar 12 18:34:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 01:34:01 +0000 Subject: hg: openjfx/8/controls/rt: 6 new changesets Message-ID: <20130313013421.1DD5D480D0@hg.openjdk.java.net> Changeset: 37f21ae48cbb Author: jgiles Date: 2013-03-12 13:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/37f21ae48cbb RT-28849: TableView has no way to clear the selection once one is made ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: d170f53e01db Author: jgiles Date: 2013-03-12 14:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d170f53e01db RT-28849: TableView has no way to clear the selection once one is made (Fix for TreeView) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 401883988dc0 Author: jgiles Date: 2013-03-13 11:23 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/401883988dc0 RT-28615: ListChangeListener on MultipleSelectionModel selectedItems does not always report correct item added. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java Changeset: 21ab95250f8f Author: jgiles Date: 2013-03-13 11:34 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/21ab95250f8f RT-28897: [TableView, TreeTableView] Column 'sortable' prop when disabled allows to sort column. ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java Changeset: e4029c52cf30 Author: jgiles Date: 2013-03-13 11:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e4029c52cf30 Enabling some ignored unit test classes. ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ChoiceBoxSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuBarSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuButtonSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ToolBarSkinTest.java Changeset: 5f1d2d1faa6d Author: jgiles Date: 2013-03-13 14:24 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5f1d2d1faa6d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From artem.ananiev at oracle.com Wed Mar 13 01:29:22 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 13 Mar 2013 12:29:22 +0400 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <1363116335.3303.110.camel@pegasus> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: <514038E2.8070400@oracle.com> On 3/12/2013 11:25 PM, Mario Torre wrote: > Anyway, back on the build, with OpenJDK 8 or Oracle JDK 8 EA and ant > 1.8.4 it fails with this weird message: > > master/rt/build.xml:87: The following error occurred while executing > this line: > master/rt/decora-runtime/build-common.xml:109: The following error > occurred while executing this line: > master/rt/decora-runtime/build-common.xml:24: Class not found: javac1.8 > > It seems that ant 1.9 is now required to compile OpenJFX, at least on > Linux. Does passing -Dbuild.compiler=javac1.7 to ant help? Thanks, Artem From hang.vo at oracle.com Wed Mar 13 02:18:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 09:18:54 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28718 Support permutation changes after add/remove changes in ObservableListBase Message-ID: <20130313091901.C4066480E3@hg.openjdk.java.net> Changeset: 5fe0d1ba95aa Author: Martin Sladecek Date: 2013-03-13 10:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5fe0d1ba95aa RT-28718 Support permutation changes after add/remove changes in ObservableListBase ! javafx-beans/src/javafx/collections/ListChangeBuilder.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java ! javafx-beans/test/javafx/collections/MockListObserver.java From hang.vo at oracle.com Wed Mar 13 02:33:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 09:33:51 +0000 Subject: hg: openjfx/8/graphics/rt: Dead code cleanup Message-ID: <20130313093358.7A9B9480E5@hg.openjdk.java.net> Changeset: abe7e78f8bad Author: Martin Sladecek Date: 2013-03-13 10:24 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/abe7e78f8bad Dead code cleanup ! javafx-beans/src/javafx/collections/ListChangeBuilder.java From neugens at redhat.com Wed Mar 13 02:53:10 2013 From: neugens at redhat.com (Mario Torre) Date: Wed, 13 Mar 2013 10:53:10 +0100 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <514038E2.8070400@oracle.com> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> <514038E2.8070400@oracle.com> Message-ID: <1363168390.3303.119.camel@pegasus> Il giorno mer, 13/03/2013 alle 12.29 +0400, Artem Ananiev ha scritto: > On 3/12/2013 11:25 PM, Mario Torre wrote: > > > Anyway, back on the build, with OpenJDK 8 or Oracle JDK 8 EA and ant > > 1.8.4 it fails with this weird message: > > > > master/rt/build.xml:87: The following error occurred while executing > > this line: > > master/rt/decora-runtime/build-common.xml:109: The following error > > occurred while executing this line: > > master/rt/decora-runtime/build-common.xml:24: Class not found: javac1.8 > > > > It seems that ant 1.9 is now required to compile OpenJFX, at least on > > Linux. > > Does passing -Dbuild.compiler=javac1.7 to ant help? Hi Artem, Thanks for the hint, this works indeed. Cheers, Mario From hang.vo at oracle.com Wed Mar 13 09:04:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 16:04:29 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28764 Ensemble8: use ConditionalFeature to decide what demos to show Message-ID: <20130313160435.A985D480EF@hg.openjdk.java.net> Changeset: f9de458279a2 Author: dmasada Date: 2013-03-13 08:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f9de458279a2 RT-28764 Ensemble8: use ConditionalFeature to decide what demos to show ! apps/samples/Ensemble8/src/app/ensemble/SampleCategory.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/ensemble/search/IndexSearcher.java + apps/samples/Ensemble8/src/app/ensemble/util/FeatureChecker.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/CodeGenerationUtils.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/Sample.java ! apps/samples/Ensemble8/src/generated/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/charts/bar/audio/AudioBarChartApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/advancedmedia/AdvancedMediaApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/audioclip/AudioClipApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/scenegraph/events/multitouch/MultiTouchApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/htmleditor/HTMLEditorApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/webview/WebViewApp.java From hang.vo at oracle.com Wed Mar 13 09:18:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 16:18:59 +0000 Subject: hg: openjfx/8/graphics/rt: 55 new changesets Message-ID: <20130313162153.A416C480F0@hg.openjdk.java.net> Changeset: 709356911e3a Author: "Jasper Potts" Date: 2013-03-06 11:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/709356911e3a Modena Test App: added sample naviagation and position rememebering ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/SamplePageNavigation.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 66330d32d59f Author: jgiles Date: 2013-03-06 12:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/66330d32d59f RT-27609: [TreeTableView] Scroll bar appears while there is enough space for rendering content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: ad7ab4d353c4 Author: jgiles Date: 2013-03-06 16:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ad7ab4d353c4 RT-28479: [TreeTableView] TreeTableColumn onEditCommit handler not called ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 0251aa01fc7c Author: jgiles Date: 2013-03-07 09:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0251aa01fc7c RT-28637: [ListView, TreeView, TableView, TreeTableView] selectionModel selectedItem returns wrong item. Tests were previously developed and have now been enabled. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 7fad68376811 Author: jgiles Date: 2013-03-07 09:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7fad68376811 Unit tests for RT-28819 ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java Changeset: 90ee146e03e5 Author: jgiles Date: 2013-03-07 12:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/90ee146e03e5 Fixes for failing unit tests related to RT-28637 and RT-21586 ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: 22bc48b746d4 Author: jgiles Date: 2013-03-07 12:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/22bc48b746d4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 9dd0e3c584b6 Author: "Jasper Potts" Date: 2013-03-06 16:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9dd0e3c584b6 Fixed RT-28843: TableView header overlaps TableView Border ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 4110414745eb Author: "Jasper Potts" Date: 2013-03-06 17:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4110414745eb Modena Fixed RT-28227: Modena: Table and TreeTable are not refined, Also fixed toolbar gradients for mid grey base colors. Consitant Checkbox sizing for font size changes. Medium text color tweek.Bunch of other CSS cleanup. Modena Test app added more tests for Table and TreeTables. ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/modena/SamplePageTreeTableHelper.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: fd5419fef373 Author: "Jasper Potts" Date: 2013-03-06 18:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fd5419fef373 Modena Test App added test case for RT-28410 ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java Changeset: 5cb29e82fed6 Author: "Jasper Potts" Date: 2013-03-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5cb29e82fed6 Intellij Project: Added Ensmeble 8 + apps/samples/Ensemble8/Ensemble8.iml Changeset: 180026bf2fca Author: "Jasper Potts" Date: 2013-03-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/180026bf2fca Modena: ComboBox menus were broken by yesterdays list view changes, fixed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: d79881867641 Author: "Jasper Potts" Date: 2013-03-07 17:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d79881867641 Fixed RT-28870:ProgressIndicator ignores padding and has no way to scale done tick mark ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 627e2260bc52 Author: Paru Somashekar Date: 2013-03-07 17:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/627e2260bc52 RT-13672 CategoryAxis diff animated property for diff constructors ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 53284fc129a4 Author: Paru Somashekar Date: 2013-03-07 17:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/53284fc129a4 RT-20110 StackedBarChart - stack does not move down on remove data ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java Changeset: a671a5f72fe9 Author: "Jasper Potts" Date: 2013-03-07 17:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a671a5f72fe9 Modena CSS, progress indicator indeterminate the SVG paths were too complex. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 67fbda7cbc0a Author: "Jasper Potts" Date: 2013-03-07 18:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/67fbda7cbc0a Fixed Modena Pagination to scale with ems. Also made pagination buttons smaller ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 65ab9f40d9ca Author: jgiles Date: 2013-03-08 15:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/65ab9f40d9ca Improved sorting APIs for TableView and TreeTableView, including: RT-17550: onSort event for TableColumn RT-19482: TableView: make sort() (or similar) methods public Also includes a number of new unit tests for the new API. ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java + javafx-ui-controls/src/javafx/scene/control/SortEvent.java ! javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java Changeset: 91f71d5a4918 Author: jgiles Date: 2013-03-08 15:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91f71d5a4918 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 3f60345c322a Author: David Grieve Date: 2013-03-07 22:47 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3f60345c322a RT-28635: if no style in current state, but there was a style in previous state, revert to initial value ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 81f83507079b Author: David Grieve Date: 2013-03-07 22:53 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/81f83507079b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 811c33cc3302 Author: David Grieve Date: 2013-03-08 10:44 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/811c33cc3302 RT-19089: reset property to initial value if no style and current value was set by css ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: 929a589c869f Author: David Grieve Date: 2013-03-08 15:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/929a589c869f RT-24516: simple cache for Images loaded from stylesheets. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/converters/PaintConverter.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java Changeset: 199a494a54e0 Author: David Grieve Date: 2013-03-08 16:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/199a494a54e0 RT-28888: conditions for setting LabeledText's text fill via -fx-fill did not work with RT-19089 fixes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: ffd70842a48d Author: David Grieve Date: 2013-03-08 16:43 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ffd70842a48d RT-28447: set popup window scene stylesheet to that of the owner window's scene ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: ddb3874aa103 Author: jgiles Date: 2013-03-11 15:09 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ddb3874aa103 RT-28893: ListView PlaceHolder is removed only after second item is added to item list Contributed-by: Sven Reimers Reviewed-by: jgiles ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java Changeset: 7680e1b9d790 Author: jgiles Date: 2013-03-11 15:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7680e1b9d790 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 1e8ef92fe45a Author: jgiles Date: 2013-03-11 15:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1e8ef92fe45a Re-enabling the keyboard input tests for ListView, TreeView, TableView and TreeTableView. Hopefully they don't bring the test infrastructure down again (either by failing on certain platforms or by causing OOME). In any case, if they fail to work they can be @Ignored again, but ideally they would be kept intact and running as they cover a lot of finicky keyboard interaction issues and will help prevent regressions (and I have to write a bunch more tests in the coming weeks for this area too). ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 02a668fbc3b6 Author: jgiles Date: 2013-03-11 15:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/02a668fbc3b6 Fixing a stack overflow issue in VirtualFlow that was identified by the keyboard navigation tests. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: fd29ff6315e7 Author: mickf Date: 2013-03-11 15:01 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fd29ff6315e7 RT-23427 : [ScrollBar] NPE in mouse event processing. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: ced0a6e6f8b4 Author: David Grieve Date: 2013-03-11 13:47 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ced0a6e6f8b4 RT-28292 [TEST-ONLY]: remove @Ignore from Node_effectiveOrientation_Css_Test and replace Toolkit.getToolkit().firePulse(); with root.impl_processCSS(true) ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: a7abdf74e155 Author: David Grieve Date: 2013-03-11 15:34 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a7abdf74e155 RT-28447: backout changeset ffd70842a48d. Causes issues with Modena ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: 36fcf9f812ed Author: David Grieve Date: 2013-03-11 15:38 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/36fcf9f812ed Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: 479e1c3e1371 Author: "Jasper Potts" Date: 2013-03-07 18:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/479e1c3e1371 Modena Progress Indicator default size was huge after last fix. Now fixed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 636b8f96d38a Author: "Jasper Potts" Date: 2013-03-11 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/636b8f96d38a Merge Changeset: c0cc2ab04805 Author: "Jasper Potts" Date: 2013-03-11 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c0cc2ab04805 Modena : Pagination added spacing between content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: b2461430c343 Author: David Grieve Date: 2013-03-11 17:23 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b2461430c343 RT-28447: set popup window scene stylesheet to that of the owner window's scene - this time with better checks on whether or not to clear style cache. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: d7a4237233a4 Author: "Jasper Potts" Date: 2013-03-11 14:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d7a4237233a4 Modena - tweek TableView sort arrows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 9d2b8b3fca1d Author: jgiles Date: 2013-03-12 11:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9d2b8b3fca1d RT-28891: 8.0-controls-scrum-404: Controls.TableView-Sort benchmark is broken ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 70b66196aea6 Author: jgiles Date: 2013-03-12 11:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/70b66196aea6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 316976bf4b3c Author: jgiles Date: 2013-03-12 12:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/316976bf4b3c RT-28898: [TableView, TreeTableView] When column 'sortable' is set to false the sort node doesn't disappear. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 283da31ead02 Author: jgiles Date: 2013-03-12 12:35 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/283da31ead02 Ignoring unit test based on change for RT-28891 ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: e4bdba51e3b6 Author: "Jasper Potts" Date: 2013-03-11 17:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e4bdba51e3b6 Modena: Tab Pane buttom tabs overflow arrow is not centered. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: c9d36dae8a70 Author: David Grieve Date: 2013-03-12 14:04 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c9d36dae8a70 RT-28907: CSS should only reset properites to initial values if there are no styles to apply to the node after an in-line style or stylesheet change ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: ad5cee5bfad6 Author: "Jasper Potts" Date: 2013-03-12 12:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ad5cee5bfad6 Fixed RT-28939: ScrollBar arrows are rendering with unexpected antialising ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 70612d9f2f28 Author: mo.chicharro Date: 2013-03-12 20:21 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/70612d9f2f28 Fix for RT-28506 - Create better icon svg for scrollbar arrows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 1ee809c26ddd Author: David Grieve Date: 2013-03-12 17:41 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1ee809c26ddd RT-21964: Insert null placeholder for stylesheet url when parsing. Substitute actual stylesheet url when declaration is added to the stylesheet ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: a0a297647a7c Author: "Jasper Potts" Date: 2013-03-12 14:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a0a297647a7c Modena: Fixed scroll arrow centered on TextArea and ScrollPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5634b086feaa Author: "Jasper Potts" Date: 2013-03-12 14:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5634b086feaa Merge Changeset: 50811c4425d8 Author: "Jasper Potts" Date: 2013-03-12 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50811c4425d8 Modena test app, added workaround for snapshot texture size limit. ! apps/experiments/Modena/src/modena/Modena.java Changeset: 6045e676948b Author: David Grieve Date: 2013-03-12 18:05 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6045e676948b RT-21967: if absolute path without a scheme, strip leading / before resolving URL. ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java Changeset: ecc8529fdc5b Author: David Grieve Date: 2013-03-12 18:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ecc8529fdc5b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: e784a2f6b6a3 Author: David Grieve Date: 2013-03-12 20:00 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e784a2f6b6a3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: f114202c0208 Author: David Grieve Date: 2013-03-12 21:16 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f114202c0208 [TEST-ONLY] RT-21967 causes failures in URLTypeTest because leading / is stripped from url. ! javafx-ui-common/test/unit/com/sun/javafx/css/URLTypeTest.java Changeset: e403dc5b195c Author: jgodinez Date: 2013-03-13 09:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e403dc5b195c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Wed Mar 13 09:48:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 16:48:37 +0000 Subject: hg: openjfx/8/graphics/rt: Updated gradle build to work on linux Message-ID: <20130313164840.C61C1480F3@hg.openjdk.java.net> Changeset: d1dbad1c94b9 Author: rbair Date: 2013-03-13 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d1dbad1c94b9 Updated gradle build to work on linux ! build.gradle From richard.bair at oracle.com Wed Mar 13 09:57:22 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 13 Mar 2013 09:57:22 -0700 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <1363116335.3303.110.camel@pegasus> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: > Is there a plan to eventually integration this code into the OpenJDK 8 > tree (like nashorn, for instance)? Not for a long time, probably Java 9 time at the earliest. >> I'm guessing you are on Linux? I have worked out windows & mac, about >> to start on the linux build. I'm guessing it dies on building native >> code? > > It seems that it fails with the :graphics:effects-jsl:compileBlend task. I just pushed a fix to graphics scrum and it compiles now for me on Linux. > But maybe I'm just doing something here, I'm not much of a gradle expert > yet. No, I'm just still fixing the gradle build, it isn't ready for production yet. > One final question, what other code is still needed to be open sourced? > I guess we're mostly done, right? We're getting close! Richard From phidias51 at gmail.com Wed Mar 13 10:24:21 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 13 Mar 2013 10:24:21 -0700 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: Hi Richard, I know you guys are busily opening up JavaFX, and I was wondering if there has been any effort to clean up the code? Not trying to critique the code, but some of the earlier code I saw wouldn't have passed minimal checkstyle settings. I recently had to delve into LineChart, and there were a number of missing comments on public methods, unnecessary "inheritDocs" tags on overridden methods, funky approaches to iterating through series data that only work within the charts package (can't be used by anyone extending the class), variables like "createSymbols" which are actually anonymous inner classes rather than a simple property. Also, do your automated builds run FindBugs or similar tools periodically? That might also help identify some problem spots before they escape out into the wild. Hmm. Well, I guess I did end up critiquing the code. When the code review tools come on line it will be easier to give you guys direct feedback on the classes, instead of heckling from the sidelines. :-) Cheers, Mark On Wed, Mar 13, 2013 at 9:57 AM, Richard Bair wrote: > > Is there a plan to eventually integration this code into the OpenJDK 8 > > tree (like nashorn, for instance)? > > Not for a long time, probably Java 9 time at the earliest. > > >> I'm guessing you are on Linux? I have worked out windows & mac, about > >> to start on the linux build. I'm guessing it dies on building native > >> code? > > > > It seems that it fails with the :graphics:effects-jsl:compileBlend task. > > I just pushed a fix to graphics scrum and it compiles now for me on Linux. > > > But maybe I'm just doing something here, I'm not much of a gradle expert > > yet. > > No, I'm just still fixing the gradle build, it isn't ready for production > yet. > > > One final question, what other code is still needed to be open sourced? > > I guess we're mostly done, right? > > We're getting close! > > Richard From richard.bair at oracle.com Wed Mar 13 10:43:51 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 13 Mar 2013 10:43:51 -0700 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: <05D763D8-F655-43B0-B287-6BDA9E6F4CC1@oracle.com> Hi Mark, > I know you guys are busily opening up JavaFX, and I was wondering if there has been any effort to clean up the code? Not trying to critique the code, but some of the earlier code I saw wouldn't have passed minimal checkstyle settings. Boy don't I know it! In my multi-step remediation plan, step 1 is to open source, step 2 is to fix the build, step 3 is to document the standards and get check style & find bugs integrated into the build and step 4 is to clean up a whole pile of stuff (much of which is more than cosmetic such as removing classes that are no longer needed and simplifying the code etc). We have had find bugs and check style around for ages but the build was such that we just didn't get it all properly integrated and used on a regular basis. This is something I want to change. We also need to document what the standards are on the wiki so that whenever there is a question we've got a document that we can go to. And IDE config files that everybody can use. Even simple things like making sure we use spaces instead of tabs. This has been a long-standing rule but people who start using Eclipse on Windows almost always end up committing change sets with tabs instead of spaces because that is the default setting, so having check style catch this before a push would be great. There are also a lot of idioms in our implementation that good check style / find bugs rules would help make sure we don't push bugs. So for example, I had one yesterday where an EventType suffered from a copy/paste bug which could have been caught by such tools. > I recently had to delve into LineChart, and there were a number of missing comments on public methods, unnecessary "inheritDocs" tags on overridden methods, funky approaches to iterating through series data that only work within the charts package (can't be used by anyone extending the class), variables like "createSymbols" which are actually anonymous inner classes rather than a simple property. > > Also, do your automated builds run FindBugs or similar tools periodically? That might also help identify some problem spots before they escape out into the wild. > > Hmm. Well, I guess I did end up critiquing the code. When the code review tools come on line it will be easier to give you guys direct feedback on the classes, instead of heckling from the sidelines. :-) Ya, and any change sets which you want to contribute which clean bits and pieces up (especially low-hanging fruit that is easy to verify doesn't change functionality) would be great. Richard From neugens at redhat.com Wed Mar 13 11:15:49 2013 From: neugens at redhat.com (Mario Torre) Date: Wed, 13 Mar 2013 19:15:49 +0100 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: <1363198549.3303.147.camel@pegasus> Il giorno mer, 13/03/2013 alle 10.24 -0700, Mark Fortner ha scritto: > Hmm. Well, I guess I did end up critiquing the code. When the code > review tools come on line it will be easier to give you guys direct > feedback on the classes, instead of heckling from the sidelines. :-) In OpenJDK land we did a cleanup warning day last year. This didn't become really a recurring occasion, but some nice folks (see Adopt OpenJDK) used this opportunity to create hack days on this topic, so the end result is that we see from time to time warning cleanups fixes here and there, which is wonderful. And for the more adventurous this also means code cleanup that can go over warnings fixes. I guess you actually just proposed to host some of those days :) Especially since I don't think we need to wait for Richard to propose us something to do, we can just start as well create some tasks ourselves where we see room for improvement. On the same subject, one thing I also would love to see is public reviews of all the code that is pushed in the repositories. @Richard, how does it work currently? Does each commit need to have a bug id on JIRA we can track? I think it would be great if we can follow the code from when it is developed rather than have just the code drop every couple of weeks, so we can participate at a deeper lever (which includes code reviews and whatnot). Cheers, Mario From phidias51 at gmail.com Wed Mar 13 11:31:48 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 13 Mar 2013 11:31:48 -0700 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> <513E607A.70103@oracle.com> Message-ID: The SymbolFactory idea should probably be discussed a little further. It would be useful if there was a simple Symbol interface that you could use. This would let you turn any Node subclass into a Symbol. public interface ISymbol{ Node getNode(); void setStyle(.....) void addEventHandler(....) void removeEventHandler(....) } The event handler methods would insure that the symbol can always respond to mouseover and click events (or any other events the user wants to support). The style method makes it easy to make the symbol pretty. The factory would then do something simple like: public interface ISymbolFactory { /** Get's a series specific symbol. */ ISymbol getSymbol(Series series, Data dataItem); } Inside the chart, the default implementation of the SymbolFactory could be an anonymous inner class or create an external implementation if you wanted it to serve as a template for users to extend and customize. You could pass new implementations of the SymbolFactory into the class in the constructor if you wanted to change the look. You'd want to do this before you actually started passing data to the chart, hence the idea of putting the factory in a constructor. Does that sound reasonable? Mark On Tue, Mar 12, 2013 at 3:01 AM, Sven Reimers wrote: > I like the idea of a symbol factory as well, but it will need to be in > some way configured per series, since a data item (XYChart.Data) does not > know about its series. > > Seems this may be a bigger API change though - Should we track this > separately? > > Any further comments? > > -Sven > > > > On Tue, Mar 12, 2013 at 12:33 AM, Jasper Potts wrote: > >> A symbol factory would also be a good idea, take in data item and return >> Node. >> >> Jasper >> >> On Mar 11, 2013, at 4:20 PM, Mark Fortner wrote: >> >> > I recently came across the "createSymbols" property code in the >> LineChart >> > and was wondering if there was some reason to write it this way rather >> than >> > simply having a default implementation of some Symbol interface which >> the >> > user can replace by simply setting the value. >> > >> > For my application, I ended up writing some conditional decorators for >> the >> > symbol, but as I was doing this I thought how much easier it would be if >> > the symbols had a factory where one could register new implementations, >> or >> > replace the factory itself to provide some conditional switching logic, >> etc. >> > >> > Any thoughts on improving the flexibility of the charts? >> > >> > Cheers, >> > >> > Mark >> > >> > >> > >> > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < >> > parvathi.somashekar at oracle.com> wrote: >> > >> >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the our >> plan >> >> of not adding the API at the Series level. >> >> >> >> thanks, >> >> Paru. >> >> >> >> On 3/11/13 3:25 PM, Jasper Potts wrote: >> >> >> >>> I feel like adding "createSymbols" boolean property to Area,& >> >>> StackedArea charts makes sense to match LineChart. >> >>> >> >>> >> >>> I don't like the idea of adding API to the series object on XYChart as >> >>> that is more generic and used by many chart types. If the user needs >> fine >> >>> grain control of symbols like in RT-21539 they can turn auto symbol >> >>> generation off with "createSymbols = false" then create their own >> symbol >> >>> nodes for the cases when they do want them. >> >>> >> >>> Thanks >> >>> >> >>> Jasper >> >>> >> >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar> >>> somashekar at oracle.com > wrote: >> >>> >> >>> There is a request for adding the createSymbols flag at the XYChart's >> >>>> Series level instead of on Chart. >> >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539< >> http://javafx-jira.kenai.com/browse/RT-21539> >> >>>> >> >>>> I think it might be a good idea to add it at the Series level so that >> >>>> one can turn ON / OFF symbols per Series rather than for all the >> series of >> >>>> a chart. >> >>>> The API could continue to be the same - except live at the Series >> level. >> >>>> Each chart can then create symbols for each of its Series only if >> this flag >> >>>> is turned on. >> >>>> This might however not make much sense for Scatter, Bubble and >> BarCharts. >> >>>> What do you think Jasper? >> >>>> >> >>>> -Paru. >> >>>> >> >>>> On 3/8/13 4:12 AM, Sven Reimers wrote: >> >>>> >> >>>>> Hi all >> >>>>> >> >>>>> AreaChart and StackedAreaChart are missing an API to simply disable >> the >> >>>>> creation of symbols. At the moment this is only possible by complex >> css >> >>>>> style acrobatics. LineChart on the other hand already provides a >> simple >> >>>>> way >> >>>>> to do this. The proposed tweak takes the existing API from >> LineChart and >> >>>>> adds this to AreaChart and StackedAreaChart. >> >>>>> >> >>>>> Desired API change: >> >>>>> >> >>>>> /** >> >>>>> * Indicates whether symbols for data points will be created or >> >>>>> not. >> >>>>> * >> >>>>> * @return true if symbols for data points will be created and >> >>>>> false >> >>>>> otherwise. >> >>>>> */ >> >>>>> public final boolean getCreateSymbols() { return >> >>>>> createSymbols.getValue(); } >> >>>>> public final void setCreateSymbols(boolean value) { >> >>>>> createSymbols.setValue(value); } >> >>>>> public final BooleanProperty createSymbolsProperty() { return >> >>>>> createSymbols; } >> >>>>> >> >>>>> Desired additional CSS property (incldues additional >> StyleableProperty): >> >>>>> >> >>>>> -fx-create-symbols >> >>>>> >> >>>>> >> >>>>> JIRA: >> >>>>> http://javafx-jira.kenai.com/**browse/RT-28148< >> http://javafx-jira.kenai.com/browse/RT-28148> >> >>>>> >> >>>>> Thank >> >>>>> >> >>>>> -Sven >> >>>>> >> >>>>> P.S. An updated patch will hopefully be available there too. >> >>>>> >> >>>>> >> >> >> >> > > > -- > 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 > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * 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 richard.bair at oracle.com Wed Mar 13 11:43:56 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 13 Mar 2013 11:43:56 -0700 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <1363198549.3303.147.camel@pegasus> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> <1363198549.3303.147.camel@pegasus> Message-ID: <18941B3E-5CF4-4141-83FF-A51949EFFB0F@oracle.com> > Especially since I don't think we need to wait for Richard to propose us > something to do, we can just start as well create some tasks ourselves > where we see room for improvement. +1 > On the same subject, one thing I also would love to see is public > reviews of all the code that is pushed in the repositories. > > @Richard, how does it work currently? Does each commit need to have a > bug id on JIRA we can track? I think it would be great if we can follow > the code from when it is developed rather than have just the code drop > every couple of weeks, so we can participate at a deeper lever (which > includes code reviews and whatnot). Each team has their own process. The graphics team has been closed source up until just recently and their code review process has involved web revs and their own mailing list. The controls team doesn't tend to do much in the way of code reviews. When I do something I usually just do the work and then let whoever owns the code do a quick review. In other words, it isn't regulated. At times what we've done is say "attach the web rev or patch to the issue" and then have the code review in the issue. What I really want of course is some modern UI such as bitbucket / github does where the entire history of the project is available + code reviews on patches and such. Richard From richard.bair at oracle.com Wed Mar 13 12:00:53 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 13 Mar 2013 12:00:53 -0700 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: <1363100858.3303.91.camel@pegasus> References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> Message-ID: <6A709722-D5F7-4BFD-84A0-52FEBD868987@oracle.com> I took the patch and ran the tests and everything looked OK so I went ahead and pushed it. Even so, let me know if you get to being able to do the tests yourself as well! I didn't do a performance test. Richard From hang.vo at oracle.com Wed Mar 13 12:04:25 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 19:04:25 +0000 Subject: hg: openjfx/8/controls/rt: RT-28945: not enough to reset to initial value on slowpath, must also reset on fastpath if css set the current value Message-ID: <20130313190438.3D368480FB@hg.openjdk.java.net> Changeset: 795697fbaa9e Author: David Grieve Date: 2013-03-13 15:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/795697fbaa9e RT-28945: not enough to reset to initial value on slowpath, must also reset on fastpath if css set the current value ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java From hang.vo at oracle.com Wed Mar 13 12:04:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 19:04:24 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130313190434.82107480FA@hg.openjdk.java.net> Changeset: d72a3b54194d Author: rbair Date: 2013-03-13 11:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d72a3b54194d [TEST-ONLY] Updated the test to use a local file instead of package.html because the new build system doesn't put javadoc files in the same places as class files, so this failed. ! javafx-ui-common/test/unit/com/sun/javafx/css/converters/URLConverterTest.java + javafx-ui-common/test/unit/com/sun/javafx/css/converters/some.txt Changeset: 4158528794cd Author: rbair Date: 2013-03-13 11:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4158528794cd RT-28886: Image URL_QUICKMATCH would be better as a cached Pattern Contributed By:neugens ! build.gradle ! javafx-ui-common/src/javafx/scene/image/Image.java From hang.vo at oracle.com Wed Mar 13 14:03:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 21:03:58 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130313210408.6174248101@hg.openjdk.java.net> Changeset: 61f4628db358 Author: Felipe Heidrich Date: 2013-03-13 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61f4628db358 [Eclipse only] adding xtext nature to rt project ! .project Changeset: 1c16ab0343bf Author: Felipe Heidrich Date: 2013-03-13 13:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1c16ab0343bf minor: fix double semicolon in css file ! apps/experiments/Modena/src/modena/TestApp.css From hang.vo at oracle.com Wed Mar 13 15:03:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 22:03:45 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130313220358.048C548107@hg.openjdk.java.net> Changeset: 2ca6c5e94163 Author: jgiles Date: 2013-03-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2ca6c5e94163 Cleanup some controls unit tests. ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/KeyModifier.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuBarSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: bd595da0dd6b Author: jgiles Date: 2013-03-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bd595da0dd6b Very early work on infrastructure for UI controls to better test mouse events (still incomplete) + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java Changeset: 86fbcdbb3e2e Author: jgiles Date: 2013-03-14 10:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/86fbcdbb3e2e Partial fix for RT-28684: [TreeTableView] When graphics is set to tree item the whole tree table row disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: adefcf226e92 Author: jgiles Date: 2013-03-14 10:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/adefcf226e92 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java From hang.vo at oracle.com Wed Mar 13 15:18:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 22:18:39 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28943 Use ConditionalFeatures instead of PlatformUtil.isEmbedded() Message-ID: <20130313221845.B177348109@hg.openjdk.java.net> Changeset: 4d82f948c42f Author: Daniel Blaukopf Date: 2013-03-13 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4d82f948c42f RT-28943 Use ConditionalFeatures instead of PlatformUtil.isEmbedded() ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Wed Mar 13 15:33:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 22:33:53 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed typo that broke the build Message-ID: <20130313223356.BD0154810B@hg.openjdk.java.net> Changeset: 88de15f1c7d9 Author: Daniel Blaukopf Date: 2013-03-13 15:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/88de15f1c7d9 Fixed typo that broke the build ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java From hang.vo at oracle.com Wed Mar 13 15:48:18 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Mar 2013 22:48:18 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28968: javafx-beans not being tested Message-ID: <20130313224821.906C74810F@hg.openjdk.java.net> Changeset: 7a3db91a4561 Author: rbair Date: 2013-03-13 15:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a3db91a4561 RT-28968: javafx-beans not being tested Summary: Now testing javafx-beans again. There were 4 failing tests which were ignored pursuant to a fix for RT-28969 ! javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java From tom.schindl at bestsolution.at Wed Mar 13 16:05:48 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 14 Mar 2013 00:05:48 +0100 Subject: Anybody looking for a quick patch to contribute? In-Reply-To: References: <92A853D8-6E6C-40B7-B5EF-99E42E2E25F0@oracle.com> <1363100858.3303.91.camel@pegasus> <1BDE40FD-A6E6-40C6-89AF-6ED286CD057A@oracle.com> <1363116335.3303.110.camel@pegasus> Message-ID: <5141064C.30907@bestsolution.at> Am 13.03.13 18:24, schrieb Mark Fortner: > Hi Richard, > I know you guys are busily opening up JavaFX, and I was wondering if there > has been any effort to clean up the code? Not trying to critique the code, > but some of the earlier code I saw wouldn't have passed minimal checkstyle > settings. I cleaned up already some parts of the control classes - Jonathan applied fairly all patches, I provided. It is a bit cumbersome because we are still not allowed to attach patches to JIRA. > > I recently had to delve into LineChart, and there were a number of missing > comments on public methods, unnecessary "inheritDocs" tags on overridden > methods, funky approaches to iterating through series data that only work > within the charts package (can't be used by anyone extending the class), > variables like "createSymbols" which are actually anonymous inner classes > rather than a simple property. There's is already a discussion between Richard and me why inner-classes are used when there is Simple*Property available in the mailing list archive. It is a trading between static (inner-classes) and dynamic footprint (Simple*Property) Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From phdoerfler at gmail.com Wed Mar 13 16:35:37 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 14 Mar 2013 00:35:37 +0100 Subject: Change existing controls or create new ones? Message-ID: <9E10C53D-B91E-443D-9612-0E6787CD59B4@gmail.com> Hi, the question might benefit from a short example: Some days ago I created a prototype of a TabPane [1] and then tried to achieve the same look by styling the already existing TabPane with CSS. The latter was not quite as successful, though [2] but I did not have the time to investigate much further. I know that it is possible to adjust the .tab-header-area's dimensions with CSS but as the dimensions of that header does not seem to obey the boundaries of the rotated tab, I would have to manage the tab-header-area's height (or width that is) manually. The underlying problem here is that the JavaFX layout managers do in general not account for transforms, so scaling, rotations and translations result in the node crossing the container's boundaries. I do not want to question whether this is "expected behavior" or not - I assume there are good reasons for the way it is implemented right now (and be it only the possibility of 3D transformations - and how should those be handled by container panes?). No, my actual question is: What is the preferred way to achieve a reusable TabPane which looks like [1]? Should one try to style the existing one using CSS and Skins or is it better to create a control like this from scratch? Just assuming the first were possible in this example (and it probably is), here are some quick pros and cons. I'd be happy if you could contribute some of your own: Style existing controls: - Better support for assistive technologies, screen readers (it's a TabPane, we already know how it works) - => more semantical information - already implemented functionality Start from scratch: - Greater flexibility in creating the visuals (wild guess - I have not bothered trying Skin myself, yet) - no functionality implemented - you have to do every single thing yourself - less semantical information (the screen reader or automation software does not know how a CustomFancyTabPane works) Might someone who has a deeper understanding of controls shed some light on these questions, please? Oh and - those reasons for not taking transformations into account... I'd be interested in them, too. Cheers, ~ Philipp [1] https://twitter.com/phdoerfler/status/308361970611023873/photo/1 [2] http://cl.ly/image/300M0q3k2u38 From jonathan.giles at oracle.com Wed Mar 13 17:06:14 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 14 Mar 2013 13:06:14 +1300 Subject: Change existing controls or create new ones? In-Reply-To: <9E10C53D-B91E-443D-9612-0E6787CD59B4@gmail.com> References: <9E10C53D-B91E-443D-9612-0E6787CD59B4@gmail.com> Message-ID: <51411476.7050307@oracle.com> Good questions. I'll do my best to answer them quickly now. Regarding the transformations and their lack of inclusion in layout: the reason for this is that more often than not a transformation is a temporary thing (for example a rotation / glow / drop shadow on mouse hover), and it is not desirable that the layout of your user interface be impacted by these transformations / effects (imagine a wide but short rotating rectangle node pushing / pulling all nodes around it as it goes through its 360 degree rotation). However, in saying this, if you do want your layout to be impacted by these transformations / effects the solution is simple: you wrap your Node in a Group, and place that Group in your scenegraph. To slightly deep dive (and I hope I'm right here - it's been a while since I've had to explain this), a Node has a few different layout bounds. The two most relevant to layout are 'layoutBounds' and 'boundsInParent'. The layoutBounds is actually what is used to determine sizes / positions of nodes in a layout, but this does not include transformations / effects. These impact the boundsInParent instead. The thing a Group does is gather together the boundsInParent of all of its children and make that its layoutBounds. This is why placing a Node with transformed boundsInParent will be used if you wrap it in a Group. Switching to custom controls / customised controls, in general the recommended advice depends on the requirements and availability of a suitable control to base customisations on. I would say the best general advice is to firstly try getting the look you want by just modifying CSS on a custom control. If this works then you're great and can stop. If this doesn't work then you could consider either extending or developing a custom Skin for the control, but this brings with it an expectation that you will support all API from the control class (which is often a big ask). One piece of advice I always give when I do conference sessions on custom controls is that you _do not_ have to build UI controls by doing it the way we do it in the UI controls team (that is by extending Control, SkinBase, etc). The only reason why you would do this is if you want to ensure maximum ease of distribution to third parties and the highest level of CSS skinning opportunities (but in saying that I don't think it is much greater than simply doing it the way I normally recommend, which is to extend Region and throw together your UI by adding children to the Region node). I hope that makes some degree of sense... -- Jonathan On 14/03/2013 12:35 p.m., Philipp D?rfler wrote: > Hi, > > the question might benefit from a short example: > Some days ago I created a prototype of a TabPane [1] and then tried to achieve the same look by styling the already existing TabPane with CSS. The latter was not quite as successful, though [2] but I did not have the time to investigate much further. I know that it is possible to adjust the .tab-header-area's dimensions with CSS but as the dimensions of that header does not seem to obey the boundaries of the rotated tab, I would have to manage the tab-header-area's height (or width that is) manually. > > The underlying problem here is that the JavaFX layout managers do in general not account for transforms, so scaling, rotations and translations result in the node crossing the container's boundaries. > I do not want to question whether this is "expected behavior" or not - I assume there are good reasons for the way it is implemented right now (and be it only the possibility of 3D transformations - and how should those be handled by container panes?). > No, my actual question is: > > What is the preferred way to achieve a reusable TabPane which looks like [1]? Should one try to style the existing one using CSS and Skins or is it better to create a control like this from scratch? Just assuming the first were possible in this example (and it probably is), here are some quick pros and cons. I'd be happy if you could contribute some of your own: > > Style existing controls: > - Better support for assistive technologies, screen readers (it's a TabPane, we already know how it works) > - => more semantical information > - already implemented functionality > > Start from scratch: > - Greater flexibility in creating the visuals (wild guess - I have not bothered trying Skin myself, yet) > - no functionality implemented - you have to do every single thing yourself > - less semantical information (the screen reader or automation software does not know how a CustomFancyTabPane works) > > Might someone who has a deeper understanding of controls shed some light on these questions, please? > Oh and - those reasons for not taking transformations into account... I'd be interested in them, too. > > Cheers, > ~ Philipp > > [1] https://twitter.com/phdoerfler/status/308361970611023873/photo/1 > [2] http://cl.ly/image/300M0q3k2u38 From John_Smith at symantec.com Wed Mar 13 17:55:16 2013 From: John_Smith at symantec.com (John Smith) Date: Wed, 13 Mar 2013 17:55:16 -0700 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> <513E607A.70103@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D2216783984C8@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> There are symbols in legends, which don't have data items and sometimes users want these symbols styled differently from symbols marking data points in charts. Mark, in your proposal, would you invoke something like the code below to get the legend symbol for a series? ISymbol legendSymbolForSeries1 = factory.getSymbol(series1, null); Also, on style, is there a precedence for prefixing interface names with I in the JavaFX code? --------- I do like the idea of some kind of factory mechanism to customize chart symbols. There have been numerous questions on forums related to chart symbol (and legend and line) customization. https://forums.oracle.com/forums/thread.jspa?threadID=2411524 "How to remove symbols from an AreaChart in JavaFX" https://forums.oracle.com/forums/thread.jspa?messageID=9697930 "Create onMouseClickEvent on Symbol of the chart" https://forums.oracle.com/forums/thread.jspa?messageID=10145108 "How to customize line chart series and symbols?" https://forums.oracle.com/forums/thread.jspa?messageID=10013764 "Pie Chart and legend symbols" https://forums.oracle.com/forums/thread.jspa?messageID=1063034 "Toggle the visibility of a single series with symbols" https://forums.oracle.com/forums/thread.jspa?messageID=10286441 "Coloring the legend" https://forums.oracle.com/forums/thread.jspa?messageID=10598795 "Display Tooltips on charts values?" https://forums.oracle.com/forums/thread.jspa?messageID=10680210 "Creating a table within the actual Chart" http://stackoverflow.com/questions/11949891/javafx2-linechart-symbols-and-css "LineChart symbols and CSS" http://stackoverflow.com/questions/12287484/controlling-symbols-etc-in-linecharts-inline-programmatically "Controlling symbols, etc. in lineCharts inline programmatically" http://stackoverflow.com/questions/12622709/javafx-2-0-how-to-change-legend-color-of-a-linechart-dynamically "How to change legend color of a LineChart dynamically?" http://stackoverflow.com/questions/9757848/how-to-dynamically-change-line-style-in-javafx-2-0-line-chart "How to dynamically change line style in JavaFX 2.0 line chart?" http://stackoverflow.com/questions/15237192/how-to-display-bar-value-on-top-of-bar-javafx "how to display bar value on top of bar javafx" People do have difficulties trying to get charts to look and work the way they want. It's somewhat understandable because there are a million different ways you can imagine charts to look and data to be represented, so they tend to be pretty heavily customized. All of the above questions were answerable using the current public API (mostly before the code was open sourced). JavaFX is flexible enough that you can get it to do pretty much anything with a fairly minimal API, but knowing a few tricks such as lookup by css selector, helps in customizing complex hierarchical nodes like charts (in the absence of easily discoverable public api). I guess, the good news from this is that JavaFX charts is a feature that gets some usage. It's also a nice library and one of the reason people use it is that the default charts look nice - fresh and clean. In terms of stuff that people struggle with, it would probably be (in decreasing order of precedence): Concurrency, Tables, Custom charts, Working out why javafx is not on the classpath, Deployment, Dialogs, Layout, Reusing nodes in the scene graph -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Wednesday, March 13, 2013 11:32 AM To: Sven Reimers Cc: openjfx-dev at openjdk.java.net Subject: Re: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart The SymbolFactory idea should probably be discussed a little further. It would be useful if there was a simple Symbol interface that you could use. This would let you turn any Node subclass into a Symbol. public interface ISymbol{ Node getNode(); void setStyle(.....) void addEventHandler(....) void removeEventHandler(....) } The event handler methods would insure that the symbol can always respond to mouseover and click events (or any other events the user wants to support). The style method makes it easy to make the symbol pretty. The factory would then do something simple like: public interface ISymbolFactory { /** Get's a series specific symbol. */ ISymbol getSymbol(Series series, Data dataItem); } Inside the chart, the default implementation of the SymbolFactory could be an anonymous inner class or create an external implementation if you wanted it to serve as a template for users to extend and customize. You could pass new implementations of the SymbolFactory into the class in the constructor if you wanted to change the look. You'd want to do this before you actually started passing data to the chart, hence the idea of putting the factory in a constructor. Does that sound reasonable? Mark On Tue, Mar 12, 2013 at 3:01 AM, Sven Reimers wrote: > I like the idea of a symbol factory as well, but it will need to be in > some way configured per series, since a data item (XYChart.Data) does > not know about its series. > > Seems this may be a bigger API change though - Should we track this > separately? > > Any further comments? > > -Sven > > > > On Tue, Mar 12, 2013 at 12:33 AM, Jasper Potts wrote: > >> A symbol factory would also be a good idea, take in data item and >> return Node. >> >> Jasper >> >> On Mar 11, 2013, at 4:20 PM, Mark Fortner wrote: >> >> > I recently came across the "createSymbols" property code in the >> LineChart >> > and was wondering if there was some reason to write it this way >> > rather >> than >> > simply having a default implementation of some Symbol interface >> > which >> the >> > user can replace by simply setting the value. >> > >> > For my application, I ended up writing some conditional decorators >> > for >> the >> > symbol, but as I was doing this I thought how much easier it would >> > be if the symbols had a factory where one could register new >> > implementations, >> or >> > replace the factory itself to provide some conditional switching >> > logic, >> etc. >> > >> > Any thoughts on improving the flexibility of the charts? >> > >> > Cheers, >> > >> > Mark >> > >> > >> > >> > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < >> > parvathi.somashekar at oracle.com> wrote: >> > >> >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the >> >> our >> plan >> >> of not adding the API at the Series level. >> >> >> >> thanks, >> >> Paru. >> >> >> >> On 3/11/13 3:25 PM, Jasper Potts wrote: >> >> >> >>> I feel like adding "createSymbols" boolean property to Area,& >> >>> StackedArea charts makes sense to match LineChart. >> >>> >> >>> >> >>> I don't like the idea of adding API to the series object on >> >>> XYChart as that is more generic and used by many chart types. If >> >>> the user needs >> fine >> >>> grain control of symbols like in RT-21539 they can turn auto >> >>> symbol generation off with "createSymbols = false" then create >> >>> their own >> symbol >> >>> nodes for the cases when they do want them. >> >>> >> >>> Thanks >> >>> >> >>> Jasper >> >>> >> >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar> >>> somashekar at oracle.com > wrote: >> >>> >> >>> There is a request for adding the createSymbols flag at the >> >>> XYChart's >> >>>> Series level instead of on Chart. >> >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539< >> http://javafx-jira.kenai.com/browse/RT-21539> >> >>>> >> >>>> I think it might be a good idea to add it at the Series level so >> >>>> that one can turn ON / OFF symbols per Series rather than for >> >>>> all the >> series of >> >>>> a chart. >> >>>> The API could continue to be the same - except live at the >> >>>> Series >> level. >> >>>> Each chart can then create symbols for each of its Series only >> >>>> if >> this flag >> >>>> is turned on. >> >>>> This might however not make much sense for Scatter, Bubble and >> BarCharts. >> >>>> What do you think Jasper? >> >>>> >> >>>> -Paru. >> >>>> >> >>>> On 3/8/13 4:12 AM, Sven Reimers wrote: >> >>>> >> >>>>> Hi all >> >>>>> >> >>>>> AreaChart and StackedAreaChart are missing an API to simply >> >>>>> disable >> the >> >>>>> creation of symbols. At the moment this is only possible by >> >>>>> complex >> css >> >>>>> style acrobatics. LineChart on the other hand already provides >> >>>>> a >> simple >> >>>>> way >> >>>>> to do this. The proposed tweak takes the existing API from >> LineChart and >> >>>>> adds this to AreaChart and StackedAreaChart. >> >>>>> >> >>>>> Desired API change: >> >>>>> >> >>>>> /** >> >>>>> * Indicates whether symbols for data points will be >> >>>>> created or not. >> >>>>> * >> >>>>> * @return true if symbols for data points will be created >> >>>>> and false otherwise. >> >>>>> */ >> >>>>> public final boolean getCreateSymbols() { return >> >>>>> createSymbols.getValue(); } >> >>>>> public final void setCreateSymbols(boolean value) { >> >>>>> createSymbols.setValue(value); } >> >>>>> public final BooleanProperty createSymbolsProperty() { >> >>>>> return createSymbols; } >> >>>>> >> >>>>> Desired additional CSS property (incldues additional >> StyleableProperty): >> >>>>> >> >>>>> -fx-create-symbols >> >>>>> >> >>>>> >> >>>>> JIRA: >> >>>>> http://javafx-jira.kenai.com/**browse/RT-28148< >> http://javafx-jira.kenai.com/browse/RT-28148> >> >>>>> >> >>>>> Thank >> >>>>> >> >>>>> -Sven >> >>>>> >> >>>>> P.S. An updated patch will hopefully be available there too. >> >>>>> >> >>>>> >> >> >> >> > > > -- > 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 > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * 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 danno.ferrin at shemnon.com Wed Mar 13 18:23:29 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Wed, 13 Mar 2013 19:23:29 -0600 Subject: SimpleStyleableProperties API Questions Message-ID: So I am getting around to porting my style code for my deck control to JDK8, and I ran across the SimpleStyleableProperty family of objects, and I have a couple of questions/crutiques 1. Why is it marked abstract? The docs claim that StyleableProperty#getCssMetaData() is not implemented and you have to do it, and yet not only is it implemented it is final, and you cannot override it! There are no abstract methods, so the abstract modifier could easily be removed. 2. Why does it extend from SimpleProperty instead of StyleableProperty? Just an implementation convenience? I think it would be more valuable to extend from the Styleable property than the Simple property, since simple only adds implementation but styleable adds implementation for a new interface. I see myself adding more StyleableDoubleProperties that are backed by a Simple varient than a SimpleDoubleProperty backed by the styleable varient. Is it too late in the game to make these API changes? -- Danno Ferrin From hang.vo at oracle.com Wed Mar 13 18:34:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 01:34:00 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130314013412.C341648116@hg.openjdk.java.net> Changeset: 5f51d88810cd Author: jgiles Date: 2013-03-14 14:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5f51d88810cd RT-23129: Memory Leak in (Context)Menu ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java Changeset: 4f803bb7ab77 Author: jgiles Date: 2013-03-14 14:27 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4f803bb7ab77 Further unit testing infrastructure explorations + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/ContextMenuEventFirer.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java From hang.vo at oracle.com Wed Mar 13 18:48:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 01:48:35 +0000 Subject: hg: openjfx/8/controls/rt: RT-23129: Memory Leak in (Context)Menu (Fix for NPE) Message-ID: <20130314014838.BF42248117@hg.openjdk.java.net> Changeset: 282078cff182 Author: jgiles Date: 2013-03-14 14:34 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/282078cff182 RT-23129: Memory Leak in (Context)Menu (Fix for NPE) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java From alexander.kouznetsov at oracle.com Wed Mar 13 19:00:30 2013 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Wed, 13 Mar 2013 19:00:30 -0700 Subject: API REVIEW Axis label property In-Reply-To: <2389A223-FD14-4F63-9A32-3DD47DBB662D@oracle.com> References: <512294B4.6000101@oracle.com> <2389A223-FD14-4F63-9A32-3DD47DBB662D@oracle.com> Message-ID: <51412F3E.3050007@oracle.com> Richard, What's the state of this API review? Best regards, Alexander Kouznetsov (408) 276-0387 On 18.02.2013 13:34, Richard Bair wrote: > I've added the api-review label. This is very likely to not be approved, as we are not allowing binary incompatible changes unless they are of the most serious nature, and this one doesn't appear to fit that criteria. > > Richard > > On Feb 18, 2013, at 12:53 PM, Paru Somashekar wrote: > >> JIRA : http://javafx-jira.kenai.com/browse/RT-28151 >> >> As the JIRA indicates, it is a simple change to use StringProperty for the axis label instead of ObjectProperty. This is a breaking API change - however the likelihood is minimal, as both ObjectProperty and StringProperty implement a lot of the same interfaces. >> As the JIRA notes, this is not consistent with the rest of the Charts API, where StringProperty is used instead of ObjectProperty, hence the need to fix it. >> >> thanks, >> Paru. From david.grieve at oracle.com Wed Mar 13 19:38:52 2013 From: david.grieve at oracle.com (David Grieve) Date: Wed, 13 Mar 2013 22:38:52 -0400 Subject: SimpleStyleableProperties API Questions In-Reply-To: References: Message-ID: <00BAE2BF-8812-4E84-9620-666B687B6BAC@oracle.com> On Mar 13, 2013, at 9:23 PM, Danno Ferrin wrote: > So I am getting around to porting my style code for my deck control to > JDK8, and I ran across the SimpleStyleableProperty family of objects, > and I have a couple of questions/crutiques > > > 1. Why is it marked abstract? The docs claim > that StyleableProperty#getCssMetaData() is not implemented and you have to > do it, and yet not only is it implemented it is final, and you cannot > override it! There are no abstract methods, so the abstract modifier could > easily be removed. Doh! Just an oversight. I'm glad you found it! I'll file a bug for it. > > 2. Why does it extend from SimpleProperty instead of > StyleableProperty? Just an implementation convenience? I think it > would be more valuable to extend from the Styleable property than the > Simple property, since simple only adds implementation but styleable adds > implementation for a new interface. I see myself adding more > StyleableDoubleProperties that are backed by a Simple varient than a > SimpleDoubleProperty backed by the styleable variant. > Because we want SimpleStyleableProperty to be a SimpleProperty _and_ a StyleableProperty. It is the only way to do it since SimpleProperty is a class and StyleableProperty is an interface. To do it the other way around would require that the SimpleStyleableProperty re-implement the entire SimpleProperty API - PropertyBase, Property, ReadOnlyProperty and so on. I can understand that you want to be able to do 'StyleableDoubleProperty foo = new SimpleStyleableDoubleProperty(FOO);' But you can do 'StyleableProperty foo = new SimpleStyleableDoubleProperty(FOO);' > Is it too late in the game to make these API changes? > -- > Danno Ferrin From hang.vo at oracle.com Wed Mar 13 20:48:20 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 03:48:20 +0000 Subject: hg: openjfx/8/controls/rt: RT-23129: Memory Leak in (Context)Menu (Fix for silly code typo found by Scott Palmer, also other slight optimisations) Message-ID: <20130314034827.4145C48120@hg.openjdk.java.net> Changeset: ff5b5435295a Author: jgiles Date: 2013-03-14 16:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ff5b5435295a RT-23129: Memory Leak in (Context)Menu (Fix for silly code typo found by Scott Palmer, also other slight optimisations) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java From hang.vo at oracle.com Wed Mar 13 23:18:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 06:18:36 +0000 Subject: hg: openjfx/8/controls/rt: RT-28678: [TreeView] graphics is not rendered immediately. Message-ID: <20130314061840.9985E48126@hg.openjdk.java.net> Changeset: e1871684b3ae Author: jgiles Date: 2013-03-14 18:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e1871684b3ae RT-28678: [TreeView] graphics is not rendered immediately. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java From hang.vo at oracle.com Thu Mar 14 02:34:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 09:34:33 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed javafx collections tests + minor code fix that was found after tests were fixed. Message-ID: <20130314093443.2DED44812D@hg.openjdk.java.net> Changeset: 3d3dd969e631 Author: Martin Sladecek Date: 2013-03-14 10:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3d3dd969e631 Fixed javafx collections tests + minor code fix that was found after tests were fixed. ! javafx-beans/src/com/sun/javafx/collections/VetoableListDecorator.java ! javafx-beans/src/javafx/collections/ListChangeListener.java ! javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java ! javafx-beans/test/javafx/collections/MockListObserver.java From hang.vo at oracle.com Thu Mar 14 06:04:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 13:04:36 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130314130447.60F6048133@hg.openjdk.java.net> Changeset: 4d5247c56a5d Author: Petr Pchelko Date: 2013-03-14 16:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4d5247c56a5d RT-24453 Mac: ComboBox, ChoiceBox, ListView when selected cause NetBeans RCP Application menubar to disappear Reviewed-by: Anthony ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassSystemMenu.java Changeset: de3ebe903c58 Author: Petr Pchelko Date: 2013-03-14 17:04 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/de3ebe903c58 RT-28542 cancelling DirectoryChooser selection leads to NPE Reviewed-by: Anthony ! glass/glass/src/com/sun/glass/ui/gtk/GtkCommonDialogs.java ! glass/glass/src/com/sun/glass/ui/win/WinCommonDialogs.java From danno.ferrin at shemnon.com Thu Mar 14 07:15:08 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 14 Mar 2013 08:15:08 -0600 Subject: SimpleStyleableProperties API Questions In-Reply-To: <00BAE2BF-8812-4E84-9620-666B687B6BAC@oracle.com> References: <00BAE2BF-8812-4E84-9620-666B687B6BAC@oracle.com> Message-ID: > > > 2. Why does it extend from SimpleProperty instead of > > StyleableProperty? Just an implementation convenience? I think it > > would be more valuable to extend from the Styleable property than the > > Simple property, since simple only adds implementation but styleable adds > > implementation for a new interface. I see myself adding more > > StyleableDoubleProperties that are backed by a Simple varient than a > > SimpleDoubleProperty backed by the styleable variant. > > > > Because we want SimpleStyleableProperty to be a SimpleProperty > _and_ a StyleableProperty. It is the only way to do it since > SimpleProperty is a class and StyleableProperty is an interface. To do > it the other way around would require that the SimpleStyleableProperty > re-implement the entire SimpleProperty API - PropertyBase, > Property, ReadOnlyProperty and so on. > > I can understand that you want to be able to do 'StyleableDoubleProperty > foo = new SimpleStyleableDoubleProperty(FOO);' But you can do > 'StyleableProperty foo = new SimpleStyleableDoubleProperty(FOO);' > > I want it to be a SimplePorperty and a StyleableProperty, you missed the on the styleable, very important. Both of these classes derive from PropertyBase, so they both save a lot of overhead there. It is the implementation in the specialization where the horse trading occurs. The implementation overhead for SimpleProperty is 3 one-line constructors, two fields, and two one line methods for those fields. The implementation overhead for SimpleStyleableProperty is 4 constructors, 5 methods, and a total of 8 lines, and two fields. Really slightly more code duplication and work is being done for the current hierarchy. -- Danno From david.hill at oracle.com Thu Mar 14 07:21:06 2013 From: david.hill at oracle.com (david.hill at oracle.com) Date: Thu, 14 Mar 2013 14:21:06 +0000 Subject: hg: openjfx/8/controls: Tweaking Raspberry PI cross build. Message-ID: <20130314142106.6C5C748138@hg.openjdk.java.net> Changeset: 65f9877c4557 Author: David Hill Date: 2013-03-14 10:18 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rev/65f9877c4557 Tweaking Raspberry PI cross build. ! build-src/build-os-arch.xml + build-src/platform/on-raspberry-pi.properties ! build-src/platform/raspberry-pi.properties From david.hill at oracle.com Thu Mar 14 07:21:46 2013 From: david.hill at oracle.com (david.hill at oracle.com) Date: Thu, 14 Mar 2013 14:21:46 +0000 Subject: hg: openjfx/8/master: Tweaking Raspberry PI cross build. Message-ID: <20130314142146.3648148139@hg.openjdk.java.net> Changeset: 65f9877c4557 Author: David Hill Date: 2013-03-14 10:18 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rev/65f9877c4557 Tweaking Raspberry PI cross build. ! build-src/build-os-arch.xml + build-src/platform/on-raspberry-pi.properties ! build-src/platform/raspberry-pi.properties From hang.vo at oracle.com Thu Mar 14 07:33:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 14:33:42 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26547: Scenegraph doesn't handle null values passed for enum arguments (and other values) Message-ID: <20130314143349.0C6C64813C@hg.openjdk.java.net> Changeset: c2e2112b523c Author: Eva Krejcirova Date: 2013-03-14 15:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c2e2112b523c RT-26547: Scenegraph doesn't handle null values passed for enum arguments (and other values) ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/DropShadow.java ! javafx-ui-common/src/javafx/scene/effect/InnerShadow.java ! javafx-ui-common/src/javafx/scene/effect/Light.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java ! javafx-ui-common/src/javafx/scene/effect/Shadow.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Arc.java ! javafx-ui-common/test/unit/javafx/scene/effect/ColorInputTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DisplacementMapTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DistantLightTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DropShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/InnerShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/LightingTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/ShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageViewTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/FlowPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/HBoxTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/StackPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/VBoxTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ArcTest.java From david.hill at oracle.com Thu Mar 14 07:19:24 2013 From: david.hill at oracle.com (david.hill at oracle.com) Date: Thu, 14 Mar 2013 14:19:24 +0000 Subject: hg: openjfx/8/graphics: Tweaking Raspberry PI cross build. Message-ID: <20130314141924.ED26248136@hg.openjdk.java.net> Changeset: 65f9877c4557 Author: David Hill Date: 2013-03-14 10:18 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rev/65f9877c4557 Tweaking Raspberry PI cross build. ! build-src/build-os-arch.xml + build-src/platform/on-raspberry-pi.properties ! build-src/platform/raspberry-pi.properties From sven.reimers at gmail.com Thu Mar 14 07:40:59 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 14 Mar 2013 15:40:59 +0100 Subject: [API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart In-Reply-To: References: <513A2909.9070204@oracle.com> <9D7A729E-9A19-4285-824F-8538CEB0D79F@oracle.com> <513E607A.70103@oracle.com> Message-ID: My 2$c.. I do not like the idea of having additional Symbol objects - thinking of large datasets this sounds like a significant overhead in cpu and memory. I would prefer public interface SymbolFactory { /** Get's a series specific symbol. */ Node getSymbol(Series series, Data dataItem); } On the other hand - do we want one factory per series? The proposed api would allow for different symbols for the same series. Do we want to support this? As with allmost all things in JavaFX I would say this could be a property that you can change, and with this the generated symbols change (maybe not used that much, but consistent non the less). Passing the factory in a constructor is not good for fxml and other rapid things who like the builder approach. So we should try to keep this out of the constructor and make it accessible via a property or at least a set method. This still looks like more discussion is needed for such an API change, which does not replace my original API-Review request. I think having simple facility to switch symbols on /off is a change small enough and independent of this bigger discussion about general further enhancements of the charts API, which may be too late for FX8, while the small change maybe still has a chance of getting into FX8. So, please let us discuss this in a separate thread and keep the discussion here focussed on the original change. -Sven P.S.Perhaps we can take try to separate things we need in FX standard API's from things that may be nice to have, but can be implemented as extensions to the existing charts and provided by a project like jfxtras.org. On Wed, Mar 13, 2013 at 7:31 PM, Mark Fortner wrote: > The SymbolFactory idea should probably be discussed a little further. > > It would be useful if there was a simple Symbol interface that you could > use. This would let you turn any Node subclass into a Symbol. > > public interface ISymbol{ > > Node getNode(); > void setStyle(.....) > void addEventHandler(....) > void removeEventHandler(....) > > } > > The event handler methods would insure that the symbol can always respond > to mouseover and click events (or any other events the user wants to > support). The style method makes it easy to make the symbol pretty. > > The factory would then do something simple like: > > public interface ISymbolFactory { > > /** Get's a series specific symbol. */ > ISymbol getSymbol(Series series, Data dataItem); > > } > > > Inside the chart, the default implementation of the SymbolFactory could be > an anonymous inner class or create an external implementation if you wanted > it to serve as a template for users to extend and customize. You could > pass new implementations of the SymbolFactory into the class in the > constructor if you wanted to change the look. You'd want to do this before > you actually started passing data to the chart, hence the idea of putting > the factory in a constructor. > > Does that sound reasonable? > > > Mark > > > > On Tue, Mar 12, 2013 at 3:01 AM, Sven Reimers wrote: > >> I like the idea of a symbol factory as well, but it will need to be in >> some way configured per series, since a data item (XYChart.Data) does not >> know about its series. >> >> Seems this may be a bigger API change though - Should we track this >> separately? >> >> Any further comments? >> >> -Sven >> >> >> >> On Tue, Mar 12, 2013 at 12:33 AM, Jasper Potts wrote: >> >>> A symbol factory would also be a good idea, take in data item and return >>> Node. >>> >>> Jasper >>> >>> On Mar 11, 2013, at 4:20 PM, Mark Fortner wrote: >>> >>> > I recently came across the "createSymbols" property code in the >>> LineChart >>> > and was wondering if there was some reason to write it this way rather >>> than >>> > simply having a default implementation of some Symbol interface which >>> the >>> > user can replace by simply setting the value. >>> > >>> > For my application, I ended up writing some conditional decorators for >>> the >>> > symbol, but as I was doing this I thought how much easier it would be >>> if >>> > the symbols had a factory where one could register new >>> implementations, or >>> > replace the factory itself to provide some conditional switching >>> logic, etc. >>> > >>> > Any thoughts on improving the flexibility of the charts? >>> > >>> > Cheers, >>> > >>> > Mark >>> > >>> > >>> > >>> > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < >>> > parvathi.somashekar at oracle.com> wrote: >>> > >>> >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the our >>> plan >>> >> of not adding the API at the Series level. >>> >> >>> >> thanks, >>> >> Paru. >>> >> >>> >> On 3/11/13 3:25 PM, Jasper Potts wrote: >>> >> >>> >>> I feel like adding "createSymbols" boolean property to Area,& >>> >>> StackedArea charts makes sense to match LineChart. >>> >>> >>> >>> >>> >>> I don't like the idea of adding API to the series object on XYChart >>> as >>> >>> that is more generic and used by many chart types. If the user needs >>> fine >>> >>> grain control of symbols like in RT-21539 they can turn auto symbol >>> >>> generation off with "createSymbols = false" then create their own >>> symbol >>> >>> nodes for the cases when they do want them. >>> >>> >>> >>> Thanks >>> >>> >>> >>> Jasper >>> >>> >>> >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar>> >>> somashekar at oracle.com > wrote: >>> >>> >>> >>> There is a request for adding the createSymbols flag at the XYChart's >>> >>>> Series level instead of on Chart. >>> >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539< >>> http://javafx-jira.kenai.com/browse/RT-21539> >>> >>>> >>> >>>> I think it might be a good idea to add it at the Series level so >>> that >>> >>>> one can turn ON / OFF symbols per Series rather than for all the >>> series of >>> >>>> a chart. >>> >>>> The API could continue to be the same - except live at the Series >>> level. >>> >>>> Each chart can then create symbols for each of its Series only if >>> this flag >>> >>>> is turned on. >>> >>>> This might however not make much sense for Scatter, Bubble and >>> BarCharts. >>> >>>> What do you think Jasper? >>> >>>> >>> >>>> -Paru. >>> >>>> >>> >>>> On 3/8/13 4:12 AM, Sven Reimers wrote: >>> >>>> >>> >>>>> Hi all >>> >>>>> >>> >>>>> AreaChart and StackedAreaChart are missing an API to simply >>> disable the >>> >>>>> creation of symbols. At the moment this is only possible by >>> complex css >>> >>>>> style acrobatics. LineChart on the other hand already provides a >>> simple >>> >>>>> way >>> >>>>> to do this. The proposed tweak takes the existing API from >>> LineChart and >>> >>>>> adds this to AreaChart and StackedAreaChart. >>> >>>>> >>> >>>>> Desired API change: >>> >>>>> >>> >>>>> /** >>> >>>>> * Indicates whether symbols for data points will be created or >>> >>>>> not. >>> >>>>> * >>> >>>>> * @return true if symbols for data points will be created and >>> >>>>> false >>> >>>>> otherwise. >>> >>>>> */ >>> >>>>> public final boolean getCreateSymbols() { return >>> >>>>> createSymbols.getValue(); } >>> >>>>> public final void setCreateSymbols(boolean value) { >>> >>>>> createSymbols.setValue(value); } >>> >>>>> public final BooleanProperty createSymbolsProperty() { return >>> >>>>> createSymbols; } >>> >>>>> >>> >>>>> Desired additional CSS property (incldues additional >>> StyleableProperty): >>> >>>>> >>> >>>>> -fx-create-symbols >>> >>>>> >>> >>>>> >>> >>>>> JIRA: >>> >>>>> http://javafx-jira.kenai.com/**browse/RT-28148< >>> http://javafx-jira.kenai.com/browse/RT-28148> >>> >>>>> >>> >>>>> Thank >>> >>>>> >>> >>>>> -Sven >>> >>>>> >>> >>>>> P.S. An updated patch will hopefully be available there too. >>> >>>>> >>> >>>>> >>> >> >>> >>> >> >> >> -- >> 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 >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * 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 * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * 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 Thu Mar 14 07:48:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 14:48:11 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130314144817.D21FF4813D@hg.openjdk.java.net> Changeset: 1a058c3aeb05 Author: Martin Sladecek Date: 2013-03-14 15:33 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1a058c3aeb05 RT-28961 BooleanExpression created by methods and(), or() are not cleaned ! javafx-beans/nbproject/project.xml ! javafx-beans/src/javafx/beans/binding/Bindings.java Changeset: c01cba0a1e6f Author: Martin Sladecek Date: 2013-03-14 15:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c01cba0a1e6f merge From david.grieve at oracle.com Thu Mar 14 08:20:34 2013 From: david.grieve at oracle.com (David Grieve) Date: Thu, 14 Mar 2013 11:20:34 -0400 Subject: SimpleStyleableProperties API Questions In-Reply-To: References: <00BAE2BF-8812-4E84-9620-666B687B6BAC@oracle.com> Message-ID: <98CBE357-68CD-4ECC-BD1C-C4E34FBBFCA7@oracle.com> I'm sorry. I must really be misunderstanding what it is you are suggesting. I don't know how you can have SimpleStyleableProperty extend both StyleableProperty and SimpleProperty. On Mar 14, 2013, at 10:15 AM, Danno Ferrin wrote: > > > > > 2. Why does it extend from SimpleProperty instead of > > StyleableProperty? Just an implementation convenience? I think it > > would be more valuable to extend from the Styleable property than the > > Simple property, since simple only adds implementation but styleable adds > > implementation for a new interface. I see myself adding more > > StyleableDoubleProperties that are backed by a Simple varient than a > > SimpleDoubleProperty backed by the styleable variant. > > > > Because we want SimpleStyleableProperty to be a SimpleProperty _and_ a StyleableProperty. It is the only way to do it since SimpleProperty is a class and StyleableProperty is an interface. To do it the other way around would require that the SimpleStyleableProperty re-implement the entire SimpleProperty API - PropertyBase, Property, ReadOnlyProperty and so on. > > I can understand that you want to be able to do 'StyleableDoubleProperty foo = new SimpleStyleableDoubleProperty(FOO);' But you can do 'StyleableProperty foo = new SimpleStyleableDoubleProperty(FOO);' > > > I want it to be a SimplePorperty and a StyleableProperty, you missed the on the styleable, very important. Both of these classes derive from PropertyBase, so they both save a lot of overhead there. It is the implementation in the specialization where the horse trading occurs. The implementation overhead for SimpleProperty is 3 one-line constructors, two fields, and two one line methods for those fields. The implementation overhead for SimpleStyleableProperty is 4 constructors, 5 methods, and a total of 8 lines, and two fields. Really slightly more code duplication and work is being done for the current hierarchy. > > > -- > Danno From hang.vo at oracle.com Thu Mar 14 09:18:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 16:18:27 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-28983: Modena dosn't use LCD text on Windows Message-ID: <20130314161834.79C0348149@hg.openjdk.java.net> Changeset: 589dff8b15bb Author: "Jasper Potts" Date: 2013-03-14 09:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/589dff8b15bb Fixed RT-28983: Modena dosn't use LCD text on Windows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From phidias51 at gmail.com Thu Mar 14 10:32:35 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 14 Mar 2013 10:32:35 -0700 Subject: New Proposals for Symbol Support In Charts Message-ID: At Sven's request, I'm spinning off a new thread for these discussions. *John Smith:* My thought was the default implementation of the SymbolFactory would do no more or less than is currently done. But would provide an injection point where a developer could provide new Symbols. So if you want to create a "Series only, No Data" symbol, then you would simply provide the appropriate factory to do so. That said, the *layoutPlotChildren* method would need to "come out of the closet". There's a lot of magic that happens in that method and that magic makes it possible to really customize what can be placed in a chart. In my case, I ended up creating a hacked version of the LineChart with support for injectable symbol decorators. This made it possible to create data-dependent symbols. In my case, the appearance of the symbol varied a lot depending on the user object associated with the data. The symbols had support for mouse over events, on-click events, and could listen for drag events within the chart (used to select multiple symbols within a chart). One example of customization involved a standard symbol which appeared with a vertical line through it, if the data object indicated that there was a search hit for it. The same symbol might also have a fill color if the node was selected. A single series might have data objects that have all or none of these decorations associated with them. It was only afterward when I looked at the code again that a light went off and I thought, "that would be easier to do in the future with a customizable symbol factory". The "symbols in legends" use case that you mentioned, sounds more like a LegendItem. http://javafx-jira.kenai.com/browse/RT-28409 *Sven:* The symbol factory could produce series-specific symbols depending on the user's implementation. I don't see any reason why the user shouldn't be able to create a symbol factory that contains a list of symbol factories which match the i'th series with the i'th symbol factory (if that's what you're after). I'm not sure how well the symbol factory approach would work for fxml in general. But from a programmatic point of view it would make things easier. How do the current cell factories work with fxml? Having a setter for the symbol factory in XYChart would allow for customization of the symbol factory in the controller code. This way you could still do your layout work in SceneBuilder, and customize series-dependent, and data-dependent symbols in the controller. I don't mind having other symbol factory implementations in jfxtras, but basic support for symbol factories themselves, would need to be in the charts API in order to make that feasible. As for memory consumption, I think the existing API has nodes per symbol. And nodes are added and removed as series and data are added and removed. It might be interesting to see what people come up with for implementations of the factory to see what kind of variations one could expect, and see if there are any cases that wouldn't be easily supported. Cheers, Mark On Wed, Mar 13, 2013 at 5:55 PM, John Smith wrote: > There are symbols in legends, which don't have data items and sometimes > users want these symbols styled differently from symbols marking data > points in charts. > > Mark, in your proposal, would you invoke something like the code below to > get the legend symbol for a series? > ISymbol legendSymbolForSeries1 = factory.getSymbol(series1, null); > > Also, on style, is there a precedence for prefixing interface names with I > in the JavaFX code? > > --------- > > I do like the idea of some kind of factory mechanism to customize chart > symbols. > > There have been numerous questions on forums related to chart symbol (and > legend and line) customization. > > https://forums.oracle.com/forums/thread.jspa?threadID=2411524 "How to > remove symbols from an AreaChart in JavaFX" > https://forums.oracle.com/forums/thread.jspa?messageID=9697930 "Create > onMouseClickEvent on Symbol of the chart" > https://forums.oracle.com/forums/thread.jspa?messageID=10145108 "How to > customize line chart series and symbols?" > https://forums.oracle.com/forums/thread.jspa?messageID=10013764 "Pie > Chart and legend symbols" > https://forums.oracle.com/forums/thread.jspa?messageID=1063034 "Toggle > the visibility of a single series with symbols" > https://forums.oracle.com/forums/thread.jspa?messageID=10286441 "Coloring > the legend" > https://forums.oracle.com/forums/thread.jspa?messageID=10598795 "Display > Tooltips on charts values?" > https://forums.oracle.com/forums/thread.jspa?messageID=10680210 "Creating > a table within the actual Chart" > > http://stackoverflow.com/questions/11949891/javafx2-linechart-symbols-and-css"LineChart symbols and CSS" > > http://stackoverflow.com/questions/12287484/controlling-symbols-etc-in-linecharts-inline-programmatically"Controlling symbols, etc. in lineCharts inline programmatically" > > http://stackoverflow.com/questions/12622709/javafx-2-0-how-to-change-legend-color-of-a-linechart-dynamically"How to change legend color of a LineChart dynamically?" > > http://stackoverflow.com/questions/9757848/how-to-dynamically-change-line-style-in-javafx-2-0-line-chart"How to dynamically change line style in JavaFX 2.0 line chart?" > > http://stackoverflow.com/questions/15237192/how-to-display-bar-value-on-top-of-bar-javafx"how to display bar value on top of bar javafx" > > People do have difficulties trying to get charts to look and work the way > they want. > It's somewhat understandable because there are a million different ways > you can imagine charts to look and data to be represented, so they tend to > be pretty heavily customized. > > All of the above questions were answerable using the current public API > (mostly before the code was open sourced). JavaFX is flexible enough that > you can get it to do pretty much anything with a fairly minimal API, but > knowing a few tricks such as lookup by css selector, helps in customizing > complex hierarchical nodes like charts (in the absence of easily > discoverable public api). > > I guess, the good news from this is that JavaFX charts is a feature that > gets some usage. > It's also a nice library and one of the reason people use it is that the > default charts look nice - fresh and clean. > > In terms of stuff that people struggle with, it would probably be (in > decreasing order of precedence): > Concurrency, > Tables, > Custom charts, > Working out why javafx is not on the classpath, > Deployment, > Dialogs, > Layout, > Reusing nodes in the scene graph > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner > Sent: Wednesday, March 13, 2013 11:32 AM > To: Sven Reimers > Cc: openjfx-dev at openjdk.java.net > Subject: Re: [API Review]: RT-28148 - Add createSymbols Property to > AreaChart / StackedAreaChart > > The SymbolFactory idea should probably be discussed a little further. > > It would be useful if there was a simple Symbol interface that you could > use. This would let you turn any Node subclass into a Symbol. > > public interface ISymbol{ > > Node getNode(); > void setStyle(.....) > void addEventHandler(....) > void removeEventHandler(....) > > } > > The event handler methods would insure that the symbol can always respond > to mouseover and click events (or any other events the user wants to > support). The style method makes it easy to make the symbol pretty. > > The factory would then do something simple like: > > public interface ISymbolFactory { > > /** Get's a series specific symbol. */ > ISymbol getSymbol(Series series, Data dataItem); > > } > > > Inside the chart, the default implementation of the SymbolFactory could be > an anonymous inner class or create an external implementation if you wanted > it to serve as a template for users to extend and customize. You could > pass new implementations of the SymbolFactory into the class in the > constructor if you wanted to change the look. You'd want to do this before > you actually started passing data to the chart, hence the idea of putting > the factory in a constructor. > > Does that sound reasonable? > > > Mark > > > > On Tue, Mar 12, 2013 at 3:01 AM, Sven Reimers >wrote: > > > I like the idea of a symbol factory as well, but it will need to be in > > some way configured per series, since a data item (XYChart.Data) does > > not know about its series. > > > > Seems this may be a bigger API change though - Should we track this > > separately? > > > > Any further comments? > > > > -Sven > > > > > > > > On Tue, Mar 12, 2013 at 12:33 AM, Jasper Potts >wrote: > > > >> A symbol factory would also be a good idea, take in data item and > >> return Node. > >> > >> Jasper > >> > >> On Mar 11, 2013, at 4:20 PM, Mark Fortner wrote: > >> > >> > I recently came across the "createSymbols" property code in the > >> LineChart > >> > and was wondering if there was some reason to write it this way > >> > rather > >> than > >> > simply having a default implementation of some Symbol interface > >> > which > >> the > >> > user can replace by simply setting the value. > >> > > >> > For my application, I ended up writing some conditional decorators > >> > for > >> the > >> > symbol, but as I was doing this I thought how much easier it would > >> > be if the symbols had a factory where one could register new > >> > implementations, > >> or > >> > replace the factory itself to provide some conditional switching > >> > logic, > >> etc. > >> > > >> > Any thoughts on improving the flexibility of the charts? > >> > > >> > Cheers, > >> > > >> > Mark > >> > > >> > > >> > > >> > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar < > >> > parvathi.somashekar at oracle.com> wrote: > >> > > >> >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the > >> >> our > >> plan > >> >> of not adding the API at the Series level. > >> >> > >> >> thanks, > >> >> Paru. > >> >> > >> >> On 3/11/13 3:25 PM, Jasper Potts wrote: > >> >> > >> >>> I feel like adding "createSymbols" boolean property to Area,& > >> >>> StackedArea charts makes sense to match LineChart. > >> >>> > >> >>> > >> >>> I don't like the idea of adding API to the series object on > >> >>> XYChart as that is more generic and used by many chart types. If > >> >>> the user needs > >> fine > >> >>> grain control of symbols like in RT-21539 they can turn auto > >> >>> symbol generation off with "createSymbols = false" then create > >> >>> their own > >> symbol > >> >>> nodes for the cases when they do want them. > >> >>> > >> >>> Thanks > >> >>> > >> >>> Jasper > >> >>> > >> >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar >> >>> somashekar at oracle.com > wrote: > >> >>> > >> >>> There is a request for adding the createSymbols flag at the > >> >>> XYChart's > >> >>>> Series level instead of on Chart. > >> >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539< > >> http://javafx-jira.kenai.com/browse/RT-21539> > >> >>>> > >> >>>> I think it might be a good idea to add it at the Series level so > >> >>>> that one can turn ON / OFF symbols per Series rather than for > >> >>>> all the > >> series of > >> >>>> a chart. > >> >>>> The API could continue to be the same - except live at the > >> >>>> Series > >> level. > >> >>>> Each chart can then create symbols for each of its Series only > >> >>>> if > >> this flag > >> >>>> is turned on. > >> >>>> This might however not make much sense for Scatter, Bubble and > >> BarCharts. > >> >>>> What do you think Jasper? > >> >>>> > >> >>>> -Paru. > >> >>>> > >> >>>> On 3/8/13 4:12 AM, Sven Reimers wrote: > >> >>>> > >> >>>>> Hi all > >> >>>>> > >> >>>>> AreaChart and StackedAreaChart are missing an API to simply > >> >>>>> disable > >> the > >> >>>>> creation of symbols. At the moment this is only possible by > >> >>>>> complex > >> css > >> >>>>> style acrobatics. LineChart on the other hand already provides > >> >>>>> a > >> simple > >> >>>>> way > >> >>>>> to do this. The proposed tweak takes the existing API from > >> LineChart and > >> >>>>> adds this to AreaChart and StackedAreaChart. > >> >>>>> > >> >>>>> Desired API change: > >> >>>>> > >> >>>>> /** > >> >>>>> * Indicates whether symbols for data points will be > >> >>>>> created or not. > >> >>>>> * > >> >>>>> * @return true if symbols for data points will be created > >> >>>>> and false otherwise. > >> >>>>> */ > >> >>>>> public final boolean getCreateSymbols() { return > >> >>>>> createSymbols.getValue(); } > >> >>>>> public final void setCreateSymbols(boolean value) { > >> >>>>> createSymbols.setValue(value); } > >> >>>>> public final BooleanProperty createSymbolsProperty() { > >> >>>>> return createSymbols; } > >> >>>>> > >> >>>>> Desired additional CSS property (incldues additional > >> StyleableProperty): > >> >>>>> > >> >>>>> -fx-create-symbols > >> >>>>> > >> >>>>> > >> >>>>> JIRA: > >> >>>>> http://javafx-jira.kenai.com/**browse/RT-28148< > >> http://javafx-jira.kenai.com/browse/RT-28148> > >> >>>>> > >> >>>>> Thank > >> >>>>> > >> >>>>> -Sven > >> >>>>> > >> >>>>> P.S. An updated patch will hopefully be available there too. > >> >>>>> > >> >>>>> > >> >> > >> > >> > > > > > > -- > > 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 > > * Duke's Choice Award Winner 2009 > > * Blog: http://nbguru.blogspot.com > > > > * 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 danno.ferrin at shemnon.com Thu Mar 14 10:56:07 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 14 Mar 2013 11:56:07 -0600 Subject: SimpleStyleableProperties API Questions In-Reply-To: <98CBE357-68CD-4ECC-BD1C-C4E34FBBFCA7@oracle.com> References: <00BAE2BF-8812-4E84-9620-666B687B6BAC@oracle.com> <98CBE357-68CD-4ECC-BD1C-C4E34FBBFCA7@oracle.com> Message-ID: Rather than deriving from Simple and adding the Styleable implementations, it would derive from Styleable and add the Simple implementations. I'll try and get a patch together tonight demonstrating it. But the advantage then is that I am more likely in my code to expose StyleableDoubleProperties and implement them with SimpleStyleableDoubleProperties. Then at a later date, if I need some more exposure into the styling life cycle I can change the backing impl. The advantage over that and, say StyleableProperty is that the generic isn't subject to erasure and reification contortions. Who would ever expose SimpleDoubleProperty in their API? But I do see people exposing StyleableDoubleProperty in an API. On Thu, Mar 14, 2013 at 9:20 AM, David Grieve wrote: > I'm sorry. I must really be misunderstanding what it is you are > suggesting. I don't know how you can have SimpleStyleableProperty > extend both StyleableProperty and SimpleProperty. > > On Mar 14, 2013, at 10:15 AM, Danno Ferrin > wrote: > > > > > >> > 2. Why does it extend from SimpleProperty instead of >> > StyleableProperty? Just an implementation convenience? I think it >> > would be more valuable to extend from the Styleable property than the >> > Simple property, since simple only adds implementation but styleable >> adds >> > implementation for a new interface. I see myself adding more >> > StyleableDoubleProperties that are backed by a Simple varient than a >> > SimpleDoubleProperty backed by the styleable variant. >> > >> >> Because we want SimpleStyleableProperty to be a SimpleProperty >> _and_ a StyleableProperty. It is the only way to do it since >> SimpleProperty is a class and StyleableProperty is an interface. To do >> it the other way around would require that the SimpleStyleableProperty >> re-implement the entire SimpleProperty API - PropertyBase, >> Property, ReadOnlyProperty and so on. >> >> I can understand that you want to be able to do 'StyleableDoubleProperty >> foo = new SimpleStyleableDoubleProperty(FOO);' But you can do >> 'StyleableProperty foo = new SimpleStyleableDoubleProperty(FOO);' >> >> > I want it to be a SimplePorperty and a StyleableProperty, you > missed the on the styleable, very important. Both of these classes > derive from PropertyBase, so they both save a lot of overhead there. > It is the implementation in the specialization where the horse trading > occurs. The implementation overhead for SimpleProperty is 3 one-line > constructors, two fields, and two one line methods for those fields. The > implementation overhead for SimpleStyleableProperty is 4 constructors, > 5 methods, and a total of 8 lines, and two fields. Really slightly more > code duplication and work is being done for the current hierarchy. > > > -- > Danno > > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From sdn at interactivemesh.com Thu Mar 14 11:17:46 2013 From: sdn at interactivemesh.com (August Lammersdorf, InteractiveMesh) Date: Thu, 14 Mar 2013 19:17:46 +0100 Subject: JavaFX 3D : PhongMaterial specification questions / issues Message-ID: <79408bc5425b11ed4bed22738c8f92ca-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNklbS1kLWkFyBktQXDBeQkMBXVJcQF5T-webmailer2@server01.webmailer.hosteurope.de> - How do I achieve transparency for a non-textured Shape3D? Neither diffuse/specular colors with an alpha value < 1.0 nor Shape3D.setOpacity(0.5) result in translucent 3D shapes. - An opaque image used as diffuse map is ignored, but is rendered if used as a selfillumination map. Is diffuse map still in work? - A transparent image used as diffuse map is rendered (!), but is not blended with the diffuse/specular color. Will blending be supported? - What is the value range of the specular power? Thanks, August p.s. Early access release of OBJ and STL importer planned for next week. 3ds, Collada, and X3D will follow. From chien.yang at oracle.com Thu Mar 14 12:02:14 2013 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 14 Mar 2013 12:02:14 -0700 Subject: JavaFX 3D : PhongMaterial specification questions / issues In-Reply-To: <79408bc5425b11ed4bed22738c8f92ca-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNklbS1kLWkFyBktQXDBeQkMBXVJcQF5T-webmailer2@server01.webmailer.hosteurope.de> References: <79408bc5425b11ed4bed22738c8f92ca-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNklbS1kLWkFyBktQXDBeQkMBXVJcQF5T-webmailer2@server01.webmailer.hosteurope.de> Message-ID: <51421EB6.80004@oracle.com> Hi August, We are aware of the limitations( or bugs) of the 3d prototype in dealing with material. Our Sample Team has been filing JIRA on issues they have encountered. It is a bug that color and map do not blend and we will fix it. Please feel free to file JIRA if we have found new bug or limitation that you want us to evaluate. http://javafx-jira.kenai.com/browse/RT-28874 : Add transparent materials http://javafx-jira.kenai.com/browse/RT-28842 : When both diffuseMap and diffuseColor are set in PhongMaterial, diffuseMap is not used The value range of specular power is currently implemented (not spec.) as byte. Thanks, - Chien On 3/14/2013 11:17 AM, August Lammersdorf, InteractiveMesh wrote: > - How do I achieve transparency for a non-textured Shape3D? Neither > diffuse/specular colors with an alpha value < 1.0 nor > Shape3D.setOpacity(0.5) result in translucent 3D shapes. > > - An opaque image used as diffuse map is ignored, but is rendered if > used as a selfillumination map. Is diffuse map still in work? > > - A transparent image used as diffuse map is rendered (!), but is not > blended with the diffuse/specular color. Will blending be supported? > > - What is the value range of the specular power? > > Thanks, August > > p.s. Early access release of OBJ and STL importer planned for next > week. 3ds, Collada, and X3D will follow. From hang.vo at oracle.com Thu Mar 14 12:18:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 19:18:31 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130314191849.11F7348158@hg.openjdk.java.net> Changeset: fe41f8a41c08 Author: jgiles Date: 2013-03-15 08:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fe41f8a41c08 Reintroduce MouseEventGenerator into javafx-ui-controls. Eclipse tricked me into thinking it would compile but it doesn't when on the command line (clearly different classpaths are being used). + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventGenerator.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java Changeset: 7462badb3a1a Author: jgiles Date: 2013-03-15 08:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7462badb3a1a Disabling problematic RT-28678 unit test temporarily. ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: c48ec880d661 Author: jgiles Date: 2013-03-15 08:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c48ec880d661 Fixing up two unit tests that Eclipse noted had errors. ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/javafx/scene/control/MenuItemTest.java Changeset: 30b551d64339 Author: jgiles Date: 2013-03-15 08:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/30b551d64339 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From phdoerfler at gmail.com Thu Mar 14 12:28:21 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 14 Mar 2013 20:28:21 +0100 Subject: Change existing controls or create new ones? In-Reply-To: <51411476.7050307@oracle.com> References: <9E10C53D-B91E-443D-9612-0E6787CD59B4@gmail.com> <51411476.7050307@oracle.com> Message-ID: <3FBD07BD-7EB7-4B3C-B2BF-A9BE34F57C6A@gmail.com> Thanks for that detailed and quick response! The reason for excluding transformations is a very valid one, indeed. Now that you mentioned the recommended solution I've found it in Group's javadoc and the one of Node's transform properties (e.g. rotate), too. Shame on me - that doc is very well written, actually. Might be worth pointing out at [1] (see the CSS of #button-custom) that Group would take care of the rotation bounds. Regarding your advice on custom controls: That makes sense. One question remains, though: How well do assistive technologies for visually impaired deal with custom controls (or the standard ones)? Are there any resources on what API JavaFX provides for this? Only thing I've heard is that it implements the W3C API for RIAs [2], but that's more of a rumor. What about the Java Accessibility API? Cheers, ~ Philipp [1] http://docs.oracle.com/javafx/2/layout/style_css.htm#sthref51 [2] http://www.w3.org/WAI/intro/aria Am 14.03.2013 um 01:06 schrieb Jonathan Giles : > Good questions. I'll do my best to answer them quickly now. > > Regarding the transformations and their lack of inclusion in layout: the reason for this is that more often than not a transformation is a temporary thing (for example a rotation / glow / drop shadow on mouse hover), and it is not desirable that the layout of your user interface be impacted by these transformations / effects (imagine a wide but short rotating rectangle node pushing / pulling all nodes around it as it goes through its 360 degree rotation). > > However, in saying this, if you do want your layout to be impacted by these transformations / effects the solution is simple: you wrap your Node in a Group, and place that Group in your scenegraph. > > To slightly deep dive (and I hope I'm right here - it's been a while since I've had to explain this), a Node has a few different layout bounds. The two most relevant to layout are 'layoutBounds' and 'boundsInParent'. The layoutBounds is actually what is used to determine sizes / positions of nodes in a layout, but this does not include transformations / effects. These impact the boundsInParent instead. The thing a Group does is gather together the boundsInParent of all of its children and make that its layoutBounds. This is why placing a Node with transformed boundsInParent will be used if you wrap it in a Group. > > Switching to custom controls / customised controls, in general the recommended advice depends on the requirements and availability of a suitable control to base customisations on. I would say the best general advice is to firstly try getting the look you want by just modifying CSS on a custom control. If this works then you're great and can stop. If this doesn't work then you could consider either extending or developing a custom Skin for the control, but this brings with it an expectation that you will support all API from the control class (which is often a big ask). > > One piece of advice I always give when I do conference sessions on custom controls is that you _do not_ have to build UI controls by doing it the way we do it in the UI controls team (that is by extending Control, SkinBase, etc). The only reason why you would do this is if you want to ensure maximum ease of distribution to third parties and the highest level of CSS skinning opportunities (but in saying that I don't think it is much greater than simply doing it the way I normally recommend, which is to extend Region and throw together your UI by adding children to the Region node). > > I hope that makes some degree of sense... > > -- Jonathan > > On 14/03/2013 12:35 p.m., Philipp D?rfler wrote: >> Hi, >> >> the question might benefit from a short example: >> Some days ago I created a prototype of a TabPane [1] and then tried to achieve the same look by styling the already existing TabPane with CSS. The latter was not quite as successful, though [2] but I did not have the time to investigate much further. I know that it is possible to adjust the .tab-header-area's dimensions with CSS but as the dimensions of that header does not seem to obey the boundaries of the rotated tab, I would have to manage the tab-header-area's height (or width that is) manually. >> >> The underlying problem here is that the JavaFX layout managers do in general not account for transforms, so scaling, rotations and translations result in the node crossing the container's boundaries. >> I do not want to question whether this is "expected behavior" or not - I assume there are good reasons for the way it is implemented right now (and be it only the possibility of 3D transformations - and how should those be handled by container panes?). >> No, my actual question is: >> >> What is the preferred way to achieve a reusable TabPane which looks like [1]? Should one try to style the existing one using CSS and Skins or is it better to create a control like this from scratch? Just assuming the first were possible in this example (and it probably is), here are some quick pros and cons. I'd be happy if you could contribute some of your own: >> >> Style existing controls: >> - Better support for assistive technologies, screen readers (it's a TabPane, we already know how it works) >> - => more semantical information >> - already implemented functionality >> >> Start from scratch: >> - Greater flexibility in creating the visuals (wild guess - I have not bothered trying Skin myself, yet) >> - no functionality implemented - you have to do every single thing yourself >> - less semantical information (the screen reader or automation software does not know how a CustomFancyTabPane works) >> >> Might someone who has a deeper understanding of controls shed some light on these questions, please? >> Oh and - those reasons for not taking transformations into account... I'd be interested in them, too. >> >> Cheers, >> ~ Philipp >> >> [1] https://twitter.com/phdoerfler/status/308361970611023873/photo/1 >> [2] http://cl.ly/image/300M0q3k2u38 > From hang.vo at oracle.com Thu Mar 14 12:33:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 19:33:28 +0000 Subject: hg: openjfx/8/controls/rt: RT-27699 : IndexOutOfBoundsException when dynamic setting TitledPane.setMnemonicParsing(false). Message-ID: <20130314193331.BEBFD4815C@hg.openjdk.java.net> Changeset: c2c906a9444a Author: mickf Date: 2013-03-14 19:18 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c2c906a9444a RT-27699 : IndexOutOfBoundsException when dynamic setting TitledPane.setMnemonicParsing(false). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java From ragini.prasad at oracle.com Thu Mar 14 13:33:12 2013 From: ragini.prasad at oracle.com (Ragini Prasad) Date: Thu, 14 Mar 2013 13:33:12 -0700 Subject: Change existing controls or create new ones? In-Reply-To: <3FBD07BD-7EB7-4B3C-B2BF-A9BE34F57C6A@gmail.com> References: <9E10C53D-B91E-443D-9612-0E6787CD59B4@gmail.com> <51411476.7050307@oracle.com> <3FBD07BD-7EB7-4B3C-B2BF-A9BE34F57C6A@gmail.com> Message-ID: <51423408.4000105@oracle.com> Philipp, We have a team inside working on Accessibility support for JavaFX, however it is in early stages. With regards to APIs, we do intend to use ARIA naming conventions for it. -Ragini. On 3/14/2013 12:28 PM, Philipp D?rfler wrote: > Thanks for that detailed and quick response! > > The reason for excluding transformations is a very valid one, indeed. Now that you mentioned the recommended solution I've found it in Group's javadoc and the one of Node's transform properties (e.g. rotate), too. Shame on me - that doc is very well written, actually. Might be worth pointing out at [1] (see the CSS of #button-custom) that Group would take care of the rotation bounds. > > Regarding your advice on custom controls: That makes sense. One question remains, though: How well do assistive technologies for visually impaired deal with custom controls (or the standard ones)? Are there any resources on what API JavaFX provides for this? Only thing I've heard is that it implements the W3C API for RIAs [2], but that's more of a rumor. What about the Java Accessibility API? > > Cheers, > ~ Philipp > > [1] http://docs.oracle.com/javafx/2/layout/style_css.htm#sthref51 > [2] http://www.w3.org/WAI/intro/aria > > Am 14.03.2013 um 01:06 schrieb Jonathan Giles : > >> Good questions. I'll do my best to answer them quickly now. >> >> Regarding the transformations and their lack of inclusion in layout: the reason for this is that more often than not a transformation is a temporary thing (for example a rotation / glow / drop shadow on mouse hover), and it is not desirable that the layout of your user interface be impacted by these transformations / effects (imagine a wide but short rotating rectangle node pushing / pulling all nodes around it as it goes through its 360 degree rotation). >> >> However, in saying this, if you do want your layout to be impacted by these transformations / effects the solution is simple: you wrap your Node in a Group, and place that Group in your scenegraph. >> >> To slightly deep dive (and I hope I'm right here - it's been a while since I've had to explain this), a Node has a few different layout bounds. The two most relevant to layout are 'layoutBounds' and 'boundsInParent'. The layoutBounds is actually what is used to determine sizes / positions of nodes in a layout, but this does not include transformations / effects. These impact the boundsInParent instead. The thing a Group does is gather together the boundsInParent of all of its children and make that its layoutBounds. This is why placing a Node with transformed boundsInParent will be used if you wrap it in a Group. >> >> Switching to custom controls / customised controls, in general the recommended advice depends on the requirements and availability of a suitable control to base customisations on. I would say the best general advice is to firstly try getting the look you want by just modifying CSS on a custom control. If this works then you're great and can stop. If this doesn't work then you could consider either extending or developing a custom Skin for the control, but this brings with it an expectation that you will support all API from the control class (which is often a big ask). >> >> One piece of advice I always give when I do conference sessions on custom controls is that you _do not_ have to build UI controls by doing it the way we do it in the UI controls team (that is by extending Control, SkinBase, etc). The only reason why you would do this is if you want to ensure maximum ease of distribution to third parties and the highest level of CSS skinning opportunities (but in saying that I don't think it is much greater than simply doing it the way I normally recommend, which is to extend Region and throw together your UI by adding children to the Region node). >> >> I hope that makes some degree of sense... >> >> -- Jonathan >> >> On 14/03/2013 12:35 p.m., Philipp D?rfler wrote: >>> Hi, >>> >>> the question might benefit from a short example: >>> Some days ago I created a prototype of a TabPane [1] and then tried to achieve the same look by styling the already existing TabPane with CSS. The latter was not quite as successful, though [2] but I did not have the time to investigate much further. I know that it is possible to adjust the .tab-header-area's dimensions with CSS but as the dimensions of that header does not seem to obey the boundaries of the rotated tab, I would have to manage the tab-header-area's height (or width that is) manually. >>> >>> The underlying problem here is that the JavaFX layout managers do in general not account for transforms, so scaling, rotations and translations result in the node crossing the container's boundaries. >>> I do not want to question whether this is "expected behavior" or not - I assume there are good reasons for the way it is implemented right now (and be it only the possibility of 3D transformations - and how should those be handled by container panes?). >>> No, my actual question is: >>> >>> What is the preferred way to achieve a reusable TabPane which looks like [1]? Should one try to style the existing one using CSS and Skins or is it better to create a control like this from scratch? Just assuming the first were possible in this example (and it probably is), here are some quick pros and cons. I'd be happy if you could contribute some of your own: >>> >>> Style existing controls: >>> - Better support for assistive technologies, screen readers (it's a TabPane, we already know how it works) >>> - => more semantical information >>> - already implemented functionality >>> >>> Start from scratch: >>> - Greater flexibility in creating the visuals (wild guess - I have not bothered trying Skin myself, yet) >>> - no functionality implemented - you have to do every single thing yourself >>> - less semantical information (the screen reader or automation software does not know how a CustomFancyTabPane works) >>> >>> Might someone who has a deeper understanding of controls shed some light on these questions, please? >>> Oh and - those reasons for not taking transformations into account... I'd be interested in them, too. >>> >>> Cheers, >>> ~ Philipp >>> >>> [1] https://twitter.com/phdoerfler/status/308361970611023873/photo/1 >>> [2] http://cl.ly/image/300M0q3k2u38 From hang.vo at oracle.com Thu Mar 14 14:04:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 21:04:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28993: can't debug on mac inside IDE Message-ID: <20130314210443.E237D4815D@hg.openjdk.java.net> Changeset: eb2fd3306c9a Author: snorthov Date: 2013-03-14 16:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eb2fd3306c9a RT-28993: can't debug on mac inside IDE ! glass/glass-lib-macosx/src/GlassTimer.m From phdoerfler at gmail.com Thu Mar 14 14:15:57 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 14 Mar 2013 22:15:57 +0100 Subject: Change existing controls or create new ones? In-Reply-To: <51423408.4000105@oracle.com> References: <9E10C53D-B91E-443D-9612-0E6787CD59B4@gmail.com> <51411476.7050307@oracle.com> <3FBD07BD-7EB7-4B3C-B2BF-A9BE34F57C6A@gmail.com> <51423408.4000105@oracle.com> Message-ID: Thanks, good to hear! Am 14.03.2013 um 21:33 schrieb Ragini Prasad : > Philipp, > We have a team inside working on Accessibility support for JavaFX, however it is in early stages. > With regards to APIs, we do intend to use ARIA naming conventions for it. > -Ragini. > > On 3/14/2013 12:28 PM, Philipp D?rfler wrote: >> Thanks for that detailed and quick response! >> >> The reason for excluding transformations is a very valid one, indeed. Now that you mentioned the recommended solution I've found it in Group's javadoc and the one of Node's transform properties (e.g. rotate), too. Shame on me - that doc is very well written, actually. Might be worth pointing out at [1] (see the CSS of #button-custom) that Group would take care of the rotation bounds. >> >> Regarding your advice on custom controls: That makes sense. One question remains, though: How well do assistive technologies for visually impaired deal with custom controls (or the standard ones)? Are there any resources on what API JavaFX provides for this? Only thing I've heard is that it implements the W3C API for RIAs [2], but that's more of a rumor. What about the Java Accessibility API? >> >> Cheers, >> ~ Philipp >> >> [1] http://docs.oracle.com/javafx/2/layout/style_css.htm#sthref51 >> [2] http://www.w3.org/WAI/intro/aria >> >> Am 14.03.2013 um 01:06 schrieb Jonathan Giles : >> >>> Good questions. I'll do my best to answer them quickly now. >>> >>> Regarding the transformations and their lack of inclusion in layout: the reason for this is that more often than not a transformation is a temporary thing (for example a rotation / glow / drop shadow on mouse hover), and it is not desirable that the layout of your user interface be impacted by these transformations / effects (imagine a wide but short rotating rectangle node pushing / pulling all nodes around it as it goes through its 360 degree rotation). >>> >>> However, in saying this, if you do want your layout to be impacted by these transformations / effects the solution is simple: you wrap your Node in a Group, and place that Group in your scenegraph. >>> >>> To slightly deep dive (and I hope I'm right here - it's been a while since I've had to explain this), a Node has a few different layout bounds. The two most relevant to layout are 'layoutBounds' and 'boundsInParent'. The layoutBounds is actually what is used to determine sizes / positions of nodes in a layout, but this does not include transformations / effects. These impact the boundsInParent instead. The thing a Group does is gather together the boundsInParent of all of its children and make that its layoutBounds. This is why placing a Node with transformed boundsInParent will be used if you wrap it in a Group. >>> >>> Switching to custom controls / customised controls, in general the recommended advice depends on the requirements and availability of a suitable control to base customisations on. I would say the best general advice is to firstly try getting the look you want by just modifying CSS on a custom control. If this works then you're great and can stop. If this doesn't work then you could consider either extending or developing a custom Skin for the control, but this brings with it an expectation that you will support all API from the control class (which is often a big ask). >>> >>> One piece of advice I always give when I do conference sessions on custom controls is that you _do not_ have to build UI controls by doing it the way we do it in the UI controls team (that is by extending Control, SkinBase, etc). The only reason why you would do this is if you want to ensure maximum ease of distribution to third parties and the highest level of CSS skinning opportunities (but in saying that I don't think it is much greater than simply doing it the way I normally recommend, which is to extend Region and throw together your UI by adding children to the Region node). >>> >>> I hope that makes some degree of sense... >>> >>> -- Jonathan >>> >>> On 14/03/2013 12:35 p.m., Philipp D?rfler wrote: >>>> Hi, >>>> >>>> the question might benefit from a short example: >>>> Some days ago I created a prototype of a TabPane [1] and then tried to achieve the same look by styling the already existing TabPane with CSS. The latter was not quite as successful, though [2] but I did not have the time to investigate much further. I know that it is possible to adjust the .tab-header-area's dimensions with CSS but as the dimensions of that header does not seem to obey the boundaries of the rotated tab, I would have to manage the tab-header-area's height (or width that is) manually. >>>> >>>> The underlying problem here is that the JavaFX layout managers do in general not account for transforms, so scaling, rotations and translations result in the node crossing the container's boundaries. >>>> I do not want to question whether this is "expected behavior" or not - I assume there are good reasons for the way it is implemented right now (and be it only the possibility of 3D transformations - and how should those be handled by container panes?). >>>> No, my actual question is: >>>> >>>> What is the preferred way to achieve a reusable TabPane which looks like [1]? Should one try to style the existing one using CSS and Skins or is it better to create a control like this from scratch? Just assuming the first were possible in this example (and it probably is), here are some quick pros and cons. I'd be happy if you could contribute some of your own: >>>> >>>> Style existing controls: >>>> - Better support for assistive technologies, screen readers (it's a TabPane, we already know how it works) >>>> - => more semantical information >>>> - already implemented functionality >>>> >>>> Start from scratch: >>>> - Greater flexibility in creating the visuals (wild guess - I have not bothered trying Skin myself, yet) >>>> - no functionality implemented - you have to do every single thing yourself >>>> - less semantical information (the screen reader or automation software does not know how a CustomFancyTabPane works) >>>> >>>> Might someone who has a deeper understanding of controls shed some light on these questions, please? >>>> Oh and - those reasons for not taking transformations into account... I'd be interested in them, too. >>>> >>>> Cheers, >>>> ~ Philipp >>>> >>>> [1] https://twitter.com/phdoerfler/status/308361970611023873/photo/1 >>>> [2] http://cl.ly/image/300M0q3k2u38 > From hang.vo at oracle.com Thu Mar 14 16:19:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 23:19:26 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130314231936.8D9F04816B@hg.openjdk.java.net> Changeset: 0096a41dcf0f Author: Paru Somashekar Date: 2013-03-14 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0096a41dcf0f RT-21162 stall bar on same category data add ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 722fd37fc0ff Author: Paru Somashekar Date: 2013-03-14 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/722fd37fc0ff RT-19855 Menu setOnAction not fired. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java From hang.vo at oracle.com Thu Mar 14 16:22:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Mar 2013 23:22:34 +0000 Subject: hg: openjfx/8/master/rt: 85 new changesets Message-ID: <20130314232657.CB6FB4816C@hg.openjdk.java.net> Changeset: 14df3baed0f8 Author: Alexander Kouznetsov Date: 2013-03-05 23:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/14df3baed0f8 Ensemble3: Fix for RT-28257 Ensemble3: XYChart Visualization in TreeTableView doesn't update on underlying data update ! apps/samples/Ensemble8/src/app/ensemble/samplepage/XYDataVisualizer.java Changeset: 57f5d847140b Author: Pavel Safrata Date: 2013-03-06 08:10 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/57f5d847140b RT-28797: Fixed NPE when picking node clipped by a node with pickOnBounds set to true. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/PickAndContainsTest.java Changeset: dd17e3699d72 Author: Martin Sladecek Date: 2013-03-06 12:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dd17e3699d72 RT-28636 ObservableLists has wrong order of notification types ! javafx-beans/src/javafx/collections/ListChangeBuilder.java ! javafx-beans/src/javafx/collections/ListChangeListener.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java Changeset: 7fa12f6c2e16 Author: Martin Sladecek Date: 2013-03-06 13:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7fa12f6c2e16 RT-28537 Bidirectional Binding does not maintain the invariant if one of the properties is bound ! javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java ! javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingTest.java Changeset: 3ec5209e2c07 Author: Martin Sladecek Date: 2013-03-06 15:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3ec5209e2c07 RT-28790 Map/Set null values/keys not handled correctly by listeners ! javafx-beans/src/com/sun/javafx/binding/MapExpressionHelper.java ! javafx-beans/src/com/sun/javafx/binding/SetExpressionHelper.java ! javafx-beans/src/com/sun/javafx/collections/ObservableMapWrapper.java ! javafx-beans/src/com/sun/javafx/collections/ObservableSetWrapper.java ! javafx-beans/test/javafx/collections/ObservableMapTestBase.java ! javafx-beans/test/javafx/collections/ObservableSetTestBase.java Changeset: df3ce8a3d2aa Author: Martin Sladecek Date: 2013-03-06 16:26 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/df3ce8a3d2aa RT-26162 Split ObservableList implementations into RandomAcess and Sequential ! javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableSequentialListWrapper.java ! javafx-beans/src/javafx/collections/FXCollections.java Changeset: bc78e8b64377 Author: Chien Yang Date: 2013-03-06 08:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bc78e8b64377 Fix to RT-28821: FX 8 3D: AmbientLight isn't implemented. Approved by Kevin ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape3D.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: c6f4b6d77cbb Author: Chien Yang Date: 2013-03-06 08:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c6f4b6d77cbb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: e2f88c00234e Author: dmasada Date: 2013-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e2f88c00234e RT-28749 Add Ensemble8 to internal build (add fxpackager use) + apps/build-tasks.xml ! apps/samples/Ensemble8/build.xml Changeset: 1a825fa0340f Author: dmasada Date: 2013-03-06 18:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1a825fa0340f Ensemble8: fixing comments ! apps/samples/Ensemble8/src/app/ensemble/EmbeddedApplication.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/PieChartDataVisualizer.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/XYDataVisualizer.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/search/DocumentationIndexer.java Changeset: 05ce1a10c53f Author: Anthony Petrov Date: 2013-03-07 15:35 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/05ce1a10c53f RT-28283 and RT-28284: HiDPI robot support ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass-lib-macosx/src/GlassRobot.m ! glass/glass-lib-macosx/src/GlassStatics.h ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/Pixels.java ! glass/glass/src/com/sun/glass/ui/Robot.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkApplication.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkPixels.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkRobot.java ! glass/glass/src/com/sun/glass/ui/ios/IosApplication.java ! glass/glass/src/com/sun/glass/ui/ios/IosPixels.java ! glass/glass/src/com/sun/glass/ui/ios/IosRobot.java ! glass/glass/src/com/sun/glass/ui/lens/LensApplication.java ! glass/glass/src/com/sun/glass/ui/lens/LensPixels.java ! glass/glass/src/com/sun/glass/ui/lens/LensRobot.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java ! glass/glass/src/com/sun/glass/ui/mac/MacPixels.java ! glass/glass/src/com/sun/glass/ui/mac/MacRobot.java ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java ! glass/glass/src/com/sun/glass/ui/swt/SWTPixels.java ! glass/glass/src/com/sun/glass/ui/swt/SWTRobot.java ! glass/glass/src/com/sun/glass/ui/win/WinApplication.java ! glass/glass/src/com/sun/glass/ui/win/WinPixels.java ! glass/glass/src/com/sun/glass/ui/win/WinRobot.java Changeset: 8e27b105aa5f Author: Alexander Zvegintsev Date: 2013-03-07 16:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8e27b105aa5f RT-28493 Gtk: calling stage.setResizable(false) does not work on Ubuntu Linux ! glass/glass-lib-gtk/src/GlassApplication.cpp ! glass/glass-lib-gtk/src/glass_window.cpp ! glass/glass-lib-gtk/src/glass_window.h Changeset: 7ab5cc8ac4a7 Author: jgodinez Date: 2013-03-07 08:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7ab5cc8ac4a7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: a52bbebbcdb8 Author: rbair Date: 2013-03-07 12:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a52bbebbcdb8 Updated gradle build script to build on windows. Testing is not working yet on windows for Graphics project. ! build.gradle Changeset: 87b6bc4d05c2 Author: Yao Wang Date: 2013-03-07 13:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/87b6bc4d05c2 RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java + javafx-sg-prism/test/com/sun/javafx/sg/prism/NGTriangleMeshTest.java ! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java + javafx-ui-common/test/unit/javafx/scene/shape/TriangleMeshTest.java Changeset: 3465e08c8a3a Author: rbair Date: 2013-03-07 19:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3465e08c8a3a Added ability to designate the build dir instead of inferring it, so that I could make this work with Gradle ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java Changeset: 86c6c588c7a7 Author: rbair Date: 2013-03-07 19:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/86c6c588c7a7 Upated Gradle build & generation scripts ! build.gradle ! generator.gradle Changeset: a359928812d1 Author: rbair Date: 2013-03-07 20:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a359928812d1 Last change to this test broke it for normal ant builds -- fixed it up. ! build.gradle ! generator.gradle ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java Changeset: ccb70bfec745 Author: rbair Date: 2013-03-07 21:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ccb70bfec745 The test target was wrong, attempting to test projects that either didn't exist, or that didn't have any tests! It wouldn't even run. ! build.xml Changeset: cbc4c527bc8a Author: Martin Soch Date: 2013-03-11 09:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cbc4c527bc8a SW pipeline: large glyphs weren't rendered (RT-27789) ! prism-sw/src/com/sun/prism/sw/SWGraphics.java Changeset: c176fd6cd024 Author: Martin Soch Date: 2013-03-11 09:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c176fd6cd024 SW pipeline: was failing with assertion in debug mode, on Windows (RT-28767) ! prism-sw-native/include/PiscesRenderer.inl ! prism-sw-native/src/PiscesBlit.c ! prism-sw-native/src/PiscesPaint.c Changeset: c77fa8b03077 Author: Richard Bair Date: 2013-03-11 09:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c77fa8b03077 RT-28914: Remove unneeded classes in Animation and unused methods Summary: Removed methods that are unused, and trimmed out 8 Java files that aren't needed. Also moved StandaloneAccessor to test code. ! javafx-anim/src/com/sun/javafx/animation/TickCalculation.java - javafx-anim/src/com/sun/javafx/animation/TimingTarget.java ! javafx-anim/src/com/sun/scenario/DelayedRunnable.java ! javafx-anim/src/com/sun/scenario/Settings.java - javafx-anim/src/com/sun/scenario/StandaloneAccessor.java ! javafx-anim/src/com/sun/scenario/ToolkitAccessor.java ! javafx-anim/src/com/sun/scenario/animation/AbstractMasterTimer.java ! javafx-anim/src/com/sun/scenario/animation/AnimationPulse.java ! javafx-anim/src/com/sun/scenario/animation/AnimationPulseMBean.java - javafx-anim/src/com/sun/scenario/animation/FixedPulseTime.java - javafx-anim/src/com/sun/scenario/animation/MilliCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/NanoCurrentTime.java ! javafx-anim/src/com/sun/scenario/animation/SplineInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/AnimationAccessor.java - javafx-anim/src/com/sun/scenario/animation/shared/AnimationPulseReceiver.java ! javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelope.java - javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelopeFactory.java ! javafx-anim/src/com/sun/scenario/animation/shared/ClipInterpolator.java - javafx-anim/src/com/sun/scenario/animation/shared/CurrentTime.java ! javafx-anim/src/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/GeneralClipInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/InterpolationInterval.java ! javafx-anim/src/com/sun/scenario/animation/shared/PulseReceiver.java ! javafx-anim/src/com/sun/scenario/animation/shared/SimpleClipInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! javafx-anim/src/com/sun/scenario/animation/shared/TimelineClipCore.java ! javafx-anim/src/javafx/animation/Animation.java ! javafx-anim/src/javafx/animation/AnimationAccessorImpl.java + javafx-anim/test/unit/com/sun/scenario/StandaloneAccessor.java - javafx-anim/test/unit/com/sun/scenario/ToolkitAccessorStub.java ! javafx-anim/test/unit/com/sun/scenario/animation/AbstractMasterTimerMock.java ! javafx-anim/test/unit/com/sun/scenario/animation/AbstractMasterTimerTest.java - javafx-anim/test/unit/com/sun/scenario/animation/shared/AnimationPulseReceiverTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/FiniteClipEnvelopeTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/InfiniteClipEnvelopeTest.java ! javafx-anim/test/unit/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeTest.java ! javafx-anim/test/unit/javafx/animation/AnimationImpl.java ! javafx-anim/test/unit/javafx/animation/AnimationMock.java + javafx-anim/test/unit/javafx/animation/AnimationPulseReceiverTest.java ! javafx-anim/test/unit/javafx/animation/AnimationSetRateTest.java ! javafx-anim/test/unit/javafx/animation/AnimationTest.java ! javafx-ui-common/build-closed.xml ! javafx-ui-common/project.properties ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Cursor.java ! javafx-ui-common/test/unit/javafx/animation/AbstractMasterTimerMock.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformOperationsTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubMasterTimer.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 90056a34a341 Author: Richard Bair Date: 2013-03-11 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/90056a34a341 Backout accidentally committed change to StubToolkit ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 26c3a8370c80 Author: kcr Date: 2013-03-11 11:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26c3a8370c80 RT-28816: PhongMaterial.toString() method produces StackOverflowError ! javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java + javafx-ui-common/test/unit/javafx/scene/paint/PhongMaterialTest.java Changeset: 782bdba1a80a Author: rbair Date: 2013-03-11 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/782bdba1a80a Removed build-closed reference to tests classpath. It looks like the project.properties, which is not used during the closed build, is used during closed test. ! javafx-ui-common/build-closed.xml Changeset: 98c92b4b238d Author: Radko Najman Date: 2013-03-12 08:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/98c92b4b238d RT-28550 - Regression: dirtyopts repaint issue in HelloFloodGame ! javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java + javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionClipTest.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java Changeset: df3b6b3fdef5 Author: Petr Pchelko Date: 2013-03-12 14:59 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/df3b6b3fdef5 RT-28781 Mac: JVM crashes when screen resolution is changed Reviewed-by: Anthomy, Steve ! glass/glass-lib-macosx/src/GlassTimer.m Changeset: d45b7c33204d Author: Lubomir Nerad Date: 2013-03-12 12:15 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d45b7c33204d Fix for RT-19239: Memory leak with Animated images ! javafx-ui-common/src/javafx/scene/image/Image.java Changeset: ca8641b9b0f4 Author: Martin Soch Date: 2013-03-12 17:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ca8641b9b0f4 SW pipeline: checking input parametrs in Pisces surfaces ! prism-sw-native/src/JJavaSurface.c ! prism-sw-native/src/JNativeSurface.c ! prism-sw/src/com/sun/pisces/AbstractSurface.java ! prism-sw/src/com/sun/pisces/JavaSurface.java ! prism-sw/src/com/sun/pisces/NativeSurface.java Changeset: 9f21025a5563 Author: jgodinez Date: 2013-03-12 09:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9f21025a5563 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-anim/src/com/sun/javafx/animation/TimingTarget.java - javafx-anim/src/com/sun/scenario/StandaloneAccessor.java - javafx-anim/src/com/sun/scenario/animation/FixedPulseTime.java - javafx-anim/src/com/sun/scenario/animation/MilliCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/NanoCurrentTime.java - javafx-anim/src/com/sun/scenario/animation/shared/AnimationPulseReceiver.java - javafx-anim/src/com/sun/scenario/animation/shared/ClipEnvelopeFactory.java - javafx-anim/src/com/sun/scenario/animation/shared/CurrentTime.java - javafx-anim/test/unit/com/sun/scenario/ToolkitAccessorStub.java - javafx-anim/test/unit/com/sun/scenario/animation/shared/AnimationPulseReceiverTest.java Changeset: 709356911e3a Author: "Jasper Potts" Date: 2013-03-06 11:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/709356911e3a Modena Test App: added sample naviagation and position rememebering ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/SamplePageNavigation.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 66330d32d59f Author: jgiles Date: 2013-03-06 12:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/66330d32d59f RT-27609: [TreeTableView] Scroll bar appears while there is enough space for rendering content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: ad7ab4d353c4 Author: jgiles Date: 2013-03-06 16:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ad7ab4d353c4 RT-28479: [TreeTableView] TreeTableColumn onEditCommit handler not called ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 0251aa01fc7c Author: jgiles Date: 2013-03-07 09:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0251aa01fc7c RT-28637: [ListView, TreeView, TableView, TreeTableView] selectionModel selectedItem returns wrong item. Tests were previously developed and have now been enabled. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 7fad68376811 Author: jgiles Date: 2013-03-07 09:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7fad68376811 Unit tests for RT-28819 ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java Changeset: 90ee146e03e5 Author: jgiles Date: 2013-03-07 12:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/90ee146e03e5 Fixes for failing unit tests related to RT-28637 and RT-21586 ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: 22bc48b746d4 Author: jgiles Date: 2013-03-07 12:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/22bc48b746d4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 9dd0e3c584b6 Author: "Jasper Potts" Date: 2013-03-06 16:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9dd0e3c584b6 Fixed RT-28843: TableView header overlaps TableView Border ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 4110414745eb Author: "Jasper Potts" Date: 2013-03-06 17:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4110414745eb Modena Fixed RT-28227: Modena: Table and TreeTable are not refined, Also fixed toolbar gradients for mid grey base colors. Consitant Checkbox sizing for font size changes. Medium text color tweek.Bunch of other CSS cleanup. Modena Test app added more tests for Table and TreeTables. ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! apps/experiments/Modena/src/modena/SamplePageTreeTableHelper.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: fd5419fef373 Author: "Jasper Potts" Date: 2013-03-06 18:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fd5419fef373 Modena Test App added test case for RT-28410 ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java Changeset: 5cb29e82fed6 Author: "Jasper Potts" Date: 2013-03-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5cb29e82fed6 Intellij Project: Added Ensmeble 8 + apps/samples/Ensemble8/Ensemble8.iml Changeset: 180026bf2fca Author: "Jasper Potts" Date: 2013-03-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/180026bf2fca Modena: ComboBox menus were broken by yesterdays list view changes, fixed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: d79881867641 Author: "Jasper Potts" Date: 2013-03-07 17:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d79881867641 Fixed RT-28870:ProgressIndicator ignores padding and has no way to scale done tick mark ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 627e2260bc52 Author: Paru Somashekar Date: 2013-03-07 17:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/627e2260bc52 RT-13672 CategoryAxis diff animated property for diff constructors ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 53284fc129a4 Author: Paru Somashekar Date: 2013-03-07 17:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/53284fc129a4 RT-20110 StackedBarChart - stack does not move down on remove data ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java Changeset: a671a5f72fe9 Author: "Jasper Potts" Date: 2013-03-07 17:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a671a5f72fe9 Modena CSS, progress indicator indeterminate the SVG paths were too complex. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 67fbda7cbc0a Author: "Jasper Potts" Date: 2013-03-07 18:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/67fbda7cbc0a Fixed Modena Pagination to scale with ems. Also made pagination buttons smaller ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 65ab9f40d9ca Author: jgiles Date: 2013-03-08 15:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/65ab9f40d9ca Improved sorting APIs for TableView and TreeTableView, including: RT-17550: onSort event for TableColumn RT-19482: TableView: make sort() (or similar) methods public Also includes a number of new unit tests for the new API. ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java + javafx-ui-controls/src/javafx/scene/control/SortEvent.java ! javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java Changeset: 91f71d5a4918 Author: jgiles Date: 2013-03-08 15:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/91f71d5a4918 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 3f60345c322a Author: David Grieve Date: 2013-03-07 22:47 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3f60345c322a RT-28635: if no style in current state, but there was a style in previous state, revert to initial value ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 81f83507079b Author: David Grieve Date: 2013-03-07 22:53 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/81f83507079b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 811c33cc3302 Author: David Grieve Date: 2013-03-08 10:44 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/811c33cc3302 RT-19089: reset property to initial value if no style and current value was set by css ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: 929a589c869f Author: David Grieve Date: 2013-03-08 15:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/929a589c869f RT-24516: simple cache for Images loaded from stylesheets. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/converters/PaintConverter.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java Changeset: 199a494a54e0 Author: David Grieve Date: 2013-03-08 16:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/199a494a54e0 RT-28888: conditions for setting LabeledText's text fill via -fx-fill did not work with RT-19089 fixes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: ffd70842a48d Author: David Grieve Date: 2013-03-08 16:43 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ffd70842a48d RT-28447: set popup window scene stylesheet to that of the owner window's scene ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: ddb3874aa103 Author: jgiles Date: 2013-03-11 15:09 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ddb3874aa103 RT-28893: ListView PlaceHolder is removed only after second item is added to item list Contributed-by: Sven Reimers Reviewed-by: jgiles ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java Changeset: 7680e1b9d790 Author: jgiles Date: 2013-03-11 15:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7680e1b9d790 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 1e8ef92fe45a Author: jgiles Date: 2013-03-11 15:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1e8ef92fe45a Re-enabling the keyboard input tests for ListView, TreeView, TableView and TreeTableView. Hopefully they don't bring the test infrastructure down again (either by failing on certain platforms or by causing OOME). In any case, if they fail to work they can be @Ignored again, but ideally they would be kept intact and running as they cover a lot of finicky keyboard interaction issues and will help prevent regressions (and I have to write a bunch more tests in the coming weeks for this area too). ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 02a668fbc3b6 Author: jgiles Date: 2013-03-11 15:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/02a668fbc3b6 Fixing a stack overflow issue in VirtualFlow that was identified by the keyboard navigation tests. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: fd29ff6315e7 Author: mickf Date: 2013-03-11 15:01 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fd29ff6315e7 RT-23427 : [ScrollBar] NPE in mouse event processing. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: ced0a6e6f8b4 Author: David Grieve Date: 2013-03-11 13:47 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ced0a6e6f8b4 RT-28292 [TEST-ONLY]: remove @Ignore from Node_effectiveOrientation_Css_Test and replace Toolkit.getToolkit().firePulse(); with root.impl_processCSS(true) ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: a7abdf74e155 Author: David Grieve Date: 2013-03-11 15:34 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a7abdf74e155 RT-28447: backout changeset ffd70842a48d. Causes issues with Modena ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: 36fcf9f812ed Author: David Grieve Date: 2013-03-11 15:38 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/36fcf9f812ed Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: 479e1c3e1371 Author: "Jasper Potts" Date: 2013-03-07 18:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/479e1c3e1371 Modena Progress Indicator default size was huge after last fix. Now fixed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 636b8f96d38a Author: "Jasper Potts" Date: 2013-03-11 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/636b8f96d38a Merge Changeset: c0cc2ab04805 Author: "Jasper Potts" Date: 2013-03-11 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c0cc2ab04805 Modena : Pagination added spacing between content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: b2461430c343 Author: David Grieve Date: 2013-03-11 17:23 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b2461430c343 RT-28447: set popup window scene stylesheet to that of the owner window's scene - this time with better checks on whether or not to clear style cache. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java Changeset: d7a4237233a4 Author: "Jasper Potts" Date: 2013-03-11 14:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d7a4237233a4 Modena - tweek TableView sort arrows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 9d2b8b3fca1d Author: jgiles Date: 2013-03-12 11:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9d2b8b3fca1d RT-28891: 8.0-controls-scrum-404: Controls.TableView-Sort benchmark is broken ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 70b66196aea6 Author: jgiles Date: 2013-03-12 11:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/70b66196aea6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 316976bf4b3c Author: jgiles Date: 2013-03-12 12:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/316976bf4b3c RT-28898: [TableView, TreeTableView] When column 'sortable' is set to false the sort node doesn't disappear. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 283da31ead02 Author: jgiles Date: 2013-03-12 12:35 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/283da31ead02 Ignoring unit test based on change for RT-28891 ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java Changeset: e4bdba51e3b6 Author: "Jasper Potts" Date: 2013-03-11 17:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e4bdba51e3b6 Modena: Tab Pane buttom tabs overflow arrow is not centered. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: c9d36dae8a70 Author: David Grieve Date: 2013-03-12 14:04 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c9d36dae8a70 RT-28907: CSS should only reset properites to initial values if there are no styles to apply to the node after an in-line style or stylesheet change ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: ad5cee5bfad6 Author: "Jasper Potts" Date: 2013-03-12 12:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ad5cee5bfad6 Fixed RT-28939: ScrollBar arrows are rendering with unexpected antialising ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 70612d9f2f28 Author: mo.chicharro Date: 2013-03-12 20:21 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/70612d9f2f28 Fix for RT-28506 - Create better icon svg for scrollbar arrows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 1ee809c26ddd Author: David Grieve Date: 2013-03-12 17:41 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1ee809c26ddd RT-21964: Insert null placeholder for stylesheet url when parsing. Substitute actual stylesheet url when declaration is added to the stylesheet ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: a0a297647a7c Author: "Jasper Potts" Date: 2013-03-12 14:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a0a297647a7c Modena: Fixed scroll arrow centered on TextArea and ScrollPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5634b086feaa Author: "Jasper Potts" Date: 2013-03-12 14:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5634b086feaa Merge Changeset: 50811c4425d8 Author: "Jasper Potts" Date: 2013-03-12 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/50811c4425d8 Modena test app, added workaround for snapshot texture size limit. ! apps/experiments/Modena/src/modena/Modena.java Changeset: 6045e676948b Author: David Grieve Date: 2013-03-12 18:05 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6045e676948b RT-21967: if absolute path without a scheme, strip leading / before resolving URL. ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java Changeset: ecc8529fdc5b Author: David Grieve Date: 2013-03-12 18:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ecc8529fdc5b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: e784a2f6b6a3 Author: David Grieve Date: 2013-03-12 20:00 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e784a2f6b6a3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: f114202c0208 Author: David Grieve Date: 2013-03-12 21:16 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f114202c0208 [TEST-ONLY] RT-21967 causes failures in URLTypeTest because leading / is stripped from url. ! javafx-ui-common/test/unit/com/sun/javafx/css/URLTypeTest.java Changeset: 19a9210e89e2 Author: hudson Date: 2013-03-14 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/19a9210e89e2 Added tag 8.0-b81 for changeset f114202c0208 ! .hgtags From danno.ferrin at shemnon.com Thu Mar 14 20:42:53 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 14 Mar 2013 21:42:53 -0600 Subject: SimpleStyleableProperties API Questions In-Reply-To: References: <00BAE2BF-8812-4E84-9620-666B687B6BAC@oracle.com> <98CBE357-68CD-4ECC-BD1C-C4E34FBBFCA7@oracle.com> Message-ID: Here is a JIRA for the issue: http://javafx-jira.kenai.com/browse/RT-28997 And here is a patch: https://bitbucket.org/shemnon/openjfx-8-master-rt/commits/ad6fa36eb9580babe265dddadc16b2c4b78ad9ee On Thu, Mar 14, 2013 at 11:56 AM, Danno Ferrin wrote: > Rather than deriving from Simple and adding the Styleable implementations, > it would derive from Styleable and add the Simple implementations. I'll > try and get a patch together tonight demonstrating it. > > But the advantage then is that I am more likely in my code to expose > StyleableDoubleProperties and implement them with > SimpleStyleableDoubleProperties. Then at a later date, if I need some more > exposure into the styling life cycle I can change the backing impl. The > advantage over that and, say StyleableProperty is that the generic > isn't subject to erasure and reification contortions. Who would ever > expose SimpleDoubleProperty in their API? But I do see people exposing > StyleableDoubleProperty in an API. > > > On Thu, Mar 14, 2013 at 9:20 AM, David Grieve wrote: > >> I'm sorry. I must really be misunderstanding what it is you are >> suggesting. I don't know how you can have SimpleStyleableProperty >> extend both StyleableProperty and SimpleProperty. >> >> On Mar 14, 2013, at 10:15 AM, Danno Ferrin >> wrote: >> >> >> > >> >>> > 2. Why does it extend from SimpleProperty instead of >>> > StyleableProperty? Just an implementation convenience? I think >>> it >>> > would be more valuable to extend from the Styleable property than the >>> > Simple property, since simple only adds implementation but styleable >>> adds >>> > implementation for a new interface. I see myself adding more >>> > StyleableDoubleProperties that are backed by a Simple varient than a >>> > SimpleDoubleProperty backed by the styleable variant. >>> > >>> >>> Because we want SimpleStyleableProperty to be a SimpleProperty >>> _and_ a StyleableProperty. It is the only way to do it since >>> SimpleProperty is a class and StyleableProperty is an interface. To do >>> it the other way around would require that the SimpleStyleableProperty >>> re-implement the entire SimpleProperty API - PropertyBase, >>> Property, ReadOnlyProperty and so on. >>> >>> I can understand that you want to be able to do 'StyleableDoubleProperty >>> foo = new SimpleStyleableDoubleProperty(FOO);' But you can do >>> 'StyleableProperty foo = new SimpleStyleableDoubleProperty(FOO);' >>> >>> >> I want it to be a SimplePorperty and a StyleableProperty, you >> missed the on the styleable, very important. Both of these classes >> derive from PropertyBase, so they both save a lot of overhead there. >> It is the implementation in the specialization where the horse trading >> occurs. The implementation overhead for SimpleProperty is 3 one-line >> constructors, two fields, and two one line methods for those fields. The >> implementation overhead for SimpleStyleableProperty is 4 constructors, >> 5 methods, and a total of 8 lines, and two fields. Really slightly more >> code duplication and work is being done for the current hierarchy. >> >> >> -- >> Danno >> >> >> > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From hjohn at xs4all.nl Fri Mar 15 11:07:09 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 15 Mar 2013 19:07:09 +0100 Subject: Duplicating a Node Message-ID: <5143634D.9050504@xs4all.nl> Hi list, I'm trying to achieve an effect that requires me to make a copy of a Node, apply some effect(s) on it (PerspectiveTransform, Clip, Blend and perhaps DisplacementMap) and place it in the same scenegraph together with the original. It is very similar to what Reflection achieves, but without alternating the size of the Node, and without the limitations (specifically, creating the correct Reflection for an object that has a PerspectiveTransform applied to it already cannot be done with Reflection). I would prefer not to have to make an actual copy of the Node, as they might get out of sync and not display the same content when they should be. Something like a NodeReference class, that takes another Node as parameter but applies different effects/clips/transforms. Since the code I'm using for this is based on Cells getting laid out, I'm toying with the idea of actually asking the provider of those cells twice for the same cell and applying different transformations on each, but they might get out of sync and it seems there should be a better way. Any ideas or suggestions at how I could best achieve this, or would it be a new feature? --John From phidias51 at gmail.com Fri Mar 15 11:35:09 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 15 Mar 2013 11:35:09 -0700 Subject: JavaFX Update Question Message-ID: I know that there have been a flurry of Java-related updates that have been pushed out over the past couple of months, and I was wondering if these updates also included JavaFX-related fixes, or were these just security updates? Cheers, Mark From steve.x.northover at oracle.com Fri Mar 15 12:33:52 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 15 Mar 2013 15:33:52 -0400 Subject: JavaFX Update Question In-Reply-To: References: Message-ID: <514377A0.7010203@oracle.com> It's the code for the next release being open sourced as quickly as we can. Steve On 15/03/2013 2:35 PM, Mark Fortner wrote: > I know that there have been a flurry of Java-related updates that have been > pushed out over the past couple of months, and I was wondering if these > updates also included JavaFX-related fixes, or were these just security > updates? > > Cheers, > > Mark From phidias51 at gmail.com Fri Mar 15 12:38:58 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 15 Mar 2013 12:38:58 -0700 Subject: JavaFX Update Question In-Reply-To: <514377A0.7010203@oracle.com> References: <514377A0.7010203@oracle.com> Message-ID: So 7u15, 17, etc don't contain any of the recent JavaFX changes, correct? Cheers, Mark On Fri, Mar 15, 2013 at 12:33 PM, wrote: > It's the code for the next release being open sourced as quickly as we can. > > Steve > > > On 15/03/2013 2:35 PM, Mark Fortner wrote: > >> I know that there have been a flurry of Java-related updates that have >> been >> pushed out over the past couple of months, and I was wondering if these >> updates also included JavaFX-related fixes, or were these just security >> updates? >> >> Cheers, >> >> Mark >> > From steve.x.northover at oracle.com Fri Mar 15 12:41:42 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 15 Mar 2013 15:41:42 -0400 Subject: JavaFX Update Question In-Reply-To: References: <514377A0.7010203@oracle.com> Message-ID: <51437976.40602@oracle.com> I thought the question was around code we were releasing to open source. Is there a particular fix you are looking for? Steve On 15/03/2013 3:38 PM, Mark Fortner wrote: > So 7u15, 17, etc don't contain any of the recent JavaFX changes, correct? > > Cheers, > > Mark > > > > On Fri, Mar 15, 2013 at 12:33 PM, > wrote: > > It's the code for the next release being open sourced as quickly > as we can. > > Steve > > > On 15/03/2013 2:35 PM, Mark Fortner wrote: > > I know that there have been a flurry of Java-related updates > that have been > pushed out over the past couple of months, and I was wondering > if these > updates also included JavaFX-related fixes, or were these just > security > updates? > > Cheers, > > Mark > > From richard.bair at oracle.com Fri Mar 15 12:43:24 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Mar 2013 12:43:24 -0700 Subject: JavaFX Update Question In-Reply-To: References: <514377A0.7010203@oracle.com> Message-ID: Most of the FX changes are going into 8 not the 7 line. On Mar 15, 2013, at 12:38 PM, Mark Fortner wrote: > So 7u15, 17, etc don't contain any of the recent JavaFX changes, correct? > > Cheers, > > Mark > > > > On Fri, Mar 15, 2013 at 12:33 PM, wrote: > >> It's the code for the next release being open sourced as quickly as we can. >> >> Steve >> >> >> On 15/03/2013 2:35 PM, Mark Fortner wrote: >> >>> I know that there have been a flurry of Java-related updates that have >>> been >>> pushed out over the past couple of months, and I was wondering if these >>> updates also included JavaFX-related fixes, or were these just security >>> updates? >>> >>> Cheers, >>> >>> Mark >>> >> From philip.race at oracle.com Fri Mar 15 12:54:38 2013 From: philip.race at oracle.com (Phil Race) Date: Fri, 15 Mar 2013 12:54:38 -0700 Subject: JavaFX Update Question In-Reply-To: References: <514377A0.7010203@oracle.com> Message-ID: <51437C7E.5000903@oracle.com> What recent FX changes ? All the FX development is around FX 8 which is for JDK 8 .. this does not go out with a 7 release. You can always look at the FX version - if it didn't change, then there were no FX changes :-) -phil. On 3/15/2013 12:38 PM, Mark Fortner wrote: > So 7u15, 17, etc don't contain any of the recent JavaFX changes, correct? > > Cheers, > > Mark > > > > On Fri, Mar 15, 2013 at 12:33 PM, wrote: > >> It's the code for the next release being open sourced as quickly as we can. >> >> Steve >> >> >> On 15/03/2013 2:35 PM, Mark Fortner wrote: >> >>> I know that there have been a flurry of Java-related updates that have >>> been >>> pushed out over the past couple of months, and I was wondering if these >>> updates also included JavaFX-related fixes, or were these just security >>> updates? >>> >>> Cheers, >>> >>> Mark >>> From tom.schindl at bestsolution.at Fri Mar 15 13:04:15 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 15 Mar 2013 21:04:15 +0100 Subject: JavaFX Update Question In-Reply-To: <51437C7E.5000903@oracle.com> References: <514377A0.7010203@oracle.com> <51437C7E.5000903@oracle.com> Message-ID: There are fixes in the java 7 area like http://javafx-jira.kenai.com/browse/RT-23411 which got fixed months ago but still are not rolled out with the latest update of Java7. The time between the fix and rollout to clients is a bit disappointing. Tom Von meinem iPhone gesendet Am 15.03.2013 um 20:54 schrieb Phil Race : > > What recent FX changes ? All the FX development is around FX 8 which is > for JDK 8 .. this does not go out with a 7 release. > You can always look at the FX version - if it didn't change, then there were > no FX changes :-) > > > -phil. > > On 3/15/2013 12:38 PM, Mark Fortner wrote: >> So 7u15, 17, etc don't contain any of the recent JavaFX changes, correct? >> >> Cheers, >> >> Mark >> >> >> >> On Fri, Mar 15, 2013 at 12:33 PM, wrote: >> >>> It's the code for the next release being open sourced as quickly as we can. >>> >>> Steve >>> >>> >>> On 15/03/2013 2:35 PM, Mark Fortner wrote: >>> >>>> I know that there have been a flurry of Java-related updates that have >>>> been >>>> pushed out over the past couple of months, and I was wondering if these >>>> updates also included JavaFX-related fixes, or were these just security >>>> updates? >>>> >>>> Cheers, >>>> >>>> Mark > From hang.vo at oracle.com Fri Mar 15 16:48:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Mar 2013 23:48:29 +0000 Subject: hg: openjfx/8/controls/rt: RT-26147: Tooltip layout issue in RTL orientation. Message-ID: <20130315234837.119D8481AB@hg.openjdk.java.net> Changeset: 148a5ddb6d8d Author: leifs Date: 2013-03-15 16:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/148a5ddb6d8d RT-26147: Tooltip layout issue in RTL orientation. ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java From phidias51 at gmail.com Fri Mar 15 17:15:27 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 15 Mar 2013 17:15:27 -0700 Subject: JavaFX Update Question In-Reply-To: References: <514377A0.7010203@oracle.com> <51437C7E.5000903@oracle.com> Message-ID: Can I assume that issues marked as critical/high priority or with the most votes are going into 7 as well as 8? Security-related patches are most likely to be applied, but moving to 8 is probably off the table for the next 18 months or so. Cheers, Mark On Fri, Mar 15, 2013 at 1:04 PM, Tom Schindl wrote: > There are fixes in the java 7 area like > http://javafx-jira.kenai.com/browse/RT-23411 which > got fixed months ago but still are not rolled out with the latest update of > Java7. The time between the fix and rollout to clients is a bit > disappointing. > > Tom > > Von meinem iPhone gesendet > > Am 15.03.2013 um 20:54 schrieb Phil Race : > > > What recent FX changes ? All the FX development is around FX 8 which is > for JDK 8 .. this does not go out with a 7 release. > You can always look at the FX version - if it didn't change, then there > were > no FX changes :-) > > > -phil. > > On 3/15/2013 12:38 PM, Mark Fortner wrote: > > So 7u15, 17, etc don't contain any of the recent JavaFX changes, correct? > > > Cheers, > > > Mark > > > > > On Fri, Mar 15, 2013 at 12:33 PM, wrote: > > > It's the code for the next release being open sourced as quickly as we can. > > > Steve > > > > On 15/03/2013 2:35 PM, Mark Fortner wrote: > > > I know that there have been a flurry of Java-related updates that have > > been > > pushed out over the past couple of months, and I was wondering if these > > updates also included JavaFX-related fixes, or were these just security > > updates? > > > Cheers, > > > Mark > > > > From hang.vo at oracle.com Fri Mar 15 17:48:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 16 Mar 2013 00:48:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28991 Ensemble8: HTMLEditor needs to fit on screen better Message-ID: <20130316004900.3B3FE481AE@hg.openjdk.java.net> Changeset: d0f2b546a80c Author: dmasada Date: 2013-03-15 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d0f2b546a80c RT-28991 Ensemble8: HTMLEditor needs to fit on screen better ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/htmleditor/HTMLEditorApp.java From hang.vo at oracle.com Fri Mar 15 19:18:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 16 Mar 2013 02:18:53 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130316021900.62476481B3@hg.openjdk.java.net> Changeset: df35cfefa6bd Author: Alexander Kouznetsov Date: 2013-03-15 19:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/df35cfefa6bd Modena app: make use of opacity in base, background or accent color ! apps/experiments/Modena/src/modena/Modena.java Changeset: f9cdb400a0d5 Author: Alexander Kouznetsov Date: 2013-03-15 19:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f9cdb400a0d5 Modena skin: Copied pattern-transparent.png for Modena skin to fix NPE in CustomColorDialog with Modena + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png From ozemale at ozemail.com.au Sat Mar 16 06:58:11 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sun, 17 Mar 2013 00:58:11 +1100 Subject: The relationship between Scene Builder and Firefox Message-ID: <001801ce224e$4c29bbc0$e47d3340$@com.au> I am just a little curious... I just tried to uninstall my current version of Scene Builder on Windows and it told me that I needed to close Firefox before the uninstall could proceed. Why does installing or uninstalling Scene Builder have anything to do with Firefox??? (Apologies if this is not the most appropriate forum for this question... I figured I would get the definitive answer here). From swpalmer at gmail.com Sat Mar 16 08:28:57 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 16 Mar 2013 11:28:57 -0400 Subject: The relationship between Scene Builder and Firefox In-Reply-To: <001801ce224e$4c29bbc0$e47d3340$@com.au> References: <001801ce224e$4c29bbc0$e47d3340$@com.au> Message-ID: <6767CC92-7A88-48FD-AC2D-7B054C1E5048@gmail.com> This is probably caused by a bug in Windows. The Microsoft Installer tech doesn't identify the "files in use" properly. Using only the filename and not the full path. So if the java plugin has a file with the same name as one installed by Scene Builder it will be confused. Scott On 2013-03-16, at 9:58 AM, "John C. Turnbull" wrote: > I am just a little curious... I just tried to uninstall my current version > of Scene Builder on Windows and it told me that I needed to close Firefox > before the uninstall could proceed. > > > > Why does installing or uninstalling Scene Builder have anything to do with > Firefox??? > > > > (Apologies if this is not the most appropriate forum for this question... I > figured I would get the definitive answer here). > From thekonradzuse at hotmail.com Sat Mar 16 09:32:17 2013 From: thekonradzuse at hotmail.com (Konrad Zuse) Date: Sat, 16 Mar 2013 12:32:17 -0400 Subject: JavaFX Update Question In-Reply-To: References: Message-ID: http://jdk8.java.net/download.html As others have said no changes are being made to 7, what's the point since we are all prepping for 8's release at the end of the year. Make sure to be updated with the beta builds as new builds come out every 1-2 weeks I believe. If you find any bugs, or have suggestions/tweaks hit up JIRA for JavaFX http://javafx-jira.kenai.com/secure/Dashboard.jspa From phidias51 at gmail.com Sat Mar 16 09:52:07 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Sat, 16 Mar 2013 09:52:07 -0700 Subject: JavaFX Update Question In-Reply-To: References: Message-ID: Unfortunately, most organizations of any size don't adopt a technology as soon as it's released. Witness the fact that the switch from 1.4 to 5 or 6 took more than 4 years to accomplish and there are still organizations out there running 1.4. The typical lag between a release and adoption is a minimum of 6 months. The only exception is for security-related patches. Which brings me back to my original question, if JavaFX fixes are deployed along with the security patches, then we'll start to see the benefits sooner rather than later. Cheers, Mark On Sat, Mar 16, 2013 at 9:32 AM, Konrad Zuse wrote: > http://jdk8.java.net/download.html > > As others have said no changes are being made to 7, what's the point since > we are all prepping for 8's release at the end of the year. Make sure to > be updated with the beta builds as new builds come out every 1-2 weeks I > believe. If you find any bugs, or have suggestions/tweaks hit up JIRA for > JavaFX http://javafx-jira.kenai.com/secure/Dashboard.jspa > From phidias51 at gmail.com Sat Mar 16 10:44:57 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Sat, 16 Mar 2013 10:44:57 -0700 Subject: JavaFX Update Question Message-ID: Hi Konrad, Actually, I've only been talking about the availability of high priority bug fixes in Java 7 patch releases. Lack of 3D support is not really a show-stopper for most corporations. Getting deployment issues, table, and charting issues fixed would tend to take higher precedence. I think Zonski and others have covered most of the deployment-related issues, and there have been a number of issues filed to improve things. If Java 8 is due in September, it won't hit most corporate desktops until Q1 of 2014. If we have fixes for JNLP, applets, and other deployment issues and security issues, and are wowed enough in September, then there might be some reason for companies to continue to install Java on the desktop (either to prompt the upgrade to 8, or to at least upgrade to the latest version of 7). There's been plenty of bad press lately, which have prompted some companies to either remove Java from the desktop, or lock it down at the firewall. Admittedly, I'd like to see that situation change, and I'm looking for useful counter-arguments. Cheers, Mark On Sat, Mar 16, 2013 at 9:58 AM, Konrad Zuse wrote: > You are mentioning a few things at once. > > Some people don't upgrade their Java because they don't need to. Why > should I update to Javas 7, if Java 6 suffices all of my needs? why pay > some coder to re-code everything when we don't need to? Also there are > companies that probably still run Java 1.2, from 15 years ago :p. Most > companies don't use the latest and greatest. Adaption time is when you > want to adapt. If your company needs 3D support via JavaFX it will be > ready for the release, or even build using the beta-builds currently > available. > > > You keep saying "JavaFX fixes" what "fix" are you looking for? The > changes in JavaFX are the language itself, 3D support, and all of the > additions we'vebeen waiting for. They aren't going to throw that into 7, > because there is no point to. > > ------------------------------ > Date: Sat, 16 Mar 2013 09:52:07 -0700 > Subject: Re: JavaFX Update Question > From: phidias51 at gmail.com > To: thekonradzuse at hotmail.com > CC: openjfx-dev at openjdk.java.net > > > Unfortunately, most organizations of any size don't adopt a technology as > soon as it's released. Witness the fact that the switch from 1.4 to 5 or 6 > took more than 4 years to accomplish and there are still organizations out > there running 1.4. The typical lag between a release and adoption is a > minimum of 6 months. The only exception is for security-related patches. > Which brings me back to my original question, if JavaFX fixes are deployed > along with the security patches, then we'll start to see the benefits > sooner rather than later. > > Cheers, > > Mark > > > > On Sat, Mar 16, 2013 at 9:32 AM, Konrad Zuse wrote: > > http://jdk8.java.net/download.html > > As others have said no changes are being made to 7, what's the point since > we are all prepping for 8's release at the end of the year. Make sure to > be updated with the beta builds as new builds come out every 1-2 weeks I > believe. If you find any bugs, or have suggestions/tweaks hit up JIRA for > JavaFX http://javafx-jira.kenai.com/secure/Dashboard.jspa > > > > From phidias51 at gmail.com Sat Mar 16 11:58:38 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Sat, 16 Mar 2013 11:58:38 -0700 Subject: JavaFX Update Question Message-ID: Applets still get a fair amount of usage behind the firewall. But JNLP really simplifies deployment. Most of the recent focus on deployment has been on building native artifacts. But they are often dependent on having a VM with the appropriate OS available. It think most of us would like to be able to build artifacts on a single OS, or have a server- or cloud-based install builder capable of building for all of the platforms you want. I think Zonski discussed this on an earlier thread, and did the topic more justice than I'm doing. Cheers, Mark On Sat, Mar 16, 2013 at 10:55 AM, Konrad Zuse wrote: > I agree I have noticed some issues with charts, but no table issues yet. > FX is still new in the grand scheme(2.0), as it's only 1 year old. As for > Java issues and "Vulnerabilities" those only happened with Applets as far > as I know, and 7.13-15 was meant to fix a lot of those issues. Most people > say Applets are dead anyways, but i would like to see fixes where we don't > have to discard parts of our language because they can cause bugs... > > I honestly don't think the vulnerabilites in applets even hurt companies. > Java bumped over C in the past 2 moths on TIOBE's index, you would think > Java would tank after the vulnerability issue... Not seeing it. > > Personally I'd like to see more push on the Mobile front, not too sure > honestly which open community is dealing with it... I know there are some > Ex-Sun coders who are making an OpenSource port, but I hear OpenJDK is > going to be doing some as well? > > ------------------------------ > Date: Sat, 16 Mar 2013 10:44:57 -0700 > > Subject: Re: JavaFX Update Question > From: phidias51 at gmail.com > To: thekonradzuse at hotmail.com; openjfx-dev at openjdk.java.net > > > Hi Konrad, > Actually, I've only been talking about the availability of high priority > bug fixes in Java 7 patch releases. Lack of 3D support is not really a > show-stopper for most corporations. Getting deployment issues, table, and > charting issues fixed would tend to take higher precedence. I think Zonski > and others have covered most of the deployment-related issues, and there > have been a number of issues filed to improve things. > > If Java 8 is due in September, it won't hit most corporate desktops until > Q1 of 2014. If we have fixes for JNLP, applets, and other deployment issues > and security issues, and are wowed enough in September, then there might be > some reason for companies to continue to install Java on the desktop > (either to prompt the upgrade to 8, or to at least upgrade to the latest > version of 7). > > There's been plenty of bad press lately, which have prompted some > companies to either remove Java from the desktop, or lock it down at the > firewall. Admittedly, I'd like to see that situation change, and I'm > looking for useful counter-arguments. > > Cheers, > > Mark > > > > On Sat, Mar 16, 2013 at 9:58 AM, Konrad Zuse wrote: > > You are mentioning a few things at once. > > Some people don't upgrade their Java because they don't need to. Why > should I update to Javas 7, if Java 6 suffices all of my needs? why pay > some coder to re-code everything when we don't need to? Also there are > companies that probably still run Java 1.2, from 15 years ago :p. Most > companies don't use the latest and greatest. Adaption time is when you > want to adapt. If your company needs 3D support via JavaFX it will be > ready for the release, or even build using the beta-builds currently > available. > > > You keep saying "JavaFX fixes" what "fix" are you looking for? The > changes in JavaFX are the language itself, 3D support, and all of the > additions we'vebeen waiting for. They aren't going to throw that into 7, > because there is no point to. > > ------------------------------ > Date: Sat, 16 Mar 2013 09:52:07 -0700 > Subject: Re: JavaFX Update Question > From: phidias51 at gmail.com > To: thekonradzuse at hotmail.com > CC: openjfx-dev at openjdk.java.net > > > Unfortunately, most organizations of any size don't adopt a technology as > soon as it's released. Witness the fact that the switch from 1.4 to 5 or 6 > took more than 4 years to accomplish and there are still organizations out > there running 1.4. The typical lag between a release and adoption is a > minimum of 6 months. The only exception is for security-related patches. > Which brings me back to my original question, if JavaFX fixes are deployed > along with the security patches, then we'll start to see the benefits > sooner rather than later. > > Cheers, > > Mark > > > > On Sat, Mar 16, 2013 at 9:32 AM, Konrad Zuse wrote: > > http://jdk8.java.net/download.html > > As others have said no changes are being made to 7, what's the point since > we are all prepping for 8's release at the end of the year. Make sure to > be updated with the beta builds as new builds come out every 1-2 weeks I > believe. If you find any bugs, or have suggestions/tweaks hit up JIRA for > JavaFX http://javafx-jira.kenai.com/secure/Dashboard.jspa > > > > > From pavel.safrata at oracle.com Mon Mar 18 02:22:11 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 18 Mar 2013 10:22:11 +0100 Subject: Duplicating a Node In-Reply-To: <5143634D.9050504@xs4all.nl> References: <5143634D.9050504@xs4all.nl> Message-ID: <5146DCC3.8010701@oracle.com> Hi John, I tried to use reflection on node with PerspectiveTransform and I don't see anything wrong with it - no alternating size, no incorrect reflection. Could you please elaborate on what you are trying to achieve? Code that I used: Rectangle rect = new Rectangle(100, 50, Color.RED); Reflection r = new Reflection(); r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, 0, 80)); rect.setEffect(r); Regards, Pavel On 15.3.2013 19:07, John Hendrikx wrote: > Hi list, > > I'm trying to achieve an effect that requires me to make a copy of a > Node, apply some effect(s) on it (PerspectiveTransform, Clip, Blend > and perhaps DisplacementMap) and place it in the same scenegraph > together with the original. > > It is very similar to what Reflection achieves, but without > alternating the size of the Node, and without the limitations > (specifically, creating the correct Reflection for an object that has > a PerspectiveTransform applied to it already cannot be done with > Reflection). > > I would prefer not to have to make an actual copy of the Node, as they > might get out of sync and not display the same content when they > should be. Something like a NodeReference class, that takes another > Node as parameter but applies different effects/clips/transforms. > > Since the code I'm using for this is based on Cells getting laid out, > I'm toying with the idea of actually asking the provider of those > cells twice for the same cell and applying different transformations > on each, but they might get out of sync and it seems there should be a > better way. > > Any ideas or suggestions at how I could best achieve this, or would it > be a new feature? > > --John From hang.vo at oracle.com Mon Mar 18 02:34:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Mar 2013 09:34:11 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28735: Cover FXCollections methods with unit tests Message-ID: <20130318093422.E37C64820B@hg.openjdk.java.net> Changeset: 69643789d32a Author: Radko Najman Date: 2013-03-18 10:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/69643789d32a RT-28735: Cover FXCollections methods with unit tests ! javafx-beans/src/javafx/collections/FXCollections.java ! javafx-beans/test/javafx/collections/FXCollectionsTest.java + javafx-beans/test/javafx/collections/ObservableListEmptyTest.java + javafx-beans/test/javafx/collections/ObservableListIteratorTest.java - javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableListTest.java - javafx-beans/test/javafx/collections/ObservableListTestBase.java - javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java - javafx-beans/test/javafx/collections/ObservableList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMapTest.java - javafx-beans/test/javafx/collections/ObservableMapTestBase.java - javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/ObservableSetTest.java - javafx-beans/test/javafx/collections/ObservableSetTestBase.java - javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIteratorTest.java - javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListTest.java - javafx-beans/test/javafx/collections/ObservableSubListTestBase.java - javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java ! javafx-beans/test/javafx/collections/TestedObservableLists.java + javafx-beans/test/javafx/collections/TestedObservableMaps.java + javafx-beans/test/javafx/collections/TestedObservableSets.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMapTest.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java From hang.vo at oracle.com Mon Mar 18 14:04:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Mar 2013 21:04:29 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130318210441.BBF2448227@hg.openjdk.java.net> Changeset: 0c08ba3460a0 Author: jgiles Date: 2013-03-18 07:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0c08ba3460a0 RT-29016: CheckBoxTreeItem doesn't have unit tests (this changeset adds ~39 unit tests for CheckBoxTreeItem) ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java + javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java Changeset: 830567b6001f Author: jgiles Date: 2013-03-19 09:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/830567b6001f First batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/ParameterisedPrebuiltCellTest.java Changeset: 3ff4d721bc61 Author: jgiles Date: 2013-03-19 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3ff4d721bc61 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Mon Mar 18 16:18:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Mar 2013 23:18:46 +0000 Subject: hg: openjfx/8/controls/rt: CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis Message-ID: <20130318231852.AC8164822C@hg.openjdk.java.net> Changeset: 54ade0062868 Author: Alexander Kouznetsov Date: 2013-03-18 16:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/54ade0062868 CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Mon Mar 18 17:05:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 00:05:05 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130319000515.2A5AE4822D@hg.openjdk.java.net> Changeset: a6ad35da022e Author: Alexander Kouznetsov Date: 2013-03-18 16:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a6ad35da022e javafx-ui-controls-tests: get rid of <> diamond operators to stay with 1.7 source level ! javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: f80b0ddaad6b Author: Alexander Kouznetsov Date: 2013-03-18 16:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f80b0ddaad6b CustomColorDialog: Made things private to ensure proper encapsulation. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java From swpalmer at gmail.com Mon Mar 18 17:22:08 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 18 Mar 2013 20:22:08 -0400 Subject: GraphicsContext transform Message-ID: How is GraphicContext.setTransform() intended to be used? There are two method signatures: GraphicContext.setTransform(Affine) GraphicContext.setTransform(double,double,double,double,double,double) The Affine class is documented as something that isn't intended to be used directly. "Note: application developers should not normally use this class directly, but instead use the specific Translate, Scale, Rotate, or Shear transforms instead." The classes that the Affine docs suggest to use are not extending Affine and can't be used with the first method signature. (e.g. Scale) The parameters for the version that takes doubles are documented as: Parameters: mxx - - the X coordinate scaling element of the 3x4 matrix myx - - the Y coordinate shearing element of the 3x4 matrix mxy - - the X coordinate shearing element of the 3x4 matrix myy - - the Y coordinate scaling element of the 3x4 matrix mxt - - the X coordinate translation element of the 3x4 matrix myt - - the Y coordinate translation element of the 3x4 matrix The Scale class does not have methods to matching the names mxt or myt (are these getTx(), getTy()?), but regardless it is still tedious to have to make six method calls on a Scale object to set the transform for a GraphicContext. Shouldn't GraphicsContext.setTransform take a Transform???? Regards, Scott From hang.vo at oracle.com Mon Mar 18 17:34:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 00:34:17 +0000 Subject: hg: openjfx/8/controls/rt: Backed out changeset f80b0ddaad6b Message-ID: <20130319003420.B28FC4822E@hg.openjdk.java.net> Changeset: b6bcfa23f268 Author: Alexander Kouznetsov Date: 2013-03-18 17:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b6bcfa23f268 Backed out changeset f80b0ddaad6b ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java From hang.vo at oracle.com Mon Mar 18 17:49:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 00:49:12 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130319004919.37D824822F@hg.openjdk.java.net> Changeset: dd2fe0f50947 Author: Alexander Kouznetsov Date: 2013-03-18 17:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dd2fe0f50947 Backed out changeset a6ad35da022e ! javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: aa130dbb8265 Author: Alexander Kouznetsov Date: 2013-03-18 17:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/aa130dbb8265 Backed out changeset 54ade0062868 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Mon Mar 18 20:04:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 03:04:17 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130319030435.6102C4823C@hg.openjdk.java.net> Changeset: d117e7743d33 Author: jgiles Date: 2013-03-19 13:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d117e7743d33 RT-28065: Focus is moved on last item when pressing CTRL+A ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 248f00a654a0 Author: jgiles Date: 2013-03-19 15:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/248f00a654a0 RT-29046: Sliders do not allow you to drag from track ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: f3d2aa1925e2 Author: jgiles Date: 2013-03-19 15:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f3d2aa1925e2 Updating source level of javafx-ui-controls netbeans project.xml from 1.6 to 1.7. ! javafx-ui-controls/nbproject/project.xml Changeset: 8a3ba759e08f Author: jgiles Date: 2013-03-19 15:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8a3ba759e08f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Mon Mar 18 20:19:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 03:19:01 +0000 Subject: hg: openjfx/8/controls/rt: Fix unit test failures for multiple selection models. Message-ID: <20130319031904.8B7D04823D@hg.openjdk.java.net> Changeset: a8a615069941 Author: jgiles Date: 2013-03-19 16:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a8a615069941 Fix unit test failures for multiple selection models. ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java From hang.vo at oracle.com Mon Mar 18 20:34:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 03:34:02 +0000 Subject: hg: openjfx/8/controls/rt: Resolve class cast exception in CssStyleHelper where Nodes that were not Parents were being cast to Parent. Casting to Node now instead. Message-ID: <20130319033405.52B4C4823E@hg.openjdk.java.net> Changeset: 5d973fbafa77 Author: jgiles Date: 2013-03-19 16:28 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5d973fbafa77 Resolve class cast exception in CssStyleHelper where Nodes that were not Parents were being cast to Parent. Casting to Node now instead. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java From hang.vo at oracle.com Tue Mar 19 01:04:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 08:04:46 +0000 Subject: hg: openjfx/8/graphics/rt: Rebuilt the native build support for Gradle so that we don't use the makefiles at all anymore, and the native sub projects were removed and instead are just source directories in the graphics project. Everything was tested on Mac, Linux (32bit) and Windows (64 bit but 32 bit JVM). The code needs to be factored and made much better (lots of nasty details were discovered along the way), but at least things are mostly building. On Windows we need a better mechanism for identifying the build paths -- maybe we need to go back to the VSProperties generation routine, but I hope not. Message-ID: <20130319080453.538DC48245@hg.openjdk.java.net> Changeset: a3bfe0d84b14 Author: Richard Bair Date: 2013-03-19 00:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a3bfe0d84b14 Rebuilt the native build support for Gradle so that we don't use the makefiles at all anymore, and the native sub projects were removed and instead are just source directories in the graphics project. Everything was tested on Mac, Linux (32bit) and Windows (64 bit but 32 bit JVM). The code needs to be factored and made much better (lots of nasty details were discovered along the way), but at least things are mostly building. On Windows we need a better mechanism for identifying the build paths -- maybe we need to go back to the VSProperties generation routine, but I hope not. ! build.gradle ! generator.gradle ! settings.gradle From hang.vo at oracle.com Tue Mar 19 01:18:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 08:18:53 +0000 Subject: hg: openjfx/8/controls/rt: Second batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests Message-ID: <20130319081859.7AEFF48246@hg.openjdk.java.net> Changeset: d077f9331707 Author: jgiles Date: 2013-03-19 20:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d077f9331707 Second batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java From hang.vo at oracle.com Tue Mar 19 02:33:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 09:33:52 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-28853: Setting eventDispatcher to null causes NPE later (in event handling) Message-ID: <20130319093358.12E9848249@hg.openjdk.java.net> Changeset: 2cbe9eff02b2 Author: Lubomir Nerad Date: 2013-03-19 10:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2cbe9eff02b2 Fix for RT-28853: Setting eventDispatcher to null causes NPE later (in event handling) ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java From hang.vo at oracle.com Tue Mar 19 03:04:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 10:04:00 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: update of input parametrs checks in Pisces renderer Message-ID: <20130319100403.CA70B4824B@hg.openjdk.java.net> Changeset: fc1e38c49db7 Author: Martin Soch Date: 2013-03-19 10:58 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc1e38c49db7 SW pipeline: update of input parametrs checks in Pisces renderer ! prism-sw-native/include/PiscesRenderer.h ! prism-sw-native/include/PiscesRenderer.inl ! prism-sw-native/include/PiscesUtil.h ! prism-sw-native/src/JPiscesRenderer.c ! prism-sw/src/com/sun/pisces/GradientColorMap.java ! prism-sw/src/com/sun/pisces/PiscesRenderer.java From hang.vo at oracle.com Tue Mar 19 07:18:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 14:18:50 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: stroke shouldn't be applied when rendering glyph-list (RT-27211) Message-ID: <20130319141856.B020A48250@hg.openjdk.java.net> Changeset: 0d29aa4bde9c Author: Martin Soch Date: 2013-03-19 15:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0d29aa4bde9c SW pipeline: stroke shouldn't be applied when rendering glyph-list (RT-27211) ! prism-sw/src/com/sun/prism/sw/SWGraphics.java From hjohn at xs4all.nl Tue Mar 19 08:15:26 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 19 Mar 2013 16:15:26 +0100 Subject: Duplicating a Node In-Reply-To: <5146DCC3.8010701@oracle.com> References: <5143634D.9050504@xs4all.nl> <5146DCC3.8010701@oracle.com> Message-ID: <5148810E.40502@xs4all.nl> On 18/03/2013 10:22, Pavel Safrata wrote: > Hi John, > I tried to use reflection on node with PerspectiveTransform and I > don't see anything wrong with it - no alternating size, no incorrect > reflection. Could you please elaborate on what you are trying to > achieve? Code that I used: > > Rectangle rect = new Rectangle(100, 50, Color.RED); > Reflection r = new Reflection(); > r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, > 0, 80)); > rect.setEffect(r); Look at the reflection for this Rectangle instead: Rectangle rect = new Rectangle(100, 50, Color.RED); Reflection r = new Reflection(); r.setInput(new PerspectiveTransform(50, 40, 100, 50, 100, 70, 50, 80)); rect.setEffect(r); Notice that the Reflection is not what you'd expect for a Node that has the appearance of being 3D. So, that is not the problem. It is perfectly possible to create a Reflection from an object that has a PerspectiveTransform applied to it. The problem is that the reflection created is simplistic in that it assumes the object must be reflected in a horizontal line somewhere below the object (which is fine for 2D stuff, but not if you are trying to make your Nodes look 3D with reflections). Please see http://www.youtube.com/watch?v=8Mb15bOwIyE and look how the reflections there are exactly attached to the bottom of PerspectiveTransform'ed Nodes, no spacing. When you apply a PerspectiveTransform, the idea is to make the object look 3D. The Reflection therefore must also be 3D, which means you cannot just create it by copying an upside-down image of the object below the PerspectiveTransformed object. Instead the Reflection should also be 3D and the line it should reflect in is the bottom line of the object AFTER the PerspectiveTransform was applied (and this line is not always horizontal). Here's some ASCII art: OOOO OOOOOOOO OOOOOOOO OOOOOOOO OOOORRRR RRRRRRRR RRRRRRRR RRRRRR RRR Instead of: OOOO OOOOOOOO OOOOOOOO OOOOOOOO OOOO RRRR RRRRRRRR RRRRRRRR RRRRRRRR RRRR Now, it is possible to achieve this by reversing the inputs, first doing the Reflection, then looking at how Reflection changed the Node, then applying a PerspectiveTransform that gets the correct 3D result. However, this is very cumbersome, makes assumptions about how Reflection will change your Node and does not allow for creation of Reflections for Objects that have more than just a rotation on the Y axis applied to them. This is why I really need something (an Effect or NodeReference) that could create a duplicate of a Node :) --John > > Regards, > Pavel > > On 15.3.2013 19:07, John Hendrikx wrote: >> Hi list, >> >> I'm trying to achieve an effect that requires me to make a copy of a >> Node, apply some effect(s) on it (PerspectiveTransform, Clip, Blend >> and perhaps DisplacementMap) and place it in the same scenegraph >> together with the original. >> >> It is very similar to what Reflection achieves, but without >> alternating the size of the Node, and without the limitations >> (specifically, creating the correct Reflection for an object that has >> a PerspectiveTransform applied to it already cannot be done with >> Reflection). >> >> I would prefer not to have to make an actual copy of the Node, as >> they might get out of sync and not display the same content when they >> should be. Something like a NodeReference class, that takes another >> Node as parameter but applies different effects/clips/transforms. >> >> Since the code I'm using for this is based on Cells getting laid out, >> I'm toying with the idea of actually asking the provider of those >> cells twice for the same cell and applying different transformations >> on each, but they might get out of sync and it seems there should be >> a better way. >> >> Any ideas or suggestions at how I could best achieve this, or would >> it be a new feature? >> >> --John > From hang.vo at oracle.com Tue Mar 19 09:49:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 16:49:05 +0000 Subject: hg: openjfx/8/controls/rt: 6 new changesets Message-ID: <20130319164931.59D5C48256@hg.openjdk.java.net> Changeset: bc859a872a95 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bc859a872a95 RT-28997: have SimpleStyleableProperty extend StyleableProperty. Patch supplied by Danno Ferrin (danno.ferrin at shemnon.com), reviewed by David Grieve. ! .idea/compiler.xml ! .idea/libraries/jfxrt_binary_stub.xml ! .idea/modules.xml ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java Changeset: 222a76ee6a38 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/222a76ee6a38 RT-29031: @Ignore Node_effectiveOrientation_Css_Test ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: 1e478f14d2f2 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1e478f14d2f2 RT-29019: check for null or empty style-class before calling StyleClassSet.getStyleClass ! javafx-ui-common/src/com/sun/javafx/css/StyleClassSet.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: e7e4b09677e5 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e7e4b09677e5 RT-28992: additional null checks in StyleManager#removeFromCacheMap ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: dec15223148f Author: Paru Somashekar Date: 2013-03-19 09:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dec15223148f RT-23457 MenuItems should not be selected when a mouse move and mouse up occurs. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 6a275aaf415f Author: Paru Somashekar Date: 2013-03-19 09:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6a275aaf415f RT-21138 BarChart - negative data item is added, animation starts from positive value ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java From hang.vo at oracle.com Tue Mar 19 10:04:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 17:04:17 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130319170426.3513F48257@hg.openjdk.java.net> Changeset: 1b6eab7f1f72 Author: mo.chicharro Date: 2013-03-19 16:56 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1b6eab7f1f72 Fix for RT-28503 - Modena: TreeView disclosure arrow is wrong shape ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 0b251608ae45 Author: mo.chicharro Date: 2013-03-19 17:00 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0b251608ae45 Fix for RT-29069 - Modena: Text inside TreeTableView cells sits 1 pixel too high ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Tue Mar 19 10:34:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 17:34:26 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130319173438.4EB894825B@hg.openjdk.java.net> Changeset: 19a9210e89e2 Author: hudson Date: 2013-03-14 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19a9210e89e2 Added tag 8.0-b81 for changeset f114202c0208 ! .hgtags Changeset: bca7b8cc76b8 Author: jgodinez Date: 2013-03-19 10:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bca7b8cc76b8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java - javafx-beans/test/javafx/collections/ObservableListTestBase.java - javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java - javafx-beans/test/javafx/collections/ObservableList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMapTestBase.java - javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java - javafx-beans/test/javafx/collections/ObservableSetTestBase.java - javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java - javafx-beans/test/javafx/collections/ObservableSubListTestBase.java - javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java From hang.vo at oracle.com Tue Mar 19 10:34:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 17:34:26 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130319173438.407EB4825A@hg.openjdk.java.net> Changeset: e78a64bc1998 Author: David Grieve Date: 2013-03-19 13:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e78a64bc1998 revert unintentional changes to rt/.idea files ! .idea/compiler.xml ! .idea/libraries/jfxrt_binary_stub.xml ! .idea/modules.xml Changeset: c215a5924b33 Author: David Grieve Date: 2013-03-19 13:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c215a5924b33 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt From hang.vo at oracle.com Tue Mar 19 11:04:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 18:04:19 +0000 Subject: hg: openjfx/8/controls/rt: Fixed typo in CSS Message-ID: <20130319180425.9716A4825D@hg.openjdk.java.net> Changeset: ee86f25fc1b3 Author: mo.chicharro Date: 2013-03-19 17:59 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ee86f25fc1b3 Fixed typo in CSS ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From omeuefilipe at gmail.com Tue Mar 19 11:09:40 2013 From: omeuefilipe at gmail.com (Filipe Portes) Date: Tue, 19 Mar 2013 15:09:40 -0300 Subject: Drombler FX: building modular JavaFX applications with OSGi and Maven In-Reply-To: <1942867.C2SCBe4CpO@shire> References: <1468973.LLaJQ6I9jc@shire> <1942867.C2SCBe4CpO@shire> Message-ID: Hi everyone, sorry for revive this old thread. I made some update in ModuleFX, now its more simple, run with JavaFX 2.2 inside the JDK 7 and in theory(need more tests) works in any OS. https://github.com/filipeportes/ModuleFX Best Regards. On Thu, Dec 20, 2012 at 5:35 PM, Florian Brunner wrote: > Hi Tom, hi Filipe, > > Sorry, for the late answer. I somehow didn't get these e-mails, but I just > found them in the Internet. > > Yes, all you need to do to make the JavaFX classes accessible by OSGi is > to specify "org.osgi.framework.system.packages.extra" and pass this > information to org.osgi.framework.launch.FrameworkFactory.newFramework in > your OSGi launcher. > > You can find the relevant code in these projects: > > > https://sourceforge.net/p/drombler/drombler-fx/ci/e82071dc633c32da770ee600ac421f9bb89ad1d9/tree/drombler-fx-startup-main/ > > and > > > https://sourceforge.net/p/drombler/drombler-acp/ci/f2c9da0d549677805fbcb3c5250e139a5d8925fb/tree/drombler-acp-startup-main/ > > Or in other words: since JavaFX is installed separately on the end user > machines (as part of the JRE), we can access them as "system packages" > (similar to all the other classes of the standard Java library) rather than > wrapping JavaFX up somehow as a bundle (which we don't do for the other > classes of the standard Java library either). > > Note that even this shoudn't be necessary once JavaFX gets part of the > standard JDK and your OSGi implementation specifies > "org.osgi.framework.system.packages" accordingly. > > The next step is to make sure JavaFX gets started properly. > > For this you need the following Manifest entries in your main jar: > > JavaFX-Application-Class: org.drombler.fx.startup.main.Main > JavaFX-Version: 2.0 > Main-Class: com.javafx.main.Main > > where org.drombler.fx.startup.main.Main is an OSGi launcher for JavaFX. > > The drombler-fx-startup-main project mentioned above specifies the > Manifest entries to be generated in the POM and the Drombler FX Maven > Plugin adds the com.javafx.main.* classes to the final main jar (similar to > what the Ant script provided by JavaFX is doing). The plugin also copies > all direct and transitive dependencies with scope "compile" or "runtime" to > the deployment directory. > > Here is the relevant project: > > > https://sourceforge.net/p/drombler/drombler-fx/ci/e82071dc633c32da770ee600ac421f9bb89ad1d9/tree/drombler-fx-maven-plugin/ > > Have a look at CreateStandaloneZipMojo. > > So far no JavaFX class has been used (apart from com.javafx.main.Main > specified the Manifest). > > The next step is to call javafx.application.Application.launch. > > Drombler FX does this in a simple OSGi bundle using OSGi Declarative > Services (using Apache Felix SCR annotations). > > Here is the relevant project: > > > https://sourceforge.net/p/drombler/drombler-fx/ci/e82071dc633c32da770ee600ac421f9bb89ad1d9/tree/drombler-fx-core-application/ > > Have a look at the following classes: FXApplicationLauncher and > ModularApplication > > Again, if you're using Drombler FX you will get all of this out-of-the-box > and several extension points as well. > > - Florian > > > Hi tom, > > > > I follow your projects for long time, really like... i'm such a fan!! > > > > I created the moduleFX for the 2.1 JavaFX, and JDK version without > > preinstalled JavaFX, never tested for the newer versions... for sure I'll > > look at florian domblerFX to learn how to manage this problem!! Thanks > for > > the tips!! > > > > On Thu, Dec 13, 2012 at 7:24 PM, Tom Schindl >wrote: > > > > Hi Filipe, > > > > From code inspection I think Florians solution is the way to get JavaFX > > running in Felix because he's modifying > > "org.osgi.framework.system.packages.extra". If I'm not 100% mistaken your > > solution will hit what I describe at > > http://tomsondev.bestsolution.at/2012/08/01/javafx-2-2-and-osgi/ in the > > "Straight Repackageing" section. > > > > In short: If a user runs with your solution on a JDK which has JavaFX > > preinstalled the native code from the JDK will be picked up and the > > Java-Code from your module-fx and there are good chances that they don't > > match! > > > > If I got the solution from Florian right he's using > > org.osgi.framework.system.packages.extra to teach OSGi the new packages > and > > somehow modifies the application classpath, or something similar. > > > > My Equinox solution on the other hand has the advantage that you don't > have > > to control the bootstraping which is e.g. the case when you want to use > > JavaFX inside an Eclipse Plugin. > > > > Tom > > > > Am 13.12.12 18:00, schrieb Filipe Portes: > > > > Hi everyone, > > > > I create a simple project called ModuleFX that also make you capable of > run > > JavaFX application over OSGI, It's still very simple, but if anyone get > > intersted here's the link: https://github.com/filipeportes/ModuleFX > > > > On Sun, Dec 9, 2012 at 11:09 AM, Florian Brunner > > > Hi everybody, > > > > I'm happy to announce the availabilty of a first Early Access version of > > Drombler FX. Drombler FX is a modular Rich Client Platform for JavaFX. > > > > You can read more about it here: http://puces- > > blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html > > > > There's a Getting Started page which explains how to create, build and > run a > > Drombler FX sample application with a few simple steps: > > > > http://wiki.drombler.org/GettingStarted > > > > - Florian > > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH > > > > ------------------------------------------------------------------------ > tom > > schindl gesch?ftsf?hrer/CEO > > > > ------------------------------------------------------------------------ > > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > > http://www.BestSolution.at phone ++43 512 935834 > > > > -- Filipe Portes - @filipeportes Java Architect - Senior Java EE/Web > > JUGLeader Gojava - @gojava > -- Filipe Portes - @filipeportes Java Architect - Senior Java EE/Web JUGLeader Gojava - @gojava From hang.vo at oracle.com Tue Mar 19 11:18:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 18:18:47 +0000 Subject: hg: openjfx/8/controls/rt: Fixed: RT-29074: When child is more css dirty than parent that gets lost Message-ID: <20130319181850.B485648260@hg.openjdk.java.net> Changeset: 98b8f8052c8b Author: "Jasper Potts" Date: 2013-03-19 11:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/98b8f8052c8b Fixed: RT-29074: When child is more css dirty than parent that gets lost ! javafx-ui-common/src/javafx/scene/Parent.java From hang.vo at oracle.com Tue Mar 19 13:49:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 20:49:37 +0000 Subject: hg: openjfx/8/controls/rt: CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis Message-ID: <20130319204945.4352F48268@hg.openjdk.java.net> Changeset: c2ebe930f201 Author: Alexander Kouznetsov Date: 2013-03-19 13:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c2ebe930f201 CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Tue Mar 19 14:34:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Mar 2013 21:34:22 +0000 Subject: hg: openjfx/8/controls/rt: 30 new changesets Message-ID: <20130319213555.C1D394826E@hg.openjdk.java.net> Changeset: 19a9210e89e2 Author: hudson Date: 2013-03-14 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/19a9210e89e2 Added tag 8.0-b81 for changeset f114202c0208 ! .hgtags Changeset: fe5a6223ed42 Author: rbair Date: 2013-03-12 09:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fe5a6223ed42 RT-28932: TransformChangedEvent TRANSFORM_CHANGED event type has the wrong name Summary: The TransformChangedEvent reused the "ACTION" name, which results in an exception if both the TransformChangedEvent and ActionEvent are used in the same app. Unit test supplied with the fix. ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformChangedEventTest.java Changeset: b93620846ba4 Author: rbair Date: 2013-03-12 16:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b93620846ba4 Merge Changeset: 5fe0d1ba95aa Author: Martin Sladecek Date: 2013-03-13 10:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5fe0d1ba95aa RT-28718 Support permutation changes after add/remove changes in ObservableListBase ! javafx-beans/src/javafx/collections/ListChangeBuilder.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java ! javafx-beans/test/javafx/collections/MockListObserver.java Changeset: abe7e78f8bad Author: Martin Sladecek Date: 2013-03-13 10:24 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/abe7e78f8bad Dead code cleanup ! javafx-beans/src/javafx/collections/ListChangeBuilder.java Changeset: f9de458279a2 Author: dmasada Date: 2013-03-13 08:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f9de458279a2 RT-28764 Ensemble8: use ConditionalFeature to decide what demos to show ! apps/samples/Ensemble8/src/app/ensemble/SampleCategory.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/ensemble/search/IndexSearcher.java + apps/samples/Ensemble8/src/app/ensemble/util/FeatureChecker.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/CodeGenerationUtils.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/Sample.java ! apps/samples/Ensemble8/src/generated/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/charts/bar/audio/AudioBarChartApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/advancedmedia/AdvancedMediaApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/audioclip/AudioClipApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/scenegraph/events/multitouch/MultiTouchApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/htmleditor/HTMLEditorApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/webview/WebViewApp.java Changeset: e403dc5b195c Author: jgodinez Date: 2013-03-13 09:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e403dc5b195c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: d1dbad1c94b9 Author: rbair Date: 2013-03-13 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d1dbad1c94b9 Updated gradle build to work on linux ! build.gradle Changeset: d72a3b54194d Author: rbair Date: 2013-03-13 11:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d72a3b54194d [TEST-ONLY] Updated the test to use a local file instead of package.html because the new build system doesn't put javadoc files in the same places as class files, so this failed. ! javafx-ui-common/test/unit/com/sun/javafx/css/converters/URLConverterTest.java + javafx-ui-common/test/unit/com/sun/javafx/css/converters/some.txt Changeset: 4158528794cd Author: rbair Date: 2013-03-13 11:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4158528794cd RT-28886: Image URL_QUICKMATCH would be better as a cached Pattern Contributed By:neugens ! build.gradle ! javafx-ui-common/src/javafx/scene/image/Image.java Changeset: 61f4628db358 Author: Felipe Heidrich Date: 2013-03-13 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/61f4628db358 [Eclipse only] adding xtext nature to rt project ! .project Changeset: 1c16ab0343bf Author: Felipe Heidrich Date: 2013-03-13 13:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1c16ab0343bf minor: fix double semicolon in css file ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 4d82f948c42f Author: Daniel Blaukopf Date: 2013-03-13 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4d82f948c42f RT-28943 Use ConditionalFeatures instead of PlatformUtil.isEmbedded() ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 88de15f1c7d9 Author: Daniel Blaukopf Date: 2013-03-13 15:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/88de15f1c7d9 Fixed typo that broke the build ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java Changeset: 7a3db91a4561 Author: rbair Date: 2013-03-13 15:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7a3db91a4561 RT-28968: javafx-beans not being tested Summary: Now testing javafx-beans again. There were 4 failing tests which were ignored pursuant to a fix for RT-28969 ! javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java Changeset: 3d3dd969e631 Author: Martin Sladecek Date: 2013-03-14 10:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3d3dd969e631 Fixed javafx collections tests + minor code fix that was found after tests were fixed. ! javafx-beans/src/com/sun/javafx/collections/VetoableListDecorator.java ! javafx-beans/src/javafx/collections/ListChangeListener.java ! javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java ! javafx-beans/test/javafx/collections/MockListObserver.java Changeset: 4d5247c56a5d Author: Petr Pchelko Date: 2013-03-14 16:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4d5247c56a5d RT-24453 Mac: ComboBox, ChoiceBox, ListView when selected cause NetBeans RCP Application menubar to disappear Reviewed-by: Anthony ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassSystemMenu.java Changeset: de3ebe903c58 Author: Petr Pchelko Date: 2013-03-14 17:04 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/de3ebe903c58 RT-28542 cancelling DirectoryChooser selection leads to NPE Reviewed-by: Anthony ! glass/glass/src/com/sun/glass/ui/gtk/GtkCommonDialogs.java ! glass/glass/src/com/sun/glass/ui/win/WinCommonDialogs.java Changeset: c2e2112b523c Author: Eva Krejcirova Date: 2013-03-14 15:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c2e2112b523c RT-26547: Scenegraph doesn't handle null values passed for enum arguments (and other values) ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/DropShadow.java ! javafx-ui-common/src/javafx/scene/effect/InnerShadow.java ! javafx-ui-common/src/javafx/scene/effect/Light.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java ! javafx-ui-common/src/javafx/scene/effect/Shadow.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Arc.java ! javafx-ui-common/test/unit/javafx/scene/effect/ColorInputTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DisplacementMapTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DistantLightTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DropShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/InnerShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/LightingTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/ShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageViewTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/FlowPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/HBoxTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/StackPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/VBoxTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ArcTest.java Changeset: 1a058c3aeb05 Author: Martin Sladecek Date: 2013-03-14 15:33 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1a058c3aeb05 RT-28961 BooleanExpression created by methods and(), or() are not cleaned ! javafx-beans/nbproject/project.xml ! javafx-beans/src/javafx/beans/binding/Bindings.java Changeset: c01cba0a1e6f Author: Martin Sladecek Date: 2013-03-14 15:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c01cba0a1e6f merge Changeset: eb2fd3306c9a Author: snorthov Date: 2013-03-14 16:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/eb2fd3306c9a RT-28993: can't debug on mac inside IDE ! glass/glass-lib-macosx/src/GlassTimer.m Changeset: d0f2b546a80c Author: dmasada Date: 2013-03-15 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d0f2b546a80c RT-28991 Ensemble8: HTMLEditor needs to fit on screen better ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/htmleditor/HTMLEditorApp.java Changeset: 69643789d32a Author: Radko Najman Date: 2013-03-18 10:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/69643789d32a RT-28735: Cover FXCollections methods with unit tests ! javafx-beans/src/javafx/collections/FXCollections.java ! javafx-beans/test/javafx/collections/FXCollectionsTest.java + javafx-beans/test/javafx/collections/ObservableListEmptyTest.java + javafx-beans/test/javafx/collections/ObservableListIteratorTest.java - javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableListTest.java - javafx-beans/test/javafx/collections/ObservableListTestBase.java - javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java - javafx-beans/test/javafx/collections/ObservableList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMapTest.java - javafx-beans/test/javafx/collections/ObservableMapTestBase.java - javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/ObservableSetTest.java - javafx-beans/test/javafx/collections/ObservableSetTestBase.java - javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIteratorTest.java - javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListTest.java - javafx-beans/test/javafx/collections/ObservableSubListTestBase.java - javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java ! javafx-beans/test/javafx/collections/TestedObservableLists.java + javafx-beans/test/javafx/collections/TestedObservableMaps.java + javafx-beans/test/javafx/collections/TestedObservableSets.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMapTest.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java Changeset: a3bfe0d84b14 Author: Richard Bair Date: 2013-03-19 00:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a3bfe0d84b14 Rebuilt the native build support for Gradle so that we don't use the makefiles at all anymore, and the native sub projects were removed and instead are just source directories in the graphics project. Everything was tested on Mac, Linux (32bit) and Windows (64 bit but 32 bit JVM). The code needs to be factored and made much better (lots of nasty details were discovered along the way), but at least things are mostly building. On Windows we need a better mechanism for identifying the build paths -- maybe we need to go back to the VSProperties generation routine, but I hope not. ! build.gradle ! generator.gradle ! settings.gradle Changeset: 2cbe9eff02b2 Author: Lubomir Nerad Date: 2013-03-19 10:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2cbe9eff02b2 Fix for RT-28853: Setting eventDispatcher to null causes NPE later (in event handling) ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java Changeset: fc1e38c49db7 Author: Martin Soch Date: 2013-03-19 10:58 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fc1e38c49db7 SW pipeline: update of input parametrs checks in Pisces renderer ! prism-sw-native/include/PiscesRenderer.h ! prism-sw-native/include/PiscesRenderer.inl ! prism-sw-native/include/PiscesUtil.h ! prism-sw-native/src/JPiscesRenderer.c ! prism-sw/src/com/sun/pisces/GradientColorMap.java ! prism-sw/src/com/sun/pisces/PiscesRenderer.java Changeset: 0d29aa4bde9c Author: Martin Soch Date: 2013-03-19 15:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0d29aa4bde9c SW pipeline: stroke shouldn't be applied when rendering glyph-list (RT-27211) ! prism-sw/src/com/sun/prism/sw/SWGraphics.java Changeset: bca7b8cc76b8 Author: jgodinez Date: 2013-03-19 10:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bca7b8cc76b8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java - javafx-beans/test/javafx/collections/ObservableListTestBase.java - javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java - javafx-beans/test/javafx/collections/ObservableList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMapTestBase.java - javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java - javafx-beans/test/javafx/collections/ObservableSetTestBase.java - javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java - javafx-beans/test/javafx/collections/ObservableSubListTestBase.java - javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java Changeset: 9cd4222cfa62 Author: Paru Somashekar Date: 2013-03-19 22:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9cd4222cfa62 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java From phdoerfler at gmail.com Tue Mar 19 15:33:54 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Tue, 19 Mar 2013 23:33:54 +0100 Subject: Threading and Node.lookup Message-ID: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> Hi, does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). Placing those lookups in Platform.runLater suddenly causes them to work. This feels like an arcane bug to me, but I might be missing some core concepts. So - did I miss something or is this a bug? Cheers, Philipp From kevin.rushforth at oracle.com Tue Mar 19 16:30:36 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Mar 2013 16:30:36 -0700 Subject: Threading and Node.lookup In-Reply-To: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> Message-ID: <5148F51C.2020202@oracle.com> > > As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. -- Kevin Philipp D?rfler wrote: > Hi, > > does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? > As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. > > However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). > > Placing those lookups in Platform.runLater suddenly causes them to work. > > This feels like an arcane bug to me, but I might be missing some core concepts. > So - did I miss something or is this a bug? > > Cheers, > Philipp From phdoerfler at gmail.com Tue Mar 19 16:45:14 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Wed, 20 Mar 2013 00:45:14 +0100 Subject: Threading and Node.lookup In-Reply-To: <5148F51C.2020202@oracle.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> Message-ID: <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> Ok, threading aside: Where's my mistake? https://gist.github.com/phdoerfler/5201162 ~ philipp Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >> >> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. > > In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. > > -- Kevin > > > Philipp D?rfler wrote: >> Hi, >> >> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >> >> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >> >> Placing those lookups in Platform.runLater suddenly causes them to work. >> >> This feels like an arcane bug to me, but I might be missing some core concepts. >> So - did I miss something or is this a bug? >> >> Cheers, >> Philipp From kevin.rushforth at oracle.com Tue Mar 19 16:50:04 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Mar 2013 16:50:04 -0700 Subject: Threading and Node.lookup In-Reply-To: <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> Message-ID: <5148F9AC.5050709@oracle.com> One of the scene graph or FXML folks should be able to reply. -- Kevin Philipp D?rfler wrote: > Ok, threading aside: Where's my mistake? > > https://gist.github.com/phdoerfler/5201162 > > ~ philipp > > Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : > > >>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>> >> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >> >> -- Kevin >> >> >> Philipp D?rfler wrote: >> >>> Hi, >>> >>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>> >>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>> >>> Placing those lookups in Platform.runLater suddenly causes them to work. >>> >>> This feels like an arcane bug to me, but I might be missing some core concepts. >>> So - did I miss something or is this a bug? >>> >>> Cheers, >>> Philipp >>> > > From swpalmer at gmail.com Tue Mar 19 16:53:05 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Mar 2013 19:53:05 -0400 Subject: Threading and Node.lookup In-Reply-To: <5148F9AC.5050709@oracle.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> Message-ID: My guess is drop the "#". That's a CSS thing and not part of the ID. Scott On 2013-03-19, at 7:50 PM, Kevin Rushforth wrote: > One of the scene graph or FXML folks should be able to reply. > > -- Kevin > > > Philipp D?rfler wrote: >> Ok, threading aside: Where's my mistake? >> >> https://gist.github.com/phdoerfler/5201162 >> >> ~ philipp >> >> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >> >> >>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>> >>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>> >>> -- Kevin >>> >>> >>> Philipp D?rfler wrote: >>> >>>> Hi, >>>> >>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>> >>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>> >>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>> >>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>> So - did I miss something or is this a bug? >>>> >>>> Cheers, >>>> Philipp >>>> >> >> From phdoerfler at gmail.com Tue Mar 19 16:58:19 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Wed, 20 Mar 2013 00:58:19 +0100 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> Message-ID: And that's what lookup and ID is for, according to Node.idProperty's javadoc: > For example, if a Node is given the id of "myId", then the lookup method can be used to find this node as follows: scene.lookup("#myId");. http://docs.oracle.com/javafx/2/api/javafx/scene/Node.html#idProperty() ~ philipp Am 20.03.2013 um 00:53 schrieb Scott Palmer : > My guess is drop the "#". That's a CSS thing and not part of the ID. > > > Scott > > On 2013-03-19, at 7:50 PM, Kevin Rushforth wrote: > >> One of the scene graph or FXML folks should be able to reply. >> >> -- Kevin >> >> >> Philipp D?rfler wrote: >>> Ok, threading aside: Where's my mistake? >>> >>> https://gist.github.com/phdoerfler/5201162 >>> >>> ~ philipp >>> >>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>> >>> >>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>> >>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>> >>>> -- Kevin >>>> >>>> >>>> Philipp D?rfler wrote: >>>> >>>>> Hi, >>>>> >>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>> >>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>> >>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>> >>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>> So - did I miss something or is this a bug? >>>>> >>>>> Cheers, >>>>> Philipp >>>>> >>> >>> > From swpalmer at gmail.com Tue Mar 19 17:24:05 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Mar 2013 20:24:05 -0400 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> Message-ID: <51BF9233-663C-4796-9E4D-C1C6B605449B@gmail.com> I always guess that wrong :-( I just remembered that something was non-intuitive about it. But I got it backwards this time (again). I always code it *without* the # and then have to scratch my head for a while trying to figure it out. Precisely because the node name does *not* have the # and # is a CSS/XML syntax thing and I'm coding Java not CSS! Oh well, Scott On 2013-03-19, at 7:58 PM, Philipp D?rfler wrote: > And that's what lookup and ID is for, according to Node.idProperty's javadoc: > >> For example, if a Node is given the id of "myId", then the lookup method can be used to find this node as follows: scene.lookup("#myId");. > > http://docs.oracle.com/javafx/2/api/javafx/scene/Node.html#idProperty() > > ~ philipp > > Am 20.03.2013 um 00:53 schrieb Scott Palmer : > >> My guess is drop the "#". That's a CSS thing and not part of the ID. >> >> >> Scott >> >> On 2013-03-19, at 7:50 PM, Kevin Rushforth wrote: >> >>> One of the scene graph or FXML folks should be able to reply. >>> >>> -- Kevin >>> >>> >>> Philipp D?rfler wrote: >>>> Ok, threading aside: Where's my mistake? >>>> >>>> https://gist.github.com/phdoerfler/5201162 >>>> >>>> ~ philipp >>>> >>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>> >>>> >>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>> >>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Philipp D?rfler wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>> >>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>> >>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>> >>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>> So - did I miss something or is this a bug? >>>>>> >>>>>> Cheers, >>>>>> Philipp >>>>>> >>>> >>>> >> > From John_Smith at symantec.com Tue Mar 19 17:30:59 2013 From: John_Smith at symantec.com (John Smith) Date: Tue, 19 Mar 2013 17:30:59 -0700 Subject: Threading and Node.lookup In-Reply-To: <5148F9AC.5050709@oracle.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> +1 to Philipp's question. It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. - John -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Tuesday, March 19, 2013 4:50 PM To: Philipp D?rfler Cc: openjfx-dev at openjdk.java.net List Subject: Re: Threading and Node.lookup One of the scene graph or FXML folks should be able to reply. -- Kevin Philipp D?rfler wrote: > Ok, threading aside: Where's my mistake? > > https://gist.github.com/phdoerfler/5201162 > > ~ philipp > > Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : > > >>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>> >> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >> >> -- Kevin >> >> >> Philipp D?rfler wrote: >> >>> Hi, >>> >>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>> >>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>> >>> Placing those lookups in Platform.runLater suddenly causes them to work. >>> >>> This feels like an arcane bug to me, but I might be missing some core concepts. >>> So - did I miss something or is this a bug? >>> >>> Cheers, >>> Philipp >>> > > From swpalmer at gmail.com Tue Mar 19 17:53:20 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Mar 2013 20:53:20 -0400 Subject: Threading and Node.lookup In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: On 2013-03-19, at 8:30 PM, John Smith wrote: > "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. Yep? I just checked my code, this doesn't return nulls: ? Parent root = FXMLLoader.load(location); Scene scene = new Scene(root); Node top = scene.lookup("#top"); Node background = scene.lookup("#background"); ? The Scene clearly was just constructed and isn't showing or part of a Stage. The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. Scott > +1 to Philipp's question. > > It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. > > With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. > > It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. > > Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. > > - John > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth > Sent: Tuesday, March 19, 2013 4:50 PM > To: Philipp D?rfler > Cc: openjfx-dev at openjdk.java.net List > Subject: Re: Threading and Node.lookup > > One of the scene graph or FXML folks should be able to reply. > > -- Kevin > > > Philipp D?rfler wrote: >> Ok, threading aside: Where's my mistake? >> >> https://gist.github.com/phdoerfler/5201162 >> >> ~ philipp >> >> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >> >> >>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>> >>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>> >>> -- Kevin >>> >>> >>> Philipp D?rfler wrote: >>> >>>> Hi, >>>> >>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>> >>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>> >>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>> >>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>> So - did I miss something or is this a bug? >>>> >>>> Cheers, >>>> Philipp >>>> >> >> From John_Smith at symantec.com Tue Mar 19 18:06:36 2013 From: John_Smith at symantec.com (John Smith) Date: Tue, 19 Mar 2013 18:06:36 -0700 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221678837262@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. It doesn't always work for me: public class LookupTest extends Application { public static void main(String[] args) { Application.launch(args); } @Override public void start(Stage stage) { Button button = new Button("xyzzy"); System.out.println("Before adding to scene: " + button.lookup(".text")); Scene scene = new Scene(button); System.out.println("After adding to scene: " + button.lookup(".text")); stage.setScene(scene); stage.show(); System.out.println("After show: " + button.lookup(".text")); } } Outputs => Before adding to scene: null After adding to scene: null After show: LabeledText at 489863ce[styleClass=text] -----Original Message----- From: Scott Palmer [mailto:swpalmer at gmail.com] Sent: Tuesday, March 19, 2013 5:53 PM To: John Smith Cc: Philipp D?rfler; openjfx-dev at openjdk.java.net List Subject: Re: Threading and Node.lookup On 2013-03-19, at 8:30 PM, John Smith wrote: > "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. Yep. I just checked my code, this doesn't return nulls: . Parent root = FXMLLoader.load(location); Scene scene = new Scene(root); Node top = scene.lookup("#top"); Node background = scene.lookup("#background"); . The Scene clearly was just constructed and isn't showing or part of a Stage. The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. Scott > +1 to Philipp's question. > > It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. > > With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. > > It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. > > Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. > > - John > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin > Rushforth > Sent: Tuesday, March 19, 2013 4:50 PM > To: Philipp D?rfler > Cc: openjfx-dev at openjdk.java.net List > Subject: Re: Threading and Node.lookup > > One of the scene graph or FXML folks should be able to reply. > > -- Kevin > > > Philipp D?rfler wrote: >> Ok, threading aside: Where's my mistake? >> >> https://gist.github.com/phdoerfler/5201162 >> >> ~ philipp >> >> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >> >> >>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>> >>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>> >>> -- Kevin >>> >>> >>> Philipp D?rfler wrote: >>> >>>> Hi, >>>> >>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>> >>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>> >>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>> >>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>> So - did I miss something or is this a bug? >>>> >>>> Cheers, >>>> Philipp >>>> >> >> From swpalmer at gmail.com Tue Mar 19 18:34:58 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Mar 2013 21:34:58 -0400 Subject: Threading and Node.lookup In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221678837262@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <411E73D23DEC4C46BA48F2B6D8BF3D221678837262@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: That's a different test. What is ".text"? Could it be an internal node generated by the Button Skin that doesn't exist until the Skin gets a chance to do it's thing? Scott On 2013-03-19, at 9:06 PM, John Smith wrote: >> I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. > > It doesn't always work for me: > > public class LookupTest extends Application { > public static void main(String[] args) { Application.launch(args); } > @Override public void start(Stage stage) { > Button button = new Button("xyzzy"); > System.out.println("Before adding to scene: " + button.lookup(".text")); > > Scene scene = new Scene(button); > System.out.println("After adding to scene: " + button.lookup(".text")); > > stage.setScene(scene); > stage.show(); > > System.out.println("After show: " + button.lookup(".text")); > } > } > > Outputs => > > Before adding to scene: null > After adding to scene: null > After show: LabeledText at 489863ce[styleClass=text] > > -----Original Message----- > From: Scott Palmer [mailto:swpalmer at gmail.com] > Sent: Tuesday, March 19, 2013 5:53 PM > To: John Smith > Cc: Philipp D?rfler; openjfx-dev at openjdk.java.net List > Subject: Re: Threading and Node.lookup > > On 2013-03-19, at 8:30 PM, John Smith wrote: >> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" > > > I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. > > Yep. I just checked my code, this doesn't return nulls: > > . > Parent root = FXMLLoader.load(location); Scene scene = new Scene(root); Node top = scene.lookup("#top"); Node background = scene.lookup("#background"); . > > The Scene clearly was just constructed and isn't showing or part of a Stage. > The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. > > You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. > > Scott > > > >> +1 to Philipp's question. >> >> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >> >> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >> >> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >> >> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >> >> - John >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin >> Rushforth >> Sent: Tuesday, March 19, 2013 4:50 PM >> To: Philipp D?rfler >> Cc: openjfx-dev at openjdk.java.net List >> Subject: Re: Threading and Node.lookup >> >> One of the scene graph or FXML folks should be able to reply. >> >> -- Kevin >> >> >> Philipp D?rfler wrote: >>> Ok, threading aside: Where's my mistake? >>> >>> https://gist.github.com/phdoerfler/5201162 >>> >>> ~ philipp >>> >>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>> >>> >>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>> >>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>> >>>> -- Kevin >>>> >>>> >>>> Philipp D?rfler wrote: >>>> >>>>> Hi, >>>>> >>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>> >>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>> >>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>> >>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>> So - did I miss something or is this a bug? >>>>> >>>>> Cheers, >>>>> Philipp >>>>> >>> >>> > From hang.vo at oracle.com Tue Mar 19 18:48:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 01:48:43 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130320014855.4DF814827D@hg.openjdk.java.net> Changeset: 20dc17b8fb1e Author: jgiles Date: 2013-03-20 11:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/20dc17b8fb1e RT-28942: HelloTreeView: Editable TreeView doesn't response to double-click ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: 6542027d1b43 Author: jgiles Date: 2013-03-20 14:29 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6542027d1b43 RT-29080: Incorrect height can be calculated for variable height table cells ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: f40c493c859b Author: jgiles Date: 2013-03-20 14:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f40c493c859b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From kevin.rushforth at oracle.com Tue Mar 19 19:35:27 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Mar 2013 19:35:27 -0700 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <5149206F.6080001@oracle.com> > Node background = scene.lookup("#background"); Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. -- Kevin Scott Palmer wrote: > On 2013-03-19, at 8:30 PM, John Smith wrote: > >> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >> > > > I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. > > Yep? I just checked my code, this doesn't return nulls: > > ? > Parent root = FXMLLoader.load(location); > Scene scene = new Scene(root); > Node top = scene.lookup("#top"); > Node background = scene.lookup("#background"); > ? > > The Scene clearly was just constructed and isn't showing or part of a Stage. > The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. > > You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. > > Scott > > > > >> +1 to Philipp's question. >> >> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >> >> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >> >> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >> >> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >> >> - John >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >> Sent: Tuesday, March 19, 2013 4:50 PM >> To: Philipp D?rfler >> Cc: openjfx-dev at openjdk.java.net List >> Subject: Re: Threading and Node.lookup >> >> One of the scene graph or FXML folks should be able to reply. >> >> -- Kevin >> >> >> Philipp D?rfler wrote: >> >>> Ok, threading aside: Where's my mistake? >>> >>> https://gist.github.com/phdoerfler/5201162 >>> >>> ~ philipp >>> >>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>> >>> >>> >>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>> >>>>> >>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>> >>>> -- Kevin >>>> >>>> >>>> Philipp D?rfler wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>> >>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>> >>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>> >>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>> So - did I miss something or is this a bug? >>>>> >>>>> Cheers, >>>>> Philipp >>>>> >>>>> >>> > > From swpalmer at gmail.com Tue Mar 19 20:47:08 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Mar 2013 23:47:08 -0400 Subject: Threading and Node.lookup In-Reply-To: <5149206F.6080001@oracle.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> Message-ID: <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. Scott On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: > > Node background = scene.lookup("#background"); > > Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. > > -- Kevin > > > > Scott Palmer wrote: >> >> On 2013-03-19, at 8:30 PM, John Smith wrote: >> >>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>> >> >> >> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >> >> Yep? I just checked my code, this doesn't return nulls: >> >> ? >> Parent root = FXMLLoader.load(location); >> Scene scene = new Scene(root); >> Node top = scene.lookup("#top"); >> Node background = scene.lookup("#background"); >> ? >> >> The Scene clearly was just constructed and isn't showing or part of a Stage. >> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >> >> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >> >> Scott >> >> >> >> >>> +1 to Philipp's question. >>> >>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>> >>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>> >>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>> >>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>> >>> - John >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>> Sent: Tuesday, March 19, 2013 4:50 PM >>> To: Philipp D?rfler >>> Cc: openjfx-dev at openjdk.java.net List >>> Subject: Re: Threading and Node.lookup >>> >>> One of the scene graph or FXML folks should be able to reply. >>> >>> -- Kevin >>> >>> >>> Philipp D?rfler wrote: >>> >>>> Ok, threading aside: Where's my mistake? >>>> >>>> https://gist.github.com/phdoerfler/5201162 >>>> >>>> ~ philipp >>>> >>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>> >>>> >>>> >>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>> >>>>>> >>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Philipp D?rfler wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>> >>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>> >>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>> >>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>> So - did I miss something or is this a bug? >>>>>> >>>>>> Cheers, >>>>>> Philipp >>>>>> >>>>>> >>>> >> >> From hang.vo at oracle.com Wed Mar 20 00:34:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 07:34:23 +0000 Subject: hg: openjfx/8/graphics/rt: Cleanup, commenting, and simplification of the gradle build. Factored most of the build parameters out into separate gradle files (to act as glorified properties files). Also put in support for cross builds. Given the right armhf.gradle file or armvfp.gradle file we ought to be able to perform cross builds. Added sanity checking code to make sure we fail when attempts are made to cross build on platforms that are not properly supported. Message-ID: <20130320073429.C444248287@hg.openjdk.java.net> Changeset: c54e819cfa5d Author: Richard Bair Date: 2013-03-20 00:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c54e819cfa5d Cleanup, commenting, and simplification of the gradle build. Factored most of the build parameters out into separate gradle files (to act as glorified properties files). Also put in support for cross builds. Given the right armhf.gradle file or armvfp.gradle file we ought to be able to perform cross builds. Added sanity checking code to make sure we fail when attempts are made to cross build on platforms that are not properly supported. ! build.gradle ! generator.gradle + linux.gradle + mac.gradle + win.gradle From tom.schindl at bestsolution.at Wed Mar 20 00:41:58 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 20 Mar 2013 08:41:58 +0100 Subject: Threading and Node.lookup In-Reply-To: <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> Message-ID: <51496846.1000604@bestsolution.at> Hi, The problem is that the lookup system depends on the CSS-Engine (you can pass any CSS-Selector!) to having processed the Node. My guess is that the CSS-Engine does only processes nodes when they are attached to the Scene (there's no reason for it to process them if they are not attached). Tom Am 20.03.13 04:47, schrieb Scott Palmer: > Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. > > Scott > > > On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: > >>> Node background = scene.lookup("#background"); >> >> Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. >> >> -- Kevin >> >> >> >> Scott Palmer wrote: >>> >>> On 2013-03-19, at 8:30 PM, John Smith wrote: >>> >>>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>>> >>> >>> >>> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >>> >>> Yep? I just checked my code, this doesn't return nulls: >>> >>> ? >>> Parent root = FXMLLoader.load(location); >>> Scene scene = new Scene(root); >>> Node top = scene.lookup("#top"); >>> Node background = scene.lookup("#background"); >>> ? >>> >>> The Scene clearly was just constructed and isn't showing or part of a Stage. >>> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >>> >>> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >>> >>> Scott >>> >>> >>> >>> >>>> +1 to Philipp's question. >>>> >>>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>>> >>>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>>> >>>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>>> >>>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>>> >>>> - John >>>> >>>> -----Original Message----- >>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>>> Sent: Tuesday, March 19, 2013 4:50 PM >>>> To: Philipp D?rfler >>>> Cc: openjfx-dev at openjdk.java.net List >>>> Subject: Re: Threading and Node.lookup >>>> >>>> One of the scene graph or FXML folks should be able to reply. >>>> >>>> -- Kevin >>>> >>>> >>>> Philipp D?rfler wrote: >>>> >>>>> Ok, threading aside: Where's my mistake? >>>>> >>>>> https://gist.github.com/phdoerfler/5201162 >>>>> >>>>> ~ philipp >>>>> >>>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>>> >>>>> >>>>> >>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>> >>>>>>> >>>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Philipp D?rfler wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>> >>>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>>> >>>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>>> >>>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>>> So - did I miss something or is this a bug? >>>>>>> >>>>>>> Cheers, >>>>>>> Philipp >>>>>>> >>>>>>> >>>>> >>> >>> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Wed Mar 20 01:04:03 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Mar 2013 01:04:03 -0700 Subject: Threading and Node.lookup In-Reply-To: <51496846.1000604@bestsolution.at> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> Message-ID: Actually in this case the CSS engine should process immediately (it won't batch up this call, it must be synchronous) -- however it may be that there are some shared data structures being foiled by multiple threads. Not sure though, just a wild guess :-) On Mar 20, 2013, at 12:41 AM, Tom Schindl wrote: > Hi, > > The problem is that the lookup system depends on the CSS-Engine (you can > pass any CSS-Selector!) to having processed the Node. > > My guess is that the CSS-Engine does only processes nodes when they are > attached to the Scene (there's no reason for it to process them if they > are not attached). > > Tom > > Am 20.03.13 04:47, schrieb Scott Palmer: >> Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. >> >> Scott >> >> >> On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: >> >>>> Node background = scene.lookup("#background"); >>> >>> Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. >>> >>> -- Kevin >>> >>> >>> >>> Scott Palmer wrote: >>>> >>>> On 2013-03-19, at 8:30 PM, John Smith wrote: >>>> >>>>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>>>> >>>> >>>> >>>> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >>>> >>>> Yep? I just checked my code, this doesn't return nulls: >>>> >>>> ? >>>> Parent root = FXMLLoader.load(location); >>>> Scene scene = new Scene(root); >>>> Node top = scene.lookup("#top"); >>>> Node background = scene.lookup("#background"); >>>> ? >>>> >>>> The Scene clearly was just constructed and isn't showing or part of a Stage. >>>> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >>>> >>>> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >>>> >>>> Scott >>>> >>>> >>>> >>>> >>>>> +1 to Philipp's question. >>>>> >>>>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>>>> >>>>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>>>> >>>>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>>>> >>>>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>>>> >>>>> - John >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>>>> Sent: Tuesday, March 19, 2013 4:50 PM >>>>> To: Philipp D?rfler >>>>> Cc: openjfx-dev at openjdk.java.net List >>>>> Subject: Re: Threading and Node.lookup >>>>> >>>>> One of the scene graph or FXML folks should be able to reply. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Philipp D?rfler wrote: >>>>> >>>>>> Ok, threading aside: Where's my mistake? >>>>>> >>>>>> https://gist.github.com/phdoerfler/5201162 >>>>>> >>>>>> ~ philipp >>>>>> >>>>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>>>> >>>>>> >>>>>> >>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>> >>>>>>>> >>>>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Philipp D?rfler wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>> >>>>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>>>> >>>>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>>>> >>>>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>>>> So - did I miss something or is this a bug? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Philipp >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Wed Mar 20 01:19:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 08:19:24 +0000 Subject: hg: openjfx/8/graphics/rt: Changed the BINARY_STUB default so that for anybody working with a workspace (i.e.: everybody) you won't have to specify the BINARY_STUB property anymore and can just type 'gradle sdk' and it will work. For goodness sake, why didn't I do that before? Message-ID: <20130320081928.26A7A48289@hg.openjdk.java.net> Changeset: 955f963b3286 Author: Richard Bair Date: 2013-03-20 01:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/955f963b3286 Changed the BINARY_STUB default so that for anybody working with a workspace (i.e.: everybody) you won't have to specify the BINARY_STUB property anymore and can just type 'gradle sdk' and it will work. For goodness sake, why didn't I do that before? ! build.gradle From hang.vo at oracle.com Wed Mar 20 02:49:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 09:49:03 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: update input checks on Pisces AbstractSurface Message-ID: <20130320094913.E08F848292@hg.openjdk.java.net> Changeset: 617340f3894b Author: Martin Soch Date: 2013-03-20 10:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/617340f3894b SW pipeline: update input checks on Pisces AbstractSurface ! prism-sw-native/src/JAbstractSurface.c ! prism-sw/src/com/sun/pisces/AbstractSurface.java ! prism-sw/src/com/sun/pisces/PiscesRenderer.java From kevin.rushforth at oracle.com Wed Mar 20 03:20:18 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Mar 2013 03:20:18 -0700 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> Message-ID: <51498D62.6070902@oracle.com> There are some limitations in the CSS engine that require it to be attached to the scene before it will process nodes. I ran into this with snapshot, so a common workaround for apps that want to take a snapshot of a Node that isn't attached to a scene is to create a dummy Scene and attach the node in question to that Scene. See http://javafx-jira.kenai.com/browse/RT-22558 for example. -- Kevin Richard Bair wrote: > Actually in this case the CSS engine should process immediately (it won't batch up this call, it must be synchronous) -- however it may be that there are some shared data structures being foiled by multiple threads. Not sure though, just a wild guess :-) > > On Mar 20, 2013, at 12:41 AM, Tom Schindl wrote: > > >> Hi, >> >> The problem is that the lookup system depends on the CSS-Engine (you can >> pass any CSS-Selector!) to having processed the Node. >> >> My guess is that the CSS-Engine does only processes nodes when they are >> attached to the Scene (there's no reason for it to process them if they >> are not attached). >> >> Tom >> >> Am 20.03.13 04:47, schrieb Scott Palmer: >> >>> Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. >>> >>> Scott >>> >>> >>> On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: >>> >>> >>>>> Node background = scene.lookup("#background"); >>>>> >>>> Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Scott Palmer wrote: >>>> >>>>> On 2013-03-19, at 8:30 PM, John Smith wrote: >>>>> >>>>> >>>>>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>>>>> >>>>>> >>>>> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >>>>> >>>>> Yep? I just checked my code, this doesn't return nulls: >>>>> >>>>> ? >>>>> Parent root = FXMLLoader.load(location); >>>>> Scene scene = new Scene(root); >>>>> Node top = scene.lookup("#top"); >>>>> Node background = scene.lookup("#background"); >>>>> ? >>>>> >>>>> The Scene clearly was just constructed and isn't showing or part of a Stage. >>>>> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >>>>> >>>>> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >>>>> >>>>> Scott >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> +1 to Philipp's question. >>>>>> >>>>>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>>>>> >>>>>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>>>>> >>>>>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>>>>> >>>>>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>>>>> >>>>>> - John >>>>>> >>>>>> -----Original Message----- >>>>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>>>>> Sent: Tuesday, March 19, 2013 4:50 PM >>>>>> To: Philipp D?rfler >>>>>> Cc: openjfx-dev at openjdk.java.net List >>>>>> Subject: Re: Threading and Node.lookup >>>>>> >>>>>> One of the scene graph or FXML folks should be able to reply. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Philipp D?rfler wrote: >>>>>> >>>>>> >>>>>>> Ok, threading aside: Where's my mistake? >>>>>>> >>>>>>> https://gist.github.com/phdoerfler/5201162 >>>>>>> >>>>>>> ~ philipp >>>>>>> >>>>>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Philipp D?rfler wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>> >>>>>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>>>>> >>>>>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>>>>> >>>>>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>>>>> So - did I miss something or is this a bug? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Philipp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 >> > > From hang.vo at oracle.com Wed Mar 20 03:34:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 10:34:34 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28969 ListProperty.equals(list) fails while list.equals(listProperty) succeeds Message-ID: <20130320103437.C408048296@hg.openjdk.java.net> Changeset: c20a97e91414 Author: Martin Sladecek Date: 2013-03-20 11:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c20a97e91414 RT-28969 ListProperty.equals(list) fails while list.equals(listProperty) succeeds ! javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java ! javafx-beans/src/javafx/beans/binding/ListExpression.java ! javafx-beans/src/javafx/beans/binding/SetExpression.java ! javafx-beans/src/javafx/beans/property/ReadOnlyBooleanProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyDoubleProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyFloatProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyIntegerProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyListProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyLongProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyMapProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyObjectProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlySetProperty.java ! javafx-beans/src/javafx/beans/property/ReadOnlyStringProperty.java ! javafx-beans/src/javafx/collections/FXCollections.java ! javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyTest.java ! javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyTest.java ! javafx-beans/test/javafx/collections/ObservableListTest.java ! javafx-beans/test/javafx/collections/ObservableMapTest.java ! javafx-beans/test/javafx/collections/ObservableSetTest.java ! javafx-beans/test/javafx/collections/TestedObservableLists.java ! javafx-beans/test/javafx/collections/TestedObservableMaps.java ! javafx-beans/test/javafx/collections/TestedObservableSets.java From hang.vo at oracle.com Wed Mar 20 03:49:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 10:49:17 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28599: No version checking when loading FXML file Message-ID: <20130320104920.9E09C48297@hg.openjdk.java.net> Changeset: e180590ea4b5 Author: Milan Kubec Date: 2013-03-20 11:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e180590ea4b5 RT-28599: No version checking when loading FXML file ! javafx-fxml/src/javafx/fxml/FXMLLoader.java + javafx-fxml/test/javafx/fxml/CompareVersionsTest.java From phdoerfler at gmail.com Wed Mar 20 04:27:55 2013 From: phdoerfler at gmail.com (=?windows-1252?Q?Philipp_D=F6rfler?=) Date: Wed, 20 Mar 2013 12:27:55 +0100 Subject: Threading and Node.lookup In-Reply-To: <51498D62.6070902@oracle.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> Message-ID: <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> So in order to reliably lookup a node, one has to: 1. Create a Scene with that scenegraph in it 2. Attach that Scene to a Stage 3. Show that Stage 4. OR alternatively (does not help always), call this without a Scene, but in Platform.runLater This this a bit too arcane for my taste. I can see that due to limitations one has to create a Scene and place nodes in there. I can't say I'm exceptionally happy with that, but it'll do for now. Those restrictions are probably there for a reason. However - I don't entirely understand why sometimes it is necessary to actually _show_ a Stage with your nodes to have CSS lookups work (As indicated by John. I ran into this, too). Any chance that this might change? I'm not talking about querying CSS attributes unknown to that point. Only thing I want to do are simple lookups. Is it because of Skin and that it is unknown how exactly the scene graph is composed without evaluating all Control's skins, thus creating more nodes which then might in turn have CSS style-classes (or IDs for that matter) assigned? Is this only possibly by showing a stage? Assuming that this is not going to change any time soon: Is it possible to re-invent the wheel, thus manually traversing the scene graph and querying each and every node for it's id and style class and so on or would that need to be attached to a Scene (and thus runLater...) and/or need to be shown, too? Cheers and thanks for your time, ~ Philipp Am 20.03.2013 um 11:20 schrieb Kevin Rushforth : > There are some limitations in the CSS engine that require it to be attached to the scene before it will process nodes. I ran into this with snapshot, so a common workaround for apps that want to take a snapshot of a Node that isn't attached to a scene is to create a dummy Scene and attach the node in question to that Scene. See http://javafx-jira.kenai.com/browse/RT-22558 for example. > > -- Kevin > > > Richard Bair wrote: >> Actually in this case the CSS engine should process immediately (it won't batch up this call, it must be synchronous) -- however it may be that there are some shared data structures being foiled by multiple threads. Not sure though, just a wild guess :-) >> >> On Mar 20, 2013, at 12:41 AM, Tom Schindl wrote: >> >> >>> Hi, >>> >>> The problem is that the lookup system depends on the CSS-Engine (you can >>> pass any CSS-Selector!) to having processed the Node. >>> >>> My guess is that the CSS-Engine does only processes nodes when they are >>> attached to the Scene (there's no reason for it to process them if they >>> are not attached). >>> >>> Tom >>> >>> Am 20.03.13 04:47, schrieb Scott Palmer: >>> >>>> Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. >>>> >>>> Scott >>>> >>>> >>>> On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: >>>> >>>> >>>>>> Node background = scene.lookup("#background"); >>>>>> >>>>> Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Scott Palmer wrote: >>>>> >>>>>> On 2013-03-19, at 8:30 PM, John Smith wrote: >>>>>> >>>>>> >>>>>>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>>>>>> >>>>>>> >>>>>> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >>>>>> >>>>>> Yep? I just checked my code, this doesn't return nulls: >>>>>> >>>>>> ? >>>>>> Parent root = FXMLLoader.load(location); >>>>>> Scene scene = new Scene(root); >>>>>> Node top = scene.lookup("#top"); >>>>>> Node background = scene.lookup("#background"); >>>>>> ? >>>>>> >>>>>> The Scene clearly was just constructed and isn't showing or part of a Stage. >>>>>> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >>>>>> >>>>>> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> +1 to Philipp's question. >>>>>>> >>>>>>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>>>>>> >>>>>>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>>>>>> >>>>>>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>>>>>> >>>>>>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>>>>>> >>>>>>> - John >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>>>>>> Sent: Tuesday, March 19, 2013 4:50 PM >>>>>>> To: Philipp D?rfler >>>>>>> Cc: openjfx-dev at openjdk.java.net List >>>>>>> Subject: Re: Threading and Node.lookup >>>>>>> >>>>>>> One of the scene graph or FXML folks should be able to reply. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Philipp D?rfler wrote: >>>>>>> >>>>>>> >>>>>>>> Ok, threading aside: Where's my mistake? >>>>>>>> >>>>>>>> https://gist.github.com/phdoerfler/5201162 >>>>>>>> >>>>>>>> ~ philipp >>>>>>>> >>>>>>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Philipp D?rfler wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>>> >>>>>>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>>>>>> >>>>>>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>>>>>> >>>>>>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>>>>>> So - did I miss something or is this a bug? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Philipp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >>> >> >> From tom.schindl at bestsolution.at Wed Mar 20 04:43:09 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 20 Mar 2013 12:43:09 +0100 Subject: Threading and Node.lookup In-Reply-To: <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> Message-ID: <5149A0CD.7010004@bestsolution.at> On 20.03.13 12:27, Philipp D?rfler wrote: > So in order to reliably lookup a node, one has to: > > 1. Create a Scene with that scenegraph in it > 2. Attach that Scene to a Stage > 3. Show that Stage > 4. OR alternatively (does not help always), call this without a Scene, but in Platform.runLater > > This this a bit too arcane for my taste. I can see that due to limitations one has to create a Scene and place nodes in there. I can't say I'm exceptionally happy with that, but it'll do for now. Those restrictions are probably there for a reason. > However - I don't entirely understand why sometimes it is necessary to actually _show_ a Stage with your nodes to have CSS lookups work (As indicated by John. I ran into this, too). Any chance that this might change? I'm not talking about querying CSS attributes unknown to that point. Only thing I want to do are simple lookups. > Is it because of Skin and that it is unknown how exactly the scene graph is composed without evaluating all Control's skins, thus creating more nodes which then might in turn have CSS style-classes (or IDs for that matter) assigned? Is this only possibly by showing a stage? > > Assuming that this is not going to change any time soon: Is it possible to re-invent the wheel, thus manually traversing the scene graph and querying each and every node for it's id and style class and so on or would that need to be attached to a Scene (and thus runLater...) and/or need to be shown, too? > As long as you are only using simple selectors I think this could work but like I said in my reply the API allows to pass in complex CSS-Selectors (e.g. you can do a query like this "#myId > * > .myclass") and you don't want to replicate something like this, I guess ;-) Tom From phdoerfler at gmail.com Wed Mar 20 04:59:03 2013 From: phdoerfler at gmail.com (=?windows-1252?Q?Philipp_D=F6rfler?=) Date: Wed, 20 Mar 2013 12:59:03 +0100 Subject: Threading and Node.lookup In-Reply-To: <5149A0CD.7010004@bestsolution.at> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> <5149A0CD.7010004@bestsolution.at> Message-ID: Oh, turns out I had no idea that CSS selectors can be that complex! Yes, I certainly don't want to replicate this. Might be a good exercise, though. ~ philipp Am 20.03.2013 um 12:43 schrieb Tom Schindl : > On 20.03.13 12:27, Philipp D?rfler wrote: >> So in order to reliably lookup a node, one has to: >> >> 1. Create a Scene with that scenegraph in it >> 2. Attach that Scene to a Stage >> 3. Show that Stage >> 4. OR alternatively (does not help always), call this without a Scene, but in Platform.runLater >> >> This this a bit too arcane for my taste. I can see that due to limitations one has to create a Scene and place nodes in there. I can't say I'm exceptionally happy with that, but it'll do for now. Those restrictions are probably there for a reason. >> However - I don't entirely understand why sometimes it is necessary to actually _show_ a Stage with your nodes to have CSS lookups work (As indicated by John. I ran into this, too). Any chance that this might change? I'm not talking about querying CSS attributes unknown to that point. Only thing I want to do are simple lookups. >> Is it because of Skin and that it is unknown how exactly the scene graph is composed without evaluating all Control's skins, thus creating more nodes which then might in turn have CSS style-classes (or IDs for that matter) assigned? Is this only possibly by showing a stage? >> >> Assuming that this is not going to change any time soon: Is it possible to re-invent the wheel, thus manually traversing the scene graph and querying each and every node for it's id and style class and so on or would that need to be attached to a Scene (and thus runLater...) and/or need to be shown, too? >> > > As long as you are only using simple selectors I think this could work but like I said in my reply the API allows to pass in complex CSS-Selectors (e.g. you can do a query like this "#myId > * > .myclass") and you don't want to replicate something like this, I guess ;-) > > Tom From tom.schindl at bestsolution.at Wed Mar 20 05:04:35 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 20 Mar 2013 13:04:35 +0100 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> <5149A0CD.7010004@bestsolution.at> Message-ID: <5149A5D3.6030301@bestsolution.at> On 20.03.13 12:59, Philipp D?rfler wrote: > Oh, turns out I had no idea that CSS selectors can be that complex! Yes, I certainly don't want to replicate this. Might be a good exercise, though. > had no idea myself before I started working on the CSS-Editor ;-) See * http://www.w3.org/TR/CSS2/selector.html * http://www.w3.org/TR/selectors/ Not all of those selectors work in JavaFX but i gives you an expression how complex those can get. So if you create an API you better not allow CSS-Selectors but: * findById(String) * findByClassNames(String ...) BTW if you need an intermediate complex solution there is JXPath allowing you to traverse Java-Object graphs using XPath ;-) http://commons.apache.org/proper/commons-jxpath/ Tom From phdoerfler at gmail.com Wed Mar 20 05:51:15 2013 From: phdoerfler at gmail.com (=?windows-1252?Q?Philipp_D=F6rfler?=) Date: Wed, 20 Mar 2013 13:51:15 +0100 Subject: Threading and Node.lookup In-Reply-To: <5149A5D3.6030301@bestsolution.at> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> <5149A0CD.7010004@bestsolution.at> <5149A5D3.6030301@bestsolution.at> Message-ID: haha, thanks for the links! I am actually considering going an entirely different route, now: Writing a SBT plugin that (like Android, playframework, ...) auto-generates variables to glue code and FXML together. So I can just say e.g. FX.myButton, which has fx:id="myButton". This should be fairly easy given that FXML is - well - XML and that SBT has special support for code generation. This is of course similiar to controllers for FXML, but is checked at compile time rather then runtime, which itself is something neither node.lookup nor an own, custom API nor JXPath or the controller class can provide. Cheers, ~ Philipp Am 20.03.2013 um 13:04 schrieb Tom Schindl : > On 20.03.13 12:59, Philipp D?rfler wrote: >> Oh, turns out I had no idea that CSS selectors can be that complex! Yes, I certainly don't want to replicate this. Might be a good exercise, though. >> > > had no idea myself before I started working on the CSS-Editor ;-) > > See > * http://www.w3.org/TR/CSS2/selector.html > * http://www.w3.org/TR/selectors/ > > Not all of those selectors work in JavaFX but i gives you an expression how complex those can get. > > So if you create an API you better not allow CSS-Selectors but: > * findById(String) > * findByClassNames(String ...) > > BTW if you need an intermediate complex solution there is JXPath allowing you to traverse Java-Object graphs using XPath ;-) > > http://commons.apache.org/proper/commons-jxpath/ > > Tom From swpalmer at gmail.com Wed Mar 20 06:42:27 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 20 Mar 2013 09:42:27 -0400 Subject: Threading and Node.lookup In-Reply-To: <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> Message-ID: #3 doesn't appear to be a requirement. Re #4 If you have attached a Scene you had to do it on the FX Application thread, so runLater probably doesn't buy you anything. It seems that just being attached to the Scene is the requirement. Scott On 2013-03-20, at 7:27 AM, Philipp D?rfler wrote: > So in order to reliably lookup a node, one has to: > > 1. Create a Scene with that scenegraph in it > 2. Attach that Scene to a Stage > 3. Show that Stage > 4. OR alternatively (does not help always), call this without a Scene, but in Platform.runLater > > This this a bit too arcane for my taste. I can see that due to limitations one has to create a Scene and place nodes in there. I can't say I'm exceptionally happy with that, but it'll do for now. Those restrictions are probably there for a reason. > However - I don't entirely understand why sometimes it is necessary to actually _show_ a Stage with your nodes to have CSS lookups work (As indicated by John. I ran into this, too). Any chance that this might change? I'm not talking about querying CSS attributes unknown to that point. Only thing I want to do are simple lookups. > Is it because of Skin and that it is unknown how exactly the scene graph is composed without evaluating all Control's skins, thus creating more nodes which then might in turn have CSS style-classes (or IDs for that matter) assigned? Is this only possibly by showing a stage? > > Assuming that this is not going to change any time soon: Is it possible to re-invent the wheel, thus manually traversing the scene graph and querying each and every node for it's id and style class and so on or would that need to be attached to a Scene (and thus runLater...) and/or need to be shown, too? > > Cheers and thanks for your time, > ~ Philipp > > Am 20.03.2013 um 11:20 schrieb Kevin Rushforth : > >> There are some limitations in the CSS engine that require it to be attached to the scene before it will process nodes. I ran into this with snapshot, so a common workaround for apps that want to take a snapshot of a Node that isn't attached to a scene is to create a dummy Scene and attach the node in question to that Scene. See http://javafx-jira.kenai.com/browse/RT-22558 for example. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> Actually in this case the CSS engine should process immediately (it won't batch up this call, it must be synchronous) -- however it may be that there are some shared data structures being foiled by multiple threads. Not sure though, just a wild guess :-) >>> >>> On Mar 20, 2013, at 12:41 AM, Tom Schindl wrote: >>> >>> >>>> Hi, >>>> >>>> The problem is that the lookup system depends on the CSS-Engine (you can >>>> pass any CSS-Selector!) to having processed the Node. >>>> >>>> My guess is that the CSS-Engine does only processes nodes when they are >>>> attached to the Scene (there's no reason for it to process them if they >>>> are not attached). >>>> >>>> Tom >>>> >>>> Am 20.03.13 04:47, schrieb Scott Palmer: >>>> >>>>> Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. >>>>> >>>>> Scott >>>>> >>>>> >>>>> On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: >>>>> >>>>> >>>>>>> Node background = scene.lookup("#background"); >>>>>>> >>>>>> Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Scott Palmer wrote: >>>>>> >>>>>>> On 2013-03-19, at 8:30 PM, John Smith wrote: >>>>>>> >>>>>>> >>>>>>>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>>>>>>> >>>>>>>> >>>>>>> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >>>>>>> >>>>>>> Yep? I just checked my code, this doesn't return nulls: >>>>>>> >>>>>>> ? >>>>>>> Parent root = FXMLLoader.load(location); >>>>>>> Scene scene = new Scene(root); >>>>>>> Node top = scene.lookup("#top"); >>>>>>> Node background = scene.lookup("#background"); >>>>>>> ? >>>>>>> >>>>>>> The Scene clearly was just constructed and isn't showing or part of a Stage. >>>>>>> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >>>>>>> >>>>>>> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> +1 to Philipp's question. >>>>>>>> >>>>>>>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>>>>>>> >>>>>>>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>>>>>>> >>>>>>>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>>>>>>> >>>>>>>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>>>>>>> >>>>>>>> - John >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>>>>>>> Sent: Tuesday, March 19, 2013 4:50 PM >>>>>>>> To: Philipp D?rfler >>>>>>>> Cc: openjfx-dev at openjdk.java.net List >>>>>>>> Subject: Re: Threading and Node.lookup >>>>>>>> >>>>>>>> One of the scene graph or FXML folks should be able to reply. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Philipp D?rfler wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Ok, threading aside: Where's my mistake? >>>>>>>>> >>>>>>>>> https://gist.github.com/phdoerfler/5201162 >>>>>>>>> >>>>>>>>> ~ philipp >>>>>>>>> >>>>>>>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Philipp D?rfler wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>>>> >>>>>>>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>>>>>>> >>>>>>>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>>>>>>> >>>>>>>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>>>>>>> So - did I miss something or is this a bug? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Philipp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>> ------------------------------------------------------------------------ >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>> http://www.BestSolution.at phone ++43 512 935834 >>>> >>> >>> > From pavel.safrata at oracle.com Wed Mar 20 07:38:35 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 20 Mar 2013 15:38:35 +0100 Subject: Duplicating a Node In-Reply-To: <5148810E.40502@xs4all.nl> References: <5143634D.9050504@xs4all.nl> <5146DCC3.8010701@oracle.com> <5148810E.40502@xs4all.nl> Message-ID: <5149C9EB.5000907@oracle.com> Hi John, I'm afraid something like this is not really supported. The best approximation I can suggest is rendering the node to image via Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. With dynamic contents, you will have to find your own way to tell when to re-generate the image.. Regards, Pavel On 19.3.2013 16:15, John Hendrikx wrote: > On 18/03/2013 10:22, Pavel Safrata wrote: >> Hi John, >> I tried to use reflection on node with PerspectiveTransform and I >> don't see anything wrong with it - no alternating size, no incorrect >> reflection. Could you please elaborate on what you are trying to >> achieve? Code that I used: >> >> Rectangle rect = new Rectangle(100, 50, Color.RED); >> Reflection r = new Reflection(); >> r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, >> 0, 80)); >> rect.setEffect(r); > Look at the reflection for this Rectangle instead: > > Rectangle rect = new Rectangle(100, 50, Color.RED); > Reflection r = new Reflection(); > r.setInput(new PerspectiveTransform(50, 40, 100, 50, 100, 70, > 50, 80)); > rect.setEffect(r); > > Notice that the Reflection is not what you'd expect for a Node that > has the appearance of being 3D. > > So, that is not the problem. It is perfectly possible to create a > Reflection from an object that has a PerspectiveTransform applied to > it. The problem is that the reflection created is simplistic in that > it assumes the object must be reflected in a horizontal line somewhere > below the object (which is fine for 2D stuff, but not if you are > trying to make your Nodes look 3D with reflections). Please see > http://www.youtube.com/watch?v=8Mb15bOwIyE and look how the > reflections there are exactly attached to the bottom of > PerspectiveTransform'ed Nodes, no spacing. > > When you apply a PerspectiveTransform, the idea is to make the object > look 3D. The Reflection therefore must also be 3D, which means you > cannot just create it by copying an upside-down image of the object > below the PerspectiveTransformed object. Instead the Reflection > should also be 3D and the line it should reflect in is the bottom line > of the object AFTER the PerspectiveTransform was applied (and this > line is not always horizontal). Here's some ASCII art: > > OOOO > OOOOOOOO > OOOOOOOO > OOOOOOOO > OOOORRRR > RRRRRRRR > RRRRRRRR > RRRRRR > RRR > > Instead of: > > OOOO > OOOOOOOO > OOOOOOOO > OOOOOOOO > OOOO > RRRR > RRRRRRRR > RRRRRRRR > RRRRRRRR > RRRR > > Now, it is possible to achieve this by reversing the inputs, first > doing the Reflection, then looking at how Reflection changed the Node, > then applying a PerspectiveTransform that gets the correct 3D result. > However, this is very cumbersome, makes assumptions about how > Reflection will change your Node and does not allow for creation of > Reflections for Objects that have more than just a rotation on the Y > axis applied to them. > > This is why I really need something (an Effect or NodeReference) that > could create a duplicate of a Node :) > > --John > >> >> Regards, >> Pavel >> >> On 15.3.2013 19:07, John Hendrikx wrote: >>> Hi list, >>> >>> I'm trying to achieve an effect that requires me to make a copy of a >>> Node, apply some effect(s) on it (PerspectiveTransform, Clip, Blend >>> and perhaps DisplacementMap) and place it in the same scenegraph >>> together with the original. >>> >>> It is very similar to what Reflection achieves, but without >>> alternating the size of the Node, and without the limitations >>> (specifically, creating the correct Reflection for an object that >>> has a PerspectiveTransform applied to it already cannot be done with >>> Reflection). >>> >>> I would prefer not to have to make an actual copy of the Node, as >>> they might get out of sync and not display the same content when >>> they should be. Something like a NodeReference class, that takes >>> another Node as parameter but applies different >>> effects/clips/transforms. >>> >>> Since the code I'm using for this is based on Cells getting laid >>> out, I'm toying with the idea of actually asking the provider of >>> those cells twice for the same cell and applying different >>> transformations on each, but they might get out of sync and it seems >>> there should be a better way. >>> >>> Any ideas or suggestions at how I could best achieve this, or would >>> it be a new feature? >>> >>> --John >> > From hang.vo at oracle.com Wed Mar 20 08:04:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 15:04:39 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: reduced memory consumption reported on ColorfulShapes test suite (RT-28952) Message-ID: <20130320150447.88F7B48299@hg.openjdk.java.net> Changeset: 7e7a238ea269 Author: Martin Soch Date: 2013-03-20 15:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7e7a238ea269 SW pipeline: reduced memory consumption reported on ColorfulShapes test suite (RT-28952) + prism-sw/src/com/sun/prism/sw/SWContext.java ! prism-sw/src/com/sun/prism/sw/SWGraphics.java ! prism-sw/src/com/sun/prism/sw/SWRTTexture.java ! prism-sw/src/com/sun/prism/sw/SWResourceFactory.java From hang.vo at oracle.com Wed Mar 20 08:34:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 15:34:23 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130320153431.E05F74829B@hg.openjdk.java.net> Changeset: 071ecca76216 Author: Elina Kleyman Date: 2013-03-20 17:13 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/071ecca76216 Porting Calculator and Bouncing Balls to Ensemble8 ! apps/samples/Ensemble8/src/generated/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fdt ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.fdx ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.frq ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.nrm ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.prx ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.tii ! apps/samples/Ensemble8/src/generated/ensemble/search/index/_0.tis ! apps/samples/Ensemble8/src/generated/ensemble/search/index/listAll.txt ! apps/samples/Ensemble8/src/generated/ensemble/search/index/segments_1 + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/Ball.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/BallsPane.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/BallsScreen.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/BouncingBallsApp.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/Constants.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/preview.png + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/bouncingballs/preview at 2x.png + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/calc/Calculator.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/calc/CalculatorApp.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/calc/Key.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/calc/Util.java + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/calc/preview.png + apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/calc/preview at 2x.png Changeset: fb10227a0396 Author: Elina Kleyman Date: 2013-03-20 17:16 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fb10227a0396 Automated merge with ssh://jfxsrc//javafx/8.0/scrum/graphics/jfx/rt From hang.vo at oracle.com Wed Mar 20 09:19:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 16:19:10 +0000 Subject: hg: openjfx/8/controls/rt: Modena app - added ScrollPane single scroll bar examples and tweaked TextArea to show vert ScrollBar thumb. Message-ID: <20130320161924.49854482A0@hg.openjdk.java.net> Changeset: 8576c76a1c25 Author: mo.chicharro Date: 2013-03-20 16:09 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8576c76a1c25 Modena app - added ScrollPane single scroll bar examples and tweaked TextArea to show vert ScrollBar thumb. ! apps/experiments/Modena/src/modena/SamplePage.java From hang.vo at oracle.com Wed Mar 20 09:49:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 16:49:49 +0000 Subject: hg: openjfx/8/graphics/rt: 58 new changesets Message-ID: <20130320165256.CFB57482A6@hg.openjdk.java.net> Changeset: 37f21ae48cbb Author: jgiles Date: 2013-03-12 13:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/37f21ae48cbb RT-28849: TableView has no way to clear the selection once one is made ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: d170f53e01db Author: jgiles Date: 2013-03-12 14:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d170f53e01db RT-28849: TableView has no way to clear the selection once one is made (Fix for TreeView) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 401883988dc0 Author: jgiles Date: 2013-03-13 11:23 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/401883988dc0 RT-28615: ListChangeListener on MultipleSelectionModel selectedItems does not always report correct item added. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java Changeset: 21ab95250f8f Author: jgiles Date: 2013-03-13 11:34 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/21ab95250f8f RT-28897: [TableView, TreeTableView] Column 'sortable' prop when disabled allows to sort column. ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java Changeset: e4029c52cf30 Author: jgiles Date: 2013-03-13 11:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e4029c52cf30 Enabling some ignored unit test classes. ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ChoiceBoxSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuBarSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuButtonSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ToolBarSkinTest.java Changeset: 5f1d2d1faa6d Author: jgiles Date: 2013-03-13 14:24 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5f1d2d1faa6d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 795697fbaa9e Author: David Grieve Date: 2013-03-13 15:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/795697fbaa9e RT-28945: not enough to reset to initial value on slowpath, must also reset on fastpath if css set the current value ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: 2ca6c5e94163 Author: jgiles Date: 2013-03-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2ca6c5e94163 Cleanup some controls unit tests. ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/KeyModifier.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuBarSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: bd595da0dd6b Author: jgiles Date: 2013-03-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bd595da0dd6b Very early work on infrastructure for UI controls to better test mouse events (still incomplete) + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java Changeset: 86fbcdbb3e2e Author: jgiles Date: 2013-03-14 10:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/86fbcdbb3e2e Partial fix for RT-28684: [TreeTableView] When graphics is set to tree item the whole tree table row disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: adefcf226e92 Author: jgiles Date: 2013-03-14 10:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/adefcf226e92 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java Changeset: 5f51d88810cd Author: jgiles Date: 2013-03-14 14:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5f51d88810cd RT-23129: Memory Leak in (Context)Menu ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java Changeset: 4f803bb7ab77 Author: jgiles Date: 2013-03-14 14:27 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4f803bb7ab77 Further unit testing infrastructure explorations + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/ContextMenuEventFirer.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: 282078cff182 Author: jgiles Date: 2013-03-14 14:34 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/282078cff182 RT-23129: Memory Leak in (Context)Menu (Fix for NPE) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: ff5b5435295a Author: jgiles Date: 2013-03-14 16:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ff5b5435295a RT-23129: Memory Leak in (Context)Menu (Fix for silly code typo found by Scott Palmer, also other slight optimisations) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: e1871684b3ae Author: jgiles Date: 2013-03-14 18:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e1871684b3ae RT-28678: [TreeView] graphics is not rendered immediately. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 589dff8b15bb Author: "Jasper Potts" Date: 2013-03-14 09:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/589dff8b15bb Fixed RT-28983: Modena dosn't use LCD text on Windows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: fe41f8a41c08 Author: jgiles Date: 2013-03-15 08:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe41f8a41c08 Reintroduce MouseEventGenerator into javafx-ui-controls. Eclipse tricked me into thinking it would compile but it doesn't when on the command line (clearly different classpaths are being used). + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventGenerator.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java Changeset: 7462badb3a1a Author: jgiles Date: 2013-03-15 08:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7462badb3a1a Disabling problematic RT-28678 unit test temporarily. ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: c48ec880d661 Author: jgiles Date: 2013-03-15 08:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c48ec880d661 Fixing up two unit tests that Eclipse noted had errors. ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/javafx/scene/control/MenuItemTest.java Changeset: 30b551d64339 Author: jgiles Date: 2013-03-15 08:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30b551d64339 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: c2c906a9444a Author: mickf Date: 2013-03-14 19:18 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c2c906a9444a RT-27699 : IndexOutOfBoundsException when dynamic setting TitledPane.setMnemonicParsing(false). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 0096a41dcf0f Author: Paru Somashekar Date: 2013-03-14 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0096a41dcf0f RT-21162 stall bar on same category data add ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 722fd37fc0ff Author: Paru Somashekar Date: 2013-03-14 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/722fd37fc0ff RT-19855 Menu setOnAction not fired. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 148a5ddb6d8d Author: leifs Date: 2013-03-15 16:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/148a5ddb6d8d RT-26147: Tooltip layout issue in RTL orientation. ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java Changeset: df35cfefa6bd Author: Alexander Kouznetsov Date: 2013-03-15 19:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/df35cfefa6bd Modena app: make use of opacity in base, background or accent color ! apps/experiments/Modena/src/modena/Modena.java Changeset: f9cdb400a0d5 Author: Alexander Kouznetsov Date: 2013-03-15 19:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f9cdb400a0d5 Modena skin: Copied pattern-transparent.png for Modena skin to fix NPE in CustomColorDialog with Modena + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png Changeset: 0c08ba3460a0 Author: jgiles Date: 2013-03-18 07:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0c08ba3460a0 RT-29016: CheckBoxTreeItem doesn't have unit tests (this changeset adds ~39 unit tests for CheckBoxTreeItem) ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java + javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java Changeset: 830567b6001f Author: jgiles Date: 2013-03-19 09:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/830567b6001f First batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/ParameterisedPrebuiltCellTest.java Changeset: 3ff4d721bc61 Author: jgiles Date: 2013-03-19 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3ff4d721bc61 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 54ade0062868 Author: Alexander Kouznetsov Date: 2013-03-18 16:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/54ade0062868 CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: a6ad35da022e Author: Alexander Kouznetsov Date: 2013-03-18 16:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a6ad35da022e javafx-ui-controls-tests: get rid of <> diamond operators to stay with 1.7 source level ! javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: f80b0ddaad6b Author: Alexander Kouznetsov Date: 2013-03-18 16:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f80b0ddaad6b CustomColorDialog: Made things private to ensure proper encapsulation. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java Changeset: b6bcfa23f268 Author: Alexander Kouznetsov Date: 2013-03-18 17:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b6bcfa23f268 Backed out changeset f80b0ddaad6b ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java Changeset: dd2fe0f50947 Author: Alexander Kouznetsov Date: 2013-03-18 17:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd2fe0f50947 Backed out changeset a6ad35da022e ! javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: aa130dbb8265 Author: Alexander Kouznetsov Date: 2013-03-18 17:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/aa130dbb8265 Backed out changeset 54ade0062868 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: d117e7743d33 Author: jgiles Date: 2013-03-19 13:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d117e7743d33 RT-28065: Focus is moved on last item when pressing CTRL+A ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 248f00a654a0 Author: jgiles Date: 2013-03-19 15:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/248f00a654a0 RT-29046: Sliders do not allow you to drag from track ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: f3d2aa1925e2 Author: jgiles Date: 2013-03-19 15:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f3d2aa1925e2 Updating source level of javafx-ui-controls netbeans project.xml from 1.6 to 1.7. ! javafx-ui-controls/nbproject/project.xml Changeset: 8a3ba759e08f Author: jgiles Date: 2013-03-19 15:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8a3ba759e08f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a8a615069941 Author: jgiles Date: 2013-03-19 16:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a8a615069941 Fix unit test failures for multiple selection models. ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 5d973fbafa77 Author: jgiles Date: 2013-03-19 16:28 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5d973fbafa77 Resolve class cast exception in CssStyleHelper where Nodes that were not Parents were being cast to Parent. Casting to Node now instead. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: d077f9331707 Author: jgiles Date: 2013-03-19 20:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d077f9331707 Second batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: bc859a872a95 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bc859a872a95 RT-28997: have SimpleStyleableProperty extend StyleableProperty. Patch supplied by Danno Ferrin (danno.ferrin at shemnon.com), reviewed by David Grieve. ! .idea/compiler.xml ! .idea/libraries/jfxrt_binary_stub.xml ! .idea/modules.xml ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java Changeset: 222a76ee6a38 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/222a76ee6a38 RT-29031: @Ignore Node_effectiveOrientation_Css_Test ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: 1e478f14d2f2 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1e478f14d2f2 RT-29019: check for null or empty style-class before calling StyleClassSet.getStyleClass ! javafx-ui-common/src/com/sun/javafx/css/StyleClassSet.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: e7e4b09677e5 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e7e4b09677e5 RT-28992: additional null checks in StyleManager#removeFromCacheMap ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: dec15223148f Author: Paru Somashekar Date: 2013-03-19 09:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dec15223148f RT-23457 MenuItems should not be selected when a mouse move and mouse up occurs. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 6a275aaf415f Author: Paru Somashekar Date: 2013-03-19 09:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a275aaf415f RT-21138 BarChart - negative data item is added, animation starts from positive value ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 1b6eab7f1f72 Author: mo.chicharro Date: 2013-03-19 16:56 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1b6eab7f1f72 Fix for RT-28503 - Modena: TreeView disclosure arrow is wrong shape ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 0b251608ae45 Author: mo.chicharro Date: 2013-03-19 17:00 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0b251608ae45 Fix for RT-29069 - Modena: Text inside TreeTableView cells sits 1 pixel too high ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: e78a64bc1998 Author: David Grieve Date: 2013-03-19 13:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e78a64bc1998 revert unintentional changes to rt/.idea files ! .idea/compiler.xml ! .idea/libraries/jfxrt_binary_stub.xml ! .idea/modules.xml Changeset: c215a5924b33 Author: David Grieve Date: 2013-03-19 13:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c215a5924b33 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: ee86f25fc1b3 Author: mo.chicharro Date: 2013-03-19 17:59 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ee86f25fc1b3 Fixed typo in CSS ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 98b8f8052c8b Author: "Jasper Potts" Date: 2013-03-19 11:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98b8f8052c8b Fixed: RT-29074: When child is more css dirty than parent that gets lost ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: c2ebe930f201 Author: Alexander Kouznetsov Date: 2013-03-19 13:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c2ebe930f201 CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: 9cd4222cfa62 Author: Paru Somashekar Date: 2013-03-19 22:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9cd4222cfa62 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java Changeset: a2cfe5a168ae Author: jgodinez Date: 2013-03-20 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a2cfe5a168ae Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Wed Mar 20 10:19:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 17:19:08 +0000 Subject: hg: openjfx/8/controls/rt: Modena - tweaked Scrollbar button hover/pressed states Message-ID: <20130320171915.8AF24482A7@hg.openjdk.java.net> Changeset: 6d708dde830a Author: mo.chicharro Date: 2013-03-20 17:10 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6d708dde830a Modena - tweaked Scrollbar button hover/pressed states ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Wed Mar 20 10:19:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 17:19:15 +0000 Subject: hg: openjfx/8/graphics/rt: Added single-file dependency tracking for native files, so that when you change a single .m, .cpp, .c, .cc, .rc. or .cur file then only that file is processed, whereas changing any other file (such as .h or .pch) results in recompilation of the native files in that task. Significant time savings (from 30s to 13s for a build on my slow windows system when changing a single native file in Glass. Much less difference on my mac). Message-ID: <20130320171922.581AB482A8@hg.openjdk.java.net> Changeset: 872ef012cd34 Author: Richard Bair Date: 2013-03-20 10:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/872ef012cd34 Added single-file dependency tracking for native files, so that when you change a single .m, .cpp, .c, .cc, .rc. or .cur file then only that file is processed, whereas changing any other file (such as .h or .pch) results in recompilation of the native files in that task. Significant time savings (from 30s to 13s for a build on my slow windows system when changing a single native file in Glass. Much less difference on my mac). ! build.gradle From richard.bair at oracle.com Wed Mar 20 10:55:47 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Mar 2013 10:55:47 -0700 Subject: Gradle build progress Message-ID: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). cd rt gradle -b generator.gradle cd ../javafx gradle sdk You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar Please give it a try and let me know if it works for you or if it fails. I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. My next tasks: - confirm javadoc generation works - fix any failing tests or configuration that causes tests to fail - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script - fix any build issues reported on this thread - IDE integration Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. Richard From John_Smith at symantec.com Wed Mar 20 10:56:45 2013 From: John_Smith at symantec.com (John Smith) Date: Wed, 20 Mar 2013 10:56:45 -0700 Subject: Duplicating a Node In-Reply-To: <5149C9EB.5000907@oracle.com> References: <5143634D.9050504@xs4all.nl> <5146DCC3.8010701@oracle.com> <5148810E.40502@xs4all.nl> <5149C9EB.5000907@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D2216788376E4@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Another user was encountering a similar (but different) requirement to John where they wanted to take a Reflection and blur it, which seemed a reasonable request, but was quite difficult to achieve with the current APIs, so I can see where the request for "something (an Effect or NodeReference)" is coming from. Today the only way to get such a thing is to chain the input effects on the Node (which doesn't always do what you need), or snapshot the nodes (but then you need to keep retaking snapshots if you have dynamic content). The Node duplication request seems to be a relatively infrequent requirement and perhaps it would be difficult to implement, so, though it seems like a nice feature, I'd guess it's implementation wouldn't be high priority. Also, maybe in the future it will be easy to create your own custom effects on Nodes, which might obviate the Node duplication request in some cases. > The best approximation I can suggest is rendering the node to image via Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. The solution I used for blurring a reflection was the same approximation method Pavel suggests of taking a Snapshot: https://forums.oracle.com/forums/thread.jspa?threadID=2496389 "Thread: Effects on effects" -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Pavel Safrata Sent: Wednesday, March 20, 2013 7:39 AM To: openjfx-dev at openjdk.java.net Subject: Re: Duplicating a Node Hi John, I'm afraid something like this is not really supported. The best approximation I can suggest is rendering the node to image via Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. With dynamic contents, you will have to find your own way to tell when to re-generate the image.. Regards, Pavel On 19.3.2013 16:15, John Hendrikx wrote: > On 18/03/2013 10:22, Pavel Safrata wrote: >> Hi John, >> I tried to use reflection on node with PerspectiveTransform and I >> don't see anything wrong with it - no alternating size, no incorrect >> reflection. Could you please elaborate on what you are trying to >> achieve? Code that I used: >> >> Rectangle rect = new Rectangle(100, 50, Color.RED); >> Reflection r = new Reflection(); >> r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, >> 0, 80)); >> rect.setEffect(r); > Look at the reflection for this Rectangle instead: > > Rectangle rect = new Rectangle(100, 50, Color.RED); > Reflection r = new Reflection(); > r.setInput(new PerspectiveTransform(50, 40, 100, 50, 100, 70, > 50, 80)); > rect.setEffect(r); > > Notice that the Reflection is not what you'd expect for a Node that > has the appearance of being 3D. > > So, that is not the problem. It is perfectly possible to create a > Reflection from an object that has a PerspectiveTransform applied to > it. The problem is that the reflection created is simplistic in that > it assumes the object must be reflected in a horizontal line somewhere > below the object (which is fine for 2D stuff, but not if you are > trying to make your Nodes look 3D with reflections). Please see > http://www.youtube.com/watch?v=8Mb15bOwIyE and look how the > reflections there are exactly attached to the bottom of > PerspectiveTransform'ed Nodes, no spacing. > > When you apply a PerspectiveTransform, the idea is to make the object > look 3D. The Reflection therefore must also be 3D, which means you > cannot just create it by copying an upside-down image of the object > below the PerspectiveTransformed object. Instead the Reflection > should also be 3D and the line it should reflect in is the bottom line > of the object AFTER the PerspectiveTransform was applied (and this > line is not always horizontal). Here's some ASCII art: > > OOOO > OOOOOOOO > OOOOOOOO > OOOOOOOO > OOOORRRR > RRRRRRRR > RRRRRRRR > RRRRRR > RRR > > Instead of: > > OOOO > OOOOOOOO > OOOOOOOO > OOOOOOOO > OOOO > RRRR > RRRRRRRR > RRRRRRRR > RRRRRRRR > RRRR > > Now, it is possible to achieve this by reversing the inputs, first > doing the Reflection, then looking at how Reflection changed the Node, > then applying a PerspectiveTransform that gets the correct 3D result. > However, this is very cumbersome, makes assumptions about how > Reflection will change your Node and does not allow for creation of > Reflections for Objects that have more than just a rotation on the Y > axis applied to them. > > This is why I really need something (an Effect or NodeReference) that > could create a duplicate of a Node :) > > --John > >> >> Regards, >> Pavel >> >> On 15.3.2013 19:07, John Hendrikx wrote: >>> Hi list, >>> >>> I'm trying to achieve an effect that requires me to make a copy of a >>> Node, apply some effect(s) on it (PerspectiveTransform, Clip, Blend >>> and perhaps DisplacementMap) and place it in the same scenegraph >>> together with the original. >>> >>> It is very similar to what Reflection achieves, but without >>> alternating the size of the Node, and without the limitations >>> (specifically, creating the correct Reflection for an object that >>> has a PerspectiveTransform applied to it already cannot be done with >>> Reflection). >>> >>> I would prefer not to have to make an actual copy of the Node, as >>> they might get out of sync and not display the same content when >>> they should be. Something like a NodeReference class, that takes >>> another Node as parameter but applies different >>> effects/clips/transforms. >>> >>> Since the code I'm using for this is based on Cells getting laid >>> out, I'm toying with the idea of actually asking the provider of >>> those cells twice for the same cell and applying different >>> transformations on each, but they might get out of sync and it seems >>> there should be a better way. >>> >>> Any ideas or suggestions at how I could best achieve this, or would >>> it be a new feature? >>> >>> --John >> > From hang.vo at oracle.com Wed Mar 20 11:04:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 18:04:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29091 Remove beans from Light effect Message-ID: <20130320180438.CC1D1482AC@hg.openjdk.java.net> Changeset: 5614a3fbcfdf Author: "Joseph Andresen" Date: 2013-03-20 10:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5614a3fbcfdf RT-29091 Remove beans from Light effect ! decora-runtime/src/com/sun/scenario/effect/light/DistantLight.java ! decora-runtime/src/com/sun/scenario/effect/light/Light.java ! decora-runtime/src/com/sun/scenario/effect/light/PointLight.java ! decora-runtime/src/com/sun/scenario/effect/light/SpotLight.java From hang.vo at oracle.com Wed Mar 20 11:18:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 18:18:53 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130320181901.79698482AD@hg.openjdk.java.net> Changeset: 89635eee9743 Author: Yao Wang Date: 2013-03-20 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/89635eee9743 RT-27908 TriangleMesh.setPoints(int, float[], int, int) API is broken ! javafx-sg-common/src/com/sun/javafx/sg/PGTriangleMesh.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/NGTriangleMeshTest.java ! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java ! javafx-ui-common/test/unit/javafx/scene/shape/TriangleMeshTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTriangleMesh.java Changeset: eae91cdbfa5d Author: Yao Wang Date: 2013-03-20 11:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eae91cdbfa5d merge heads From hang.vo at oracle.com Wed Mar 20 11:33:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 18:33:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28355: LOD helper needs to test in the same coordinate system Message-ID: <20130320183352.E8156482AE@hg.openjdk.java.net> Changeset: 2f1c0d44b4cf Author: RT-28355: LOD helper needs to test in the same coordinate system Date: 2013-03-20 11:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2f1c0d44b4cf RT-28355: LOD helper needs to test in the same coordinate system ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Node.java + javafx-ui-common/test/unit/javafx/scene/CameraTest.java From peter.pilgrim at gmail.com Wed Mar 20 13:03:47 2013 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Wed, 20 Mar 2013 20:03:47 +0000 Subject: Gradle build progress In-Reply-To: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> Message-ID: Hey Richard I just tried with Gradle 1.4 and the compilation failed. Hope this helps peterpilgrim at Peters-MacBook-Pro-3.local [572] > gradle clean The CompileOptions.useAnt property has been deprecated and is scheduled to be removed in Gradle 2.0. There is no replacement for this property. :base:clean :build-tools:clean :controls:clean :designTime:clean :fxml:clean :graphics:clean :swing:clean :swt:clean :graphics:effects-jsl:clean :graphics:native:clean :graphics:prism-jsl:clean BUILD SUCCESSFUL Total time: 3.348 secs peterpilgrim at Peters-MacBook-Pro-3.local [573] > gradle sdk The CompileOptions.useAnt property has been deprecated and is scheduled to be removed in Gradle 2.0. There is no replacement for this property. :base:processVersion :build-tools:generateGrammarSource :build-tools:compileJava :build-tools:processResources :build-tools:classes :build-tools:jar :base:compileJava [ant:javac] Note: /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/base/src/main/java/com/sun/scenario/animation/shared/InterpolationInterval.java uses or overrides a deprecated API. [ant:javac] Note: Recompile with -Xlint:deprecation for details. [ant:javac] Note: Some input files use unchecked or unsafe operations. [ant:javac] Note: Recompile with -Xlint:unchecked for details. :base:processResources UP-TO-DATE :base:classes :base:jar :base:assemble :build-tools:assemble :graphics:compileJava [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:28: error: package com.sun.javafx.accessible.utils does not exist [ant:javac] import com.sun.javafx.accessible.utils.NavigateDirection; [ant:javac] ^ [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:29: error: package com.sun.javafx.accessible.utils does not exist [ant:javac] import com.sun.javafx.accessible.utils.Rect; [ant:javac] ^ [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:30: error: package com.sun.javafx.accessible.providers does not exist [ant:javac] import com.sun.javafx.accessible.providers.AccessibleProvider; [ant:javac] ^ [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:112: error: cannot find symbol [ant:javac] private AccessibleProvider hostRawElementProvider() { etc, etc On 20 March 2013 17:55, Richard Bair wrote: > I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. > > To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). > > cd rt > gradle -b generator.gradle > cd ../javafx > gradle sdk > > You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. > > It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar > > Please give it a try and let me know if it works for you or if it fails. > > I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. > > Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. > > My next tasks: > - confirm javadoc generation works > - fix any failing tests or configuration that causes tests to fail > - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster > - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script > - fix any build issues reported on this thread > - IDE integration > > Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. > > Richard -- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for `BlueChip' enterprises, London, UK JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim :: :: Skype Call peter_pilgrim :: :: http://java-champions.java.net/ :: From richard.bair at oracle.com Wed Mar 20 13:13:48 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Mar 2013 13:13:48 -0700 Subject: Gradle build progress In-Reply-To: References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> Message-ID: Hi Peter, This will be because the stub binary is not available. Where do you have the JDK 8 b81 jfxrt.jar file located? Thanks! Richard On Mar 20, 2013, at 1:03 PM, Peter Pilgrim wrote: > Hey Richard > > I just tried with Gradle 1.4 and the compilation failed. > > Hope this helps > > peterpilgrim at Peters-MacBook-Pro-3.local [572] > gradle clean > The CompileOptions.useAnt property has been deprecated and is > scheduled to be removed in Gradle 2.0. There is no replacement for > this property. > :base:clean > :build-tools:clean > :controls:clean > :designTime:clean > :fxml:clean > :graphics:clean > :swing:clean > :swt:clean > :graphics:effects-jsl:clean > :graphics:native:clean > :graphics:prism-jsl:clean > > BUILD SUCCESSFUL > > Total time: 3.348 secs > peterpilgrim at Peters-MacBook-Pro-3.local [573] > gradle sdk > The CompileOptions.useAnt property has been deprecated and is > scheduled to be removed in Gradle 2.0. There is no replacement for > this property. > :base:processVersion > :build-tools:generateGrammarSource > :build-tools:compileJava > :build-tools:processResources > :build-tools:classes > :build-tools:jar > :base:compileJava > [ant:javac] Note: > /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/base/src/main/java/com/sun/scenario/animation/shared/InterpolationInterval.java > uses or overrides a deprecated API. > [ant:javac] Note: Recompile with -Xlint:deprecation for details. > [ant:javac] Note: Some input files use unchecked or unsafe operations. > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > :base:processResources UP-TO-DATE > :base:classes > :base:jar > :base:assemble > :build-tools:assemble > :graphics:compileJava > [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:28: > error: package com.sun.javafx.accessible.utils does not exist > [ant:javac] import com.sun.javafx.accessible.utils.NavigateDirection; > [ant:javac] ^ > [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:29: > error: package com.sun.javafx.accessible.utils does not exist > [ant:javac] import com.sun.javafx.accessible.utils.Rect; > [ant:javac] ^ > [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:30: > error: package com.sun.javafx.accessible.providers does not exist > [ant:javac] import com.sun.javafx.accessible.providers.AccessibleProvider; > [ant:javac] ^ > [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:112: > error: cannot find symbol > [ant:javac] private AccessibleProvider hostRawElementProvider() { > > etc, etc > > > On 20 March 2013 17:55, Richard Bair wrote: >> I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. >> >> To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). >> >> cd rt >> gradle -b generator.gradle >> cd ../javafx >> gradle sdk >> >> You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. >> >> It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar >> >> Please give it a try and let me know if it works for you or if it fails. >> >> I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. >> >> Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. >> >> My next tasks: >> - confirm javadoc generation works >> - fix any failing tests or configuration that causes tests to fail >> - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster >> - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script >> - fix any build issues reported on this thread >> - IDE integration >> >> Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. >> >> Richard > > > > -- > Peter Pilgrim, > **Java Champion**, > Java EE Software Development / Design / Architect for `BlueChip' > enterprises, London, UK > > JavaFX ++ Scala ++ Groovy ++ Android ++ Java > > :: http://www.xenonique.co.uk/blog/ :: > :: http://twitter.com/peter_pilgrim :: > :: http://audio.fm/profile/peter_pilgrim :: > :: Skype Call peter_pilgrim :: > :: http://java-champions.java.net/ :: From richard.bair at oracle.com Wed Mar 20 13:41:59 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Mar 2013 13:41:59 -0700 Subject: Gradle build progress In-Reply-To: References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> Message-ID: <53A0C78D-2708-400B-974F-69B7B7553B24@oracle.com> Peter replied off thread that indeed he has jfxrt.jar in the right place! I'm thinking perhaps the problem is that the Accessible classes here that are being relied on have not yet been open sourced and neither have they found their way into jfxrt.jar, and thus we have a bit of a problem! I will try filtering out the accessible package from glass so that it is not built. Richard On Mar 20, 2013, at 1:13 PM, Richard Bair wrote: > Hi Peter, > > This will be because the stub binary is not available. Where do you have the JDK 8 b81 jfxrt.jar file located? > > Thanks! > Richard > > On Mar 20, 2013, at 1:03 PM, Peter Pilgrim wrote: > >> Hey Richard >> >> I just tried with Gradle 1.4 and the compilation failed. >> >> Hope this helps >> >> peterpilgrim at Peters-MacBook-Pro-3.local [572] > gradle clean >> The CompileOptions.useAnt property has been deprecated and is >> scheduled to be removed in Gradle 2.0. There is no replacement for >> this property. >> :base:clean >> :build-tools:clean >> :controls:clean >> :designTime:clean >> :fxml:clean >> :graphics:clean >> :swing:clean >> :swt:clean >> :graphics:effects-jsl:clean >> :graphics:native:clean >> :graphics:prism-jsl:clean >> >> BUILD SUCCESSFUL >> >> Total time: 3.348 secs >> peterpilgrim at Peters-MacBook-Pro-3.local [573] > gradle sdk >> The CompileOptions.useAnt property has been deprecated and is >> scheduled to be removed in Gradle 2.0. There is no replacement for >> this property. >> :base:processVersion >> :build-tools:generateGrammarSource >> :build-tools:compileJava >> :build-tools:processResources >> :build-tools:classes >> :build-tools:jar >> :base:compileJava >> [ant:javac] Note: >> /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/base/src/main/java/com/sun/scenario/animation/shared/InterpolationInterval.java >> uses or overrides a deprecated API. >> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >> [ant:javac] Note: Some input files use unchecked or unsafe operations. >> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >> :base:processResources UP-TO-DATE >> :base:classes >> :base:jar >> :base:assemble >> :build-tools:assemble >> :graphics:compileJava >> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:28: >> error: package com.sun.javafx.accessible.utils does not exist >> [ant:javac] import com.sun.javafx.accessible.utils.NavigateDirection; >> [ant:javac] ^ >> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:29: >> error: package com.sun.javafx.accessible.utils does not exist >> [ant:javac] import com.sun.javafx.accessible.utils.Rect; >> [ant:javac] ^ >> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:30: >> error: package com.sun.javafx.accessible.providers does not exist >> [ant:javac] import com.sun.javafx.accessible.providers.AccessibleProvider; >> [ant:javac] ^ >> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:112: >> error: cannot find symbol >> [ant:javac] private AccessibleProvider hostRawElementProvider() { >> >> etc, etc >> >> >> On 20 March 2013 17:55, Richard Bair wrote: >>> I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. >>> >>> To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). >>> >>> cd rt >>> gradle -b generator.gradle >>> cd ../javafx >>> gradle sdk >>> >>> You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. >>> >>> It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar >>> >>> Please give it a try and let me know if it works for you or if it fails. >>> >>> I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. >>> >>> Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. >>> >>> My next tasks: >>> - confirm javadoc generation works >>> - fix any failing tests or configuration that causes tests to fail >>> - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster >>> - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script >>> - fix any build issues reported on this thread >>> - IDE integration >>> >>> Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. >>> >>> Richard >> >> >> >> -- >> Peter Pilgrim, >> **Java Champion**, >> Java EE Software Development / Design / Architect for `BlueChip' >> enterprises, London, UK >> >> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >> >> :: http://www.xenonique.co.uk/blog/ :: >> :: http://twitter.com/peter_pilgrim :: >> :: http://audio.fm/profile/peter_pilgrim :: >> :: Skype Call peter_pilgrim :: >> :: http://java-champions.java.net/ :: > From peter.pilgrim at gmail.com Wed Mar 20 13:46:55 2013 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Wed, 20 Mar 2013 20:46:55 +0000 Subject: Gradle build progress In-Reply-To: <53A0C78D-2708-400B-974F-69B7B7553B24@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <53A0C78D-2708-400B-974F-69B7B7553B24@oracle.com> Message-ID: Sorry. I was away temporarily. peterpilgrim at Peters-MacBook-Pro-3.local [577] > jar -tvf ../artifacts/sdk/rt/lib/ext/jfxrt.jar | grep "accessible" 0 Wed Mar 13 14:21:36 GMT 2013 com/sun/glass/ui/accessible/ 0 Wed Mar 13 14:21:40 GMT 2013 com/sun/glass/ui/accessible/mac/ 0 Wed Mar 13 14:05:56 GMT 2013 com/sun/javafx/accessible/ 0 Wed Mar 13 14:21:42 GMT 2013 com/sun/javafx/accessible/providers/ 0 Wed Mar 13 14:21:40 GMT 2013 com/sun/javafx/accessible/utils/ 0 Wed Mar 13 14:21:40 GMT 2013 com/sun/javafx/scene/control/accessible/ 733 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/AccessibleBasePatternProvider.class 3134 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/AccessibleBaseProvider.class 924 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/AccessibleLogger$1.class 1855 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/AccessibleLogger.class 3323 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/AccessibleRoot.class 11084 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleAttributes$MacAttribute.class 482 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleAttributes.class 518 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleBasePatternProvider.class 8354 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleBaseProvider.class 3252 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleEventIds$MacEventId.class 470 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleEventIds.class 4233 Wed Mar 13 14:06:02 GMT 2013 com/sun/glass/ui/accessible/mac/MacAccessibleRoles$MacRole.class On 20 March 2013 20:41, Richard Bair wrote: > Peter replied off thread that indeed he has jfxrt.jar in the right place! I'm thinking perhaps the problem is that the Accessible classes here that are being relied on have not yet been open sourced and neither have they found their way into jfxrt.jar, and thus we have a bit of a problem! > > I will try filtering out the accessible package from glass so that it is not built. > > Richard > > On Mar 20, 2013, at 1:13 PM, Richard Bair wrote: > >> Hi Peter, >> >> This will be because the stub binary is not available. Where do you have the JDK 8 b81 jfxrt.jar file located? >> >> Thanks! >> Richard >> >> On Mar 20, 2013, at 1:03 PM, Peter Pilgrim wrote: >> >>> Hey Richard >>> >>> I just tried with Gradle 1.4 and the compilation failed. >>> >>> Hope this helps >>> >>> peterpilgrim at Peters-MacBook-Pro-3.local [572] > gradle clean >>> The CompileOptions.useAnt property has been deprecated and is >>> scheduled to be removed in Gradle 2.0. There is no replacement for >>> this property. >>> :base:clean >>> :build-tools:clean >>> :controls:clean >>> :designTime:clean >>> :fxml:clean >>> :graphics:clean >>> :swing:clean >>> :swt:clean >>> :graphics:effects-jsl:clean >>> :graphics:native:clean >>> :graphics:prism-jsl:clean >>> >>> BUILD SUCCESSFUL >>> >>> Total time: 3.348 secs >>> peterpilgrim at Peters-MacBook-Pro-3.local [573] > gradle sdk >>> The CompileOptions.useAnt property has been deprecated and is >>> scheduled to be removed in Gradle 2.0. There is no replacement for >>> this property. >>> :base:processVersion >>> :build-tools:generateGrammarSource >>> :build-tools:compileJava >>> :build-tools:processResources >>> :build-tools:classes >>> :build-tools:jar >>> :base:compileJava >>> [ant:javac] Note: >>> /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/base/src/main/java/com/sun/scenario/animation/shared/InterpolationInterval.java >>> uses or overrides a deprecated API. >>> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >>> [ant:javac] Note: Some input files use unchecked or unsafe operations. >>> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >>> :base:processResources UP-TO-DATE >>> :base:classes >>> :base:jar >>> :base:assemble >>> :build-tools:assemble >>> :graphics:compileJava >>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:28: >>> error: package com.sun.javafx.accessible.utils does not exist >>> [ant:javac] import com.sun.javafx.accessible.utils.NavigateDirection; >>> [ant:javac] ^ >>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:29: >>> error: package com.sun.javafx.accessible.utils does not exist >>> [ant:javac] import com.sun.javafx.accessible.utils.Rect; >>> [ant:javac] ^ >>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:30: >>> error: package com.sun.javafx.accessible.providers does not exist >>> [ant:javac] import com.sun.javafx.accessible.providers.AccessibleProvider; >>> [ant:javac] ^ >>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:112: >>> error: cannot find symbol >>> [ant:javac] private AccessibleProvider hostRawElementProvider() { >>> >>> etc, etc >>> >>> >>> On 20 March 2013 17:55, Richard Bair wrote: >>>> I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. >>>> >>>> To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). >>>> >>>> cd rt >>>> gradle -b generator.gradle >>>> cd ../javafx >>>> gradle sdk >>>> >>>> You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. >>>> >>>> It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar >>>> >>>> Please give it a try and let me know if it works for you or if it fails. >>>> >>>> I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. >>>> >>>> Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. >>>> >>>> My next tasks: >>>> - confirm javadoc generation works >>>> - fix any failing tests or configuration that causes tests to fail >>>> - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster >>>> - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script >>>> - fix any build issues reported on this thread >>>> - IDE integration >>>> >>>> Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. >>>> >>>> Richard >>> >>> >>> >>> -- >>> Peter Pilgrim, >>> **Java Champion**, >>> Java EE Software Development / Design / Architect for `BlueChip' >>> enterprises, London, UK >>> >>> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >>> >>> :: http://www.xenonique.co.uk/blog/ :: >>> :: http://twitter.com/peter_pilgrim :: >>> :: http://audio.fm/profile/peter_pilgrim :: >>> :: Skype Call peter_pilgrim :: >>> :: http://java-champions.java.net/ :: >> > -- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for `BlueChip' enterprises, London, UK JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim :: :: Skype Call peter_pilgrim :: :: http://java-champions.java.net/ :: From richard.bair at oracle.com Wed Mar 20 13:52:15 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Mar 2013 13:52:15 -0700 Subject: Gradle build progress In-Reply-To: References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <53A0C78D-2708-400B-974F-69B7B7553B24@oracle.com> Message-ID: <10EC0A37-C022-4E7C-A788-CE1CD02FCB60@oracle.com> Thanks Peter! That is indeed the problem. Basically there are some glass accessible classes which, if ever attempted to be used, would fail at runtime because they were compiled against classes not included in jfxrt.jar :-/. I am betting a quick look in the build files would find that those packages are not compiled in the existing ant-based open build. Richard On Mar 20, 2013, at 1:46 PM, Peter Pilgrim wrote: > Sorry. I was away temporarily. > > peterpilgrim at Peters-MacBook-Pro-3.local [577] > jar -tvf > ../artifacts/sdk/rt/lib/ext/jfxrt.jar | grep "accessible" > 0 Wed Mar 13 14:21:36 GMT 2013 com/sun/glass/ui/accessible/ > 0 Wed Mar 13 14:21:40 GMT 2013 com/sun/glass/ui/accessible/mac/ > 0 Wed Mar 13 14:05:56 GMT 2013 com/sun/javafx/accessible/ > 0 Wed Mar 13 14:21:42 GMT 2013 com/sun/javafx/accessible/providers/ > 0 Wed Mar 13 14:21:40 GMT 2013 com/sun/javafx/accessible/utils/ > 0 Wed Mar 13 14:21:40 GMT 2013 com/sun/javafx/scene/control/accessible/ > 733 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/AccessibleBasePatternProvider.class > 3134 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/AccessibleBaseProvider.class > 924 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/AccessibleLogger$1.class > 1855 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/AccessibleLogger.class > 3323 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/AccessibleRoot.class > 11084 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleAttributes$MacAttribute.class > 482 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleAttributes.class > 518 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleBasePatternProvider.class > 8354 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleBaseProvider.class > 3252 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleEventIds$MacEventId.class > 470 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleEventIds.class > 4233 Wed Mar 13 14:06:02 GMT 2013 > com/sun/glass/ui/accessible/mac/MacAccessibleRoles$MacRole.class > > > On 20 March 2013 20:41, Richard Bair wrote: >> Peter replied off thread that indeed he has jfxrt.jar in the right place! I'm thinking perhaps the problem is that the Accessible classes here that are being relied on have not yet been open sourced and neither have they found their way into jfxrt.jar, and thus we have a bit of a problem! >> >> I will try filtering out the accessible package from glass so that it is not built. >> >> Richard >> >> On Mar 20, 2013, at 1:13 PM, Richard Bair wrote: >> >>> Hi Peter, >>> >>> This will be because the stub binary is not available. Where do you have the JDK 8 b81 jfxrt.jar file located? >>> >>> Thanks! >>> Richard >>> >>> On Mar 20, 2013, at 1:03 PM, Peter Pilgrim wrote: >>> >>>> Hey Richard >>>> >>>> I just tried with Gradle 1.4 and the compilation failed. >>>> >>>> Hope this helps >>>> >>>> peterpilgrim at Peters-MacBook-Pro-3.local [572] > gradle clean >>>> The CompileOptions.useAnt property has been deprecated and is >>>> scheduled to be removed in Gradle 2.0. There is no replacement for >>>> this property. >>>> :base:clean >>>> :build-tools:clean >>>> :controls:clean >>>> :designTime:clean >>>> :fxml:clean >>>> :graphics:clean >>>> :swing:clean >>>> :swt:clean >>>> :graphics:effects-jsl:clean >>>> :graphics:native:clean >>>> :graphics:prism-jsl:clean >>>> >>>> BUILD SUCCESSFUL >>>> >>>> Total time: 3.348 secs >>>> peterpilgrim at Peters-MacBook-Pro-3.local [573] > gradle sdk >>>> The CompileOptions.useAnt property has been deprecated and is >>>> scheduled to be removed in Gradle 2.0. There is no replacement for >>>> this property. >>>> :base:processVersion >>>> :build-tools:generateGrammarSource >>>> :build-tools:compileJava >>>> :build-tools:processResources >>>> :build-tools:classes >>>> :build-tools:jar >>>> :base:compileJava >>>> [ant:javac] Note: >>>> /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/base/src/main/java/com/sun/scenario/animation/shared/InterpolationInterval.java >>>> uses or overrides a deprecated API. >>>> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >>>> [ant:javac] Note: Some input files use unchecked or unsafe operations. >>>> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >>>> :base:processResources UP-TO-DATE >>>> :base:classes >>>> :base:jar >>>> :base:assemble >>>> :build-tools:assemble >>>> :graphics:compileJava >>>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:28: >>>> error: package com.sun.javafx.accessible.utils does not exist >>>> [ant:javac] import com.sun.javafx.accessible.utils.NavigateDirection; >>>> [ant:javac] ^ >>>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:29: >>>> error: package com.sun.javafx.accessible.utils does not exist >>>> [ant:javac] import com.sun.javafx.accessible.utils.Rect; >>>> [ant:javac] ^ >>>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:30: >>>> error: package com.sun.javafx.accessible.providers does not exist >>>> [ant:javac] import com.sun.javafx.accessible.providers.AccessibleProvider; >>>> [ant:javac] ^ >>>> [ant:javac] /Users/peterpilgrim/Documents/IdeaProjects/open-jfx-8/master/javafx/modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleRoot.java:112: >>>> error: cannot find symbol >>>> [ant:javac] private AccessibleProvider hostRawElementProvider() { >>>> >>>> etc, etc >>>> >>>> >>>> On 20 March 2013 17:55, Richard Bair wrote: >>>>> I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. >>>>> >>>>> To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). >>>>> >>>>> cd rt >>>>> gradle -b generator.gradle >>>>> cd ../javafx >>>>> gradle sdk >>>>> >>>>> You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. >>>>> >>>>> It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar >>>>> >>>>> Please give it a try and let me know if it works for you or if it fails. >>>>> >>>>> I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. >>>>> >>>>> Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. >>>>> >>>>> My next tasks: >>>>> - confirm javadoc generation works >>>>> - fix any failing tests or configuration that causes tests to fail >>>>> - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster >>>>> - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script >>>>> - fix any build issues reported on this thread >>>>> - IDE integration >>>>> >>>>> Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. >>>>> >>>>> Richard >>>> >>>> >>>> >>>> -- >>>> Peter Pilgrim, >>>> **Java Champion**, >>>> Java EE Software Development / Design / Architect for `BlueChip' >>>> enterprises, London, UK >>>> >>>> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >>>> >>>> :: http://www.xenonique.co.uk/blog/ :: >>>> :: http://twitter.com/peter_pilgrim :: >>>> :: http://audio.fm/profile/peter_pilgrim :: >>>> :: Skype Call peter_pilgrim :: >>>> :: http://java-champions.java.net/ :: >>> >> > > > > -- > Peter Pilgrim, > **Java Champion**, > Java EE Software Development / Design / Architect for `BlueChip' > enterprises, London, UK > > JavaFX ++ Scala ++ Groovy ++ Android ++ Java > > :: http://www.xenonique.co.uk/blog/ :: > :: http://twitter.com/peter_pilgrim :: > :: http://audio.fm/profile/peter_pilgrim :: > :: Skype Call peter_pilgrim :: > :: http://java-champions.java.net/ :: From hang.vo at oracle.com Wed Mar 20 15:18:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 22:18:59 +0000 Subject: hg: openjfx/8/graphics/rt: Added support for generation of javadocs. This comes in two parts: first, there is the ability to generate javadocs normally as on any Java project. Second, I added a top-level javadoc task that will be used to create a single aggregate javadoc in the top-level build directory. The javadocs are linked to Java 7 docs (but should be linked to Java 8 when doing RE builds). This is provided by the JDK_DOCS property. Another doc property, DOC_LINT is used to specify what the lint level should be for generating javadocs. Message-ID: <20130320221906.75902482BD@hg.openjdk.java.net> Changeset: 3db24fb4cad3 Author: Richard Bair Date: 2013-03-20 15:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3db24fb4cad3 Added support for generation of javadocs. This comes in two parts: first, there is the ability to generate javadocs normally as on any Java project. Second, I added a top-level javadoc task that will be used to create a single aggregate javadoc in the top-level build directory. The javadocs are linked to Java 7 docs (but should be linked to Java 8 when doing RE builds). This is provided by the JDK_DOCS property. Another doc property, DOC_LINT is used to specify what the lint level should be for generating javadocs. I also moved the top-level tasks to the bottom of the file so they have access to all the configured projects. Finally, I found that a number of Builders were being included in the Jar & JavaDoc which had no business there! I had to add a workaround such that we remove those builders (java and .class) after they've been generated in the compile step. ! build.gradle From hang.vo at oracle.com Wed Mar 20 15:18:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Mar 2013 22:18:59 +0000 Subject: hg: openjfx/8/controls/rt: Modena: fixed checkbox in table view in single cell selection had wrong border color. Message-ID: <20130320221906.C3A19482BE@hg.openjdk.java.net> Changeset: 1293b4bf044e Author: "Jasper Potts" Date: 2013-03-20 15:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1293b4bf044e Modena: fixed checkbox in table view in single cell selection had wrong border color. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Wed Mar 20 18:34:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 01:34:38 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130321013448.31A9F482CF@hg.openjdk.java.net> Changeset: 1fcd9b3e921a Author: Alexander Kouznetsov Date: 2013-03-20 18:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1fcd9b3e921a Fix for RT-29050 CustomColorDialog does not limit access to its internal structure for the classes in its package ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java Changeset: efea9d5c5826 Author: Alexander Kouznetsov Date: 2013-03-20 18:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/efea9d5c5826 Fix for RT-29051 CustomColorDialog Save button not always saves the color ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Wed Mar 20 18:48:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 01:48:58 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130321014904.F3060482D0@hg.openjdk.java.net> Changeset: fd6edcfb8852 Author: Alexander Kouznetsov Date: 2013-03-20 18:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fd6edcfb8852 Fixed RT-29072 CustomColorDialog hue gradient is diagonal ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: b9ff8f77688e Author: Alexander Kouznetsov Date: 2013-03-20 18:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b9ff8f77688e Fixed CustomColorDialog related issue of RT-24375 Evaluate findbugs issues in control code ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Wed Mar 20 19:19:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 02:19:09 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130321021915.B5859482D1@hg.openjdk.java.net> Changeset: d9e1e0d00cea Author: jgiles Date: 2013-03-21 15:11 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d9e1e0d00cea RT-29111: 8.0-controls-scrum-438: benchmarks Controls.ListView-Keyboard and Controls.TableViewView-Keyboard fail with ArrayIndexOutOfBoundsException ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 8830929006b0 Author: jgiles Date: 2013-03-21 15:12 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8830929006b0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Wed Mar 20 22:49:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 05:49:01 +0000 Subject: hg: openjfx/8/controls/rt: Exclude auto-generated *Builder classes from Cobertura unit test coverage reports. Message-ID: <20130321054907.20F55482D6@hg.openjdk.java.net> Changeset: ed5cf47ecb1e Author: jgiles Date: 2013-03-21 18:36 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ed5cf47ecb1e Exclude auto-generated *Builder classes from Cobertura unit test coverage reports. ! build-defs.xml From hang.vo at oracle.com Thu Mar 21 00:19:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 07:19:07 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28488 Change Glass Screen for MT access Message-ID: <20130321071913.B5CA1482D9@hg.openjdk.java.net> Changeset: 35dae1e875af Author: Petr Pchelko Date: 2013-03-21 11:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/35dae1e875af RT-28488 Change Glass Screen for MT access Reviewed-by: Anthony, Steve ! glass/glass-lib-gtk/src/GlassApplication.cpp ! glass/glass-lib-gtk/src/glass_general.cpp ! glass/glass-lib-ios/Makefile ! glass/glass-lib-ios/src/GlassApplication.m + glass/glass-lib-ios/src/GlassScreen.h ! glass/glass-lib-ios/src/GlassScreen.m ! glass/glass-lib-lens/build.xml ! glass/glass-lib-lens/src/LensApplication.c ! glass/glass-lib-lens/src/LensCommon.h ! glass/glass-lib-lens/src/LensScreen.c ! glass/glass-lib-macosx/Makefile ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass-lib-macosx/src/GlassScreen.h ! glass/glass-lib-macosx/src/GlassScreen.m ! glass/glass-lib-macosx/src/GlassTimer.m ! glass/glass-lib-windows/Makefile ! glass/glass-lib-windows/src/GlassApplication.cpp ! glass/glass-lib-windows/src/GlassScreen.cpp ! glass/glass-lib-windows/src/GlassScreen.h ! glass/glass-lib-windows/src/Utils.h ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/Screen.java ! glass/glass/src/com/sun/glass/ui/gtk/GtkApplication.java ! glass/glass/src/com/sun/glass/ui/ios/IosApplication.java - glass/glass/src/com/sun/glass/ui/ios/IosScreen.java ! glass/glass/src/com/sun/glass/ui/lens/LensApplication.java - glass/glass/src/com/sun/glass/ui/lens/LensScreen.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java - glass/glass/src/com/sun/glass/ui/mac/MacScreen.java ! glass/glass/src/com/sun/glass/ui/mac/MacTimer.java ! glass/glass/src/com/sun/glass/ui/swt/SWTApplication.java - glass/glass/src/com/sun/glass/ui/swt/SWTScreen.java ! glass/glass/src/com/sun/glass/ui/win/WinApplication.java - glass/glass/src/com/sun/glass/ui/win/WinScreen.java From hang.vo at oracle.com Thu Mar 21 01:34:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 08:34:53 +0000 Subject: hg: openjfx/8/graphics/rt: RT-21999 Win: FileChooser does not accept valid initial directory. Message-ID: <20130321083507.2EE17482DC@hg.openjdk.java.net> Changeset: 281f59feb34e Author: Petr Pchelko Date: 2013-03-21 12:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/281f59feb34e RT-21999 Win: FileChooser does not accept valid initial directory. Reviewed-by: Anthony ! glass/glass/src/com/sun/glass/ui/CommonDialogs.java From neugens at redhat.com Thu Mar 21 01:50:07 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 21 Mar 2013 09:50:07 +0100 Subject: Gradle build progress In-Reply-To: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> Message-ID: <514AC9BF.2020907@redhat.com> On 03/20/2013 06:55 PM, Richard Bair wrote: > I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations. > > To try out the gradle scripts, get the latest graphics repo (http://hg.openjdk.java.net/openjfx/8/graphics, http://hg.openjdk.java.net/openjfx/8/graphics/rt). > > cd rt > gradle -b generator.gradle > cd ../javafx > gradle sdk > > You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle. > > It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar > > Please give it a try and let me know if it works for you or if it fails. Hi Richard, I can confirm I have the same problem that Peter has (btw, I tried with Gradle 1.3 and seem to work to the same extent that 1.4 does). I guess the real solution is to open another couple of bits of code ;) > I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. > > Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. I think this will be a major problem for everybody, indeed. I believe the sanest thing to do is not ship OpenJFX in the ext directory for OpenJDK, or it will make rebuilding from sources next to impossible in Linux distributions. I wish Oracle would follow this advice and remove this library from Java 8, people who really rely on the jar to be in part of the external libraries can put it back there any time (i.e. an installer can be provided that put it back there). > My next tasks: > - confirm javadoc generation works > - fix any failing tests or configuration that causes tests to fail > - specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster > - jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script > - fix any build issues reported on this thread > - IDE integration > > Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine. Neat! Cheers, Mario From phdoerfler at gmail.com Thu Mar 21 04:33:39 2013 From: phdoerfler at gmail.com (=?windows-1252?Q?Philipp_D=F6rfler?=) Date: Thu, 21 Mar 2013 12:33:39 +0100 Subject: Threading and Node.lookup In-Reply-To: References: <5C2208E9-D4DA-49C2-BFA2-9D0AAC101DAA@gmail.com> <5148F51C.2020202@oracle.com> <467F2078-CBA4-41D1-839F-49F932D21282@gmail.com> <5148F9AC.5050709@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221678837228@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5149206F.6080001@oracle.com> <7725F01C-64AE-42D2-8353-793845C6F256@gmail.com> <51496846.1000604@bestsolution.at> <51498D62.6070902@oracle.com> <00E80D72-C457-4A24-A1E9-BB63E7365A5F@gmail.com> Message-ID: <3F92978E-88EF-495D-899E-51CB5A035F91@gmail.com> I created another gist showing that just attaching to a Scene is not enough: https://gist.github.com/phdoerfler/5212324 This code is running in the FX application thread. Showing the stage fixes the lookup. Running the code in Platform.runLater does - as expected - not buy you anything extra. This seems obvious, but I remember having some code which does different things depending on whether it's running inside of Platform.runLater, even when already running in the FXAT. That was ScalaFX code however running in a DelayedInit trait. ~ philipp Am 20.03.2013 um 14:42 schrieb Scott Palmer : > #3 doesn't appear to be a requirement. > > Re #4 If you have attached a Scene you had to do it on the FX Application thread, so runLater probably doesn't buy you anything. > > It seems that just being attached to the Scene is the requirement. > > Scott > > On 2013-03-20, at 7:27 AM, Philipp D?rfler wrote: > >> So in order to reliably lookup a node, one has to: >> >> 1. Create a Scene with that scenegraph in it >> 2. Attach that Scene to a Stage >> 3. Show that Stage >> 4. OR alternatively (does not help always), call this without a Scene, but in Platform.runLater >> >> This this a bit too arcane for my taste. I can see that due to limitations one has to create a Scene and place nodes in there. I can't say I'm exceptionally happy with that, but it'll do for now. Those restrictions are probably there for a reason. >> However - I don't entirely understand why sometimes it is necessary to actually _show_ a Stage with your nodes to have CSS lookups work (As indicated by John. I ran into this, too). Any chance that this might change? I'm not talking about querying CSS attributes unknown to that point. Only thing I want to do are simple lookups. >> Is it because of Skin and that it is unknown how exactly the scene graph is composed without evaluating all Control's skins, thus creating more nodes which then might in turn have CSS style-classes (or IDs for that matter) assigned? Is this only possibly by showing a stage? >> >> Assuming that this is not going to change any time soon: Is it possible to re-invent the wheel, thus manually traversing the scene graph and querying each and every node for it's id and style class and so on or would that need to be attached to a Scene (and thus runLater...) and/or need to be shown, too? >> >> Cheers and thanks for your time, >> ~ Philipp >> >> Am 20.03.2013 um 11:20 schrieb Kevin Rushforth : >> >>> There are some limitations in the CSS engine that require it to be attached to the scene before it will process nodes. I ran into this with snapshot, so a common workaround for apps that want to take a snapshot of a Node that isn't attached to a scene is to create a dummy Scene and attach the node in question to that Scene. See http://javafx-jira.kenai.com/browse/RT-22558 for example. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>>> Actually in this case the CSS engine should process immediately (it won't batch up this call, it must be synchronous) -- however it may be that there are some shared data structures being foiled by multiple threads. Not sure though, just a wild guess :-) >>>> >>>> On Mar 20, 2013, at 12:41 AM, Tom Schindl wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> The problem is that the lookup system depends on the CSS-Engine (you can >>>>> pass any CSS-Selector!) to having processed the Node. >>>>> >>>>> My guess is that the CSS-Engine does only processes nodes when they are >>>>> attached to the Scene (there's no reason for it to process them if they >>>>> are not attached). >>>>> >>>>> Tom >>>>> >>>>> Am 20.03.13 04:47, schrieb Scott Palmer: >>>>> >>>>>> Yes, good point. In that case I could delay the connection to the Scene object and instead do the lookup via the root node. But still in this case, has a rendering pass ("pulse") happened yet on such a Scene? Since Scene objects must be constructed and modified on the FX app thread I guess it makes sense that they would do an initial layout pass on the root node? So perhaps John is correct. It's late and I don't have time to construct a test case now. >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>> On 2013-03-19, at 10:35 PM, Kevin Rushforth wrote: >>>>>> >>>>>> >>>>>>>> Node background = scene.lookup("#background"); >>>>>>>> >>>>>>> Note that this particular call references a scene, so must be done on the FX application thread. You should not touch the scene or a node that is connected to a scene on a background thread. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Scott Palmer wrote: >>>>>>> >>>>>>>> On 2013-03-19, at 8:30 PM, John Smith wrote: >>>>>>>> >>>>>>>> >>>>>>>>> "the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene" >>>>>>>>> >>>>>>>>> >>>>>>>> I don't think that is exactly right. I'm sure I used the lookup method to grab nodes from a scene graph that I made with Scene Builder *prior* to showing it. >>>>>>>> >>>>>>>> Yep? I just checked my code, this doesn't return nulls: >>>>>>>> >>>>>>>> ? >>>>>>>> Parent root = FXMLLoader.load(location); >>>>>>>> Scene scene = new Scene(root); >>>>>>>> Node top = scene.lookup("#top"); >>>>>>>> Node background = scene.lookup("#background"); >>>>>>>> ? >>>>>>>> >>>>>>>> The Scene clearly was just constructed and isn't showing or part of a Stage. >>>>>>>> The only difference is that this is called on the Platform thread. So something must be happening that needs to run on the Platform thread. >>>>>>>> >>>>>>>> You are correct about the width/height stuff that requires a layout pass to have happened before you get reasonable values. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> +1 to Philipp's question. >>>>>>>>> >>>>>>>>> It's always been the case that the node lookup function doesn't function (just returns null) until a rendering pass has been run on the scene. >>>>>>>>> >>>>>>>>> With Philipp's sample at (https://gist.github.com/phdoerfler/5201162) , if you implemented it as an Application, placed the item to be looked up in a stage, and called lookup only *after* you called stage.show on your scene, then the lookup would work (without requiring Platform.runLater) - so some side effect of showing the scene on the stage allows nodes in the scene to be looked up. >>>>>>>>> >>>>>>>>> It works the same way as trying to get the height and width of a node before it has been shown on stage - that also does not really work as you might expect because the css needs to be processed in the rendering pass to accurately determine the height and width. I understand why height and width work the way they do, but I was never really sure why lookup doesn't just work immediately and the delayed behavior isn't documented anywhere. >>>>>>>>> >>>>>>>>> Likely there is some hidden impl_ function you could use to trigger the rendering pass, after which the lookup would work. >>>>>>>>> >>>>>>>>> - John >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth >>>>>>>>> Sent: Tuesday, March 19, 2013 4:50 PM >>>>>>>>> To: Philipp D?rfler >>>>>>>>> Cc: openjfx-dev at openjdk.java.net List >>>>>>>>> Subject: Re: Threading and Node.lookup >>>>>>>>> >>>>>>>>> One of the scene graph or FXML folks should be able to reply. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Philipp D?rfler wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Ok, threading aside: Where's my mistake? >>>>>>>>>> >>>>>>>>>> https://gist.github.com/phdoerfler/5201162 >>>>>>>>>> >>>>>>>>>> ~ philipp >>>>>>>>>> >>>>>>>>>> Am 20.03.2013 um 00:30 schrieb Kevin Rushforth : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> In general is is legal to call accessor and mutator methods on a Node not attached to a Scene from any thread. I don't specifically know whether lookup does anything that would add additional threading restrictions. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Philipp D?rfler wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> does fooNode.lookup("#bar") have to be called using Platform.runLater if fooNode is not attached to any Scene? >>>>>>>>>>>> As to my understanding, one only has to use Platform.runLater for accessing nodes already attached to a Scene. >>>>>>>>>>>> >>>>>>>>>>>> However, fooNode.lookup seems to fail (= return null) for nodes which are not contained directly in it, but in another node (in my case: a ScrollPane), which is then contained in fooNode. The scene graph was provided by FXMLLoader.load(...). >>>>>>>>>>>> >>>>>>>>>>>> Placing those lookups in Platform.runLater suddenly causes them to work. >>>>>>>>>>>> >>>>>>>>>>>> This feels like an arcane bug to me, but I might be missing some core concepts. >>>>>>>>>>>> So - did I miss something or is this a bug? >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Philipp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>>> ------------------------------------------------------------------------ >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------------------------------------------------ >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>>> http://www.BestSolution.at phone ++43 512 935834 >>>>> >>>> >>>> >> > From hang.vo at oracle.com Thu Mar 21 05:19:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 12:19:19 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed failing tests after RT-28488 Message-ID: <20130321121928.A1946482E4@hg.openjdk.java.net> Changeset: db480c3a5d19 Author: Petr Pchelko Date: 2013-03-21 16:08 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/db480c3a5d19 Fixed failing tests after RT-28488 ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java From cognitionmission at gmail.com Thu Mar 21 06:07:41 2013 From: cognitionmission at gmail.com (David Ray) Date: Thu, 21 Mar 2013 08:07:41 -0500 Subject: Duplicating a Node In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D2216788376E4@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <5143634D.9050504@xs4all.nl> <5146DCC3.8010701@oracle.com> <5148810E.40502@xs4all.nl> <5149C9EB.5000907@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216788376E4@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Why wouldn't the ability to dynamically update nodes with transforms on them, be a priority? David Ray Sent from my iPhone On Mar 20, 2013, at 12:56 PM, John Smith wrote: > Another user was encountering a similar (but different) requirement to John where they wanted to take a Reflection and blur it, which seemed a reasonable request, but was quite difficult to achieve with the current APIs, so I can see where the request for "something (an Effect or NodeReference)" is coming from. Today the only way to get such a thing is to chain the input effects on the Node (which doesn't always do what you need), or snapshot the nodes (but then you need to keep retaking snapshots if you have dynamic content). > > The Node duplication request seems to be a relatively infrequent requirement and perhaps it would be difficult to implement, so, though it seems like a nice feature, I'd guess it's implementation wouldn't be high priority. Also, maybe in the future it will be easy to create your own custom effects on Nodes, which might obviate the Node duplication request in some cases. > >> The best approximation I can suggest is rendering the node to image via Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. > > The solution I used for blurring a reflection was the same approximation method Pavel suggests of taking a Snapshot: > https://forums.oracle.com/forums/thread.jspa?threadID=2496389 "Thread: Effects on effects" > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Pavel Safrata > Sent: Wednesday, March 20, 2013 7:39 AM > To: openjfx-dev at openjdk.java.net > Subject: Re: Duplicating a Node > > Hi John, > I'm afraid something like this is not really supported. The best approximation I can suggest is rendering the node to image via > Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. With dynamic contents, you will have to find your own way to tell when to re-generate the image.. > Regards, > Pavel > > On 19.3.2013 16:15, John Hendrikx wrote: >> On 18/03/2013 10:22, Pavel Safrata wrote: >>> Hi John, >>> I tried to use reflection on node with PerspectiveTransform and I >>> don't see anything wrong with it - no alternating size, no incorrect >>> reflection. Could you please elaborate on what you are trying to >>> achieve? Code that I used: >>> >>> Rectangle rect = new Rectangle(100, 50, Color.RED); >>> Reflection r = new Reflection(); >>> r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, >>> 0, 80)); >>> rect.setEffect(r); >> Look at the reflection for this Rectangle instead: >> >> Rectangle rect = new Rectangle(100, 50, Color.RED); >> Reflection r = new Reflection(); >> r.setInput(new PerspectiveTransform(50, 40, 100, 50, 100, 70, >> 50, 80)); >> rect.setEffect(r); >> >> Notice that the Reflection is not what you'd expect for a Node that >> has the appearance of being 3D. >> >> So, that is not the problem. It is perfectly possible to create a >> Reflection from an object that has a PerspectiveTransform applied to >> it. The problem is that the reflection created is simplistic in that >> it assumes the object must be reflected in a horizontal line somewhere >> below the object (which is fine for 2D stuff, but not if you are >> trying to make your Nodes look 3D with reflections). Please see >> http://www.youtube.com/watch?v=8Mb15bOwIyE and look how the >> reflections there are exactly attached to the bottom of >> PerspectiveTransform'ed Nodes, no spacing. >> >> When you apply a PerspectiveTransform, the idea is to make the object >> look 3D. The Reflection therefore must also be 3D, which means you >> cannot just create it by copying an upside-down image of the object >> below the PerspectiveTransformed object. Instead the Reflection >> should also be 3D and the line it should reflect in is the bottom line >> of the object AFTER the PerspectiveTransform was applied (and this >> line is not always horizontal). Here's some ASCII art: >> >> OOOO >> OOOOOOOO >> OOOOOOOO >> OOOOOOOO >> OOOORRRR >> RRRRRRRR >> RRRRRRRR >> RRRRRR >> RRR >> >> Instead of: >> >> OOOO >> OOOOOOOO >> OOOOOOOO >> OOOOOOOO >> OOOO >> RRRR >> RRRRRRRR >> RRRRRRRR >> RRRRRRRR >> RRRR >> >> Now, it is possible to achieve this by reversing the inputs, first >> doing the Reflection, then looking at how Reflection changed the Node, >> then applying a PerspectiveTransform that gets the correct 3D result. >> However, this is very cumbersome, makes assumptions about how >> Reflection will change your Node and does not allow for creation of >> Reflections for Objects that have more than just a rotation on the Y >> axis applied to them. >> >> This is why I really need something (an Effect or NodeReference) that >> could create a duplicate of a Node :) >> >> --John >> >>> >>> Regards, >>> Pavel >>> >>> On 15.3.2013 19:07, John Hendrikx wrote: >>>> Hi list, >>>> >>>> I'm trying to achieve an effect that requires me to make a copy of a >>>> Node, apply some effect(s) on it (PerspectiveTransform, Clip, Blend >>>> and perhaps DisplacementMap) and place it in the same scenegraph >>>> together with the original. >>>> >>>> It is very similar to what Reflection achieves, but without >>>> alternating the size of the Node, and without the limitations >>>> (specifically, creating the correct Reflection for an object that >>>> has a PerspectiveTransform applied to it already cannot be done with >>>> Reflection). >>>> >>>> I would prefer not to have to make an actual copy of the Node, as >>>> they might get out of sync and not display the same content when >>>> they should be. Something like a NodeReference class, that takes >>>> another Node as parameter but applies different >>>> effects/clips/transforms. >>>> >>>> Since the code I'm using for this is based on Cells getting laid >>>> out, I'm toying with the idea of actually asking the provider of >>>> those cells twice for the same cell and applying different >>>> transformations on each, but they might get out of sync and it seems >>>> there should be a better way. >>>> >>>> Any ideas or suggestions at how I could best achieve this, or would >>>> it be a new feature? >>>> >>>> --John > From hang.vo at oracle.com Thu Mar 21 07:19:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 14:19:09 +0000 Subject: hg: openjfx/8/graphics/rt: RT-21347 Mac: Invalid memory access of location when calling stage.hide() Message-ID: <20130321141914.A7EE9482EA@hg.openjdk.java.net> Changeset: 6ea4187e06ba Author: Petr Pchelko Date: 2013-03-21 18:10 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6ea4187e06ba RT-21347 Mac: Invalid memory access of location when calling stage.hide() Reviewed-by: Anthony ! glass/glass-lib-macosx/src/GlassWindow+Java.m ! glass/glass-lib-macosx/src/GlassWindow.h ! glass/glass-lib-macosx/src/GlassWindow.m From John_Smith at symantec.com Thu Mar 21 10:22:53 2013 From: John_Smith at symantec.com (John Smith) Date: Thu, 21 Mar 2013 10:22:53 -0700 Subject: Duplicating a Node In-Reply-To: References: <5143634D.9050504@xs4all.nl> <5146DCC3.8010701@oracle.com> <5148810E.40502@xs4all.nl> <5149C9EB.5000907@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216788376E4@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221678837F65@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > Why wouldn't the ability to dynamically update nodes with transforms on them, be a priority? Hello David, It's just my opinion that "the Node duplication request seems to be a relatively infrequent requirement and perhaps it would be difficult to implement, so, though it seems like a nice feature, I'd guess it's implementation wouldn't be high priority". I am not an Oracle employee nor do I choose priorities for the project. Also, you can already dynamically update nodes with transforms on them, the opinion I offered was regard to Node duplication, not dynamically updating nodes with transforms. If the addition of a Node duplication feature is important, please file a feature request at: http://javafx-jira.kenai.com/ (which is undergoing maintenance at this time). Jira has a voting and commenting system where you can vote for and comment on issues and feature requests. I believe that the JavaFX planning team takes these votes and comments on logged issues into account when planning future work. Regards, John -----Original Message----- From: David Ray [mailto:cognitionmission at gmail.com] Sent: Thursday, March 21, 2013 6:08 AM To: John Smith Cc: Pavel Safrata; openjfx-dev at openjdk.java.net Subject: Re: Duplicating a Node Why wouldn't the ability to dynamically update nodes with transforms on them, be a priority? David Ray Sent from my iPhone On Mar 20, 2013, at 12:56 PM, John Smith wrote: > Another user was encountering a similar (but different) requirement to John where they wanted to take a Reflection and blur it, which seemed a reasonable request, but was quite difficult to achieve with the current APIs, so I can see where the request for "something (an Effect or NodeReference)" is coming from. Today the only way to get such a thing is to chain the input effects on the Node (which doesn't always do what you need), or snapshot the nodes (but then you need to keep retaking snapshots if you have dynamic content). > > The Node duplication request seems to be a relatively infrequent requirement and perhaps it would be difficult to implement, so, though it seems like a nice feature, I'd guess it's implementation wouldn't be high priority. Also, maybe in the future it will be easy to create your own custom effects on Nodes, which might obviate the Node duplication request in some cases. > >> The best approximation I can suggest is rendering the node to image via Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. > > The solution I used for blurring a reflection was the same approximation method Pavel suggests of taking a Snapshot: > https://forums.oracle.com/forums/thread.jspa?threadID=2496389 "Thread: Effects on effects" > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Pavel > Safrata > Sent: Wednesday, March 20, 2013 7:39 AM > To: openjfx-dev at openjdk.java.net > Subject: Re: Duplicating a Node > > Hi John, > I'm afraid something like this is not really supported. The best > approximation I can suggest is rendering the node to image via > Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. With dynamic contents, you will have to find your own way to tell when to re-generate the image.. > Regards, > Pavel > > On 19.3.2013 16:15, John Hendrikx wrote: >> On 18/03/2013 10:22, Pavel Safrata wrote: >>> Hi John, >>> I tried to use reflection on node with PerspectiveTransform and I >>> don't see anything wrong with it - no alternating size, no incorrect >>> reflection. Could you please elaborate on what you are trying to >>> achieve? Code that I used: >>> >>> Rectangle rect = new Rectangle(100, 50, Color.RED); >>> Reflection r = new Reflection(); >>> r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, >>> 0, 80)); >>> rect.setEffect(r); >> Look at the reflection for this Rectangle instead: >> >> Rectangle rect = new Rectangle(100, 50, Color.RED); >> Reflection r = new Reflection(); >> r.setInput(new PerspectiveTransform(50, 40, 100, 50, 100, 70, >> 50, 80)); >> rect.setEffect(r); >> >> Notice that the Reflection is not what you'd expect for a Node that >> has the appearance of being 3D. >> >> So, that is not the problem. It is perfectly possible to create a >> Reflection from an object that has a PerspectiveTransform applied to >> it. The problem is that the reflection created is simplistic in that >> it assumes the object must be reflected in a horizontal line >> somewhere below the object (which is fine for 2D stuff, but not if >> you are trying to make your Nodes look 3D with reflections). Please >> see http://www.youtube.com/watch?v=8Mb15bOwIyE and look how the >> reflections there are exactly attached to the bottom of >> PerspectiveTransform'ed Nodes, no spacing. >> >> When you apply a PerspectiveTransform, the idea is to make the object >> look 3D. The Reflection therefore must also be 3D, which means you >> cannot just create it by copying an upside-down image of the object >> below the PerspectiveTransformed object. Instead the Reflection >> should also be 3D and the line it should reflect in is the bottom >> line of the object AFTER the PerspectiveTransform was applied (and >> this line is not always horizontal). Here's some ASCII art: >> >> OOOO >> OOOOOOOO >> OOOOOOOO >> OOOOOOOO >> OOOORRRR >> RRRRRRRR >> RRRRRRRR >> RRRRRR >> RRR >> >> Instead of: >> >> OOOO >> OOOOOOOO >> OOOOOOOO >> OOOOOOOO >> OOOO >> RRRR >> RRRRRRRR >> RRRRRRRR >> RRRRRRRR >> RRRR >> >> Now, it is possible to achieve this by reversing the inputs, first >> doing the Reflection, then looking at how Reflection changed the >> Node, then applying a PerspectiveTransform that gets the correct 3D result. >> However, this is very cumbersome, makes assumptions about how >> Reflection will change your Node and does not allow for creation of >> Reflections for Objects that have more than just a rotation on the Y >> axis applied to them. >> >> This is why I really need something (an Effect or NodeReference) that >> could create a duplicate of a Node :) >> >> --John >> >>> >>> Regards, >>> Pavel >>> >>> On 15.3.2013 19:07, John Hendrikx wrote: >>>> Hi list, >>>> >>>> I'm trying to achieve an effect that requires me to make a copy of >>>> a Node, apply some effect(s) on it (PerspectiveTransform, Clip, >>>> Blend and perhaps DisplacementMap) and place it in the same >>>> scenegraph together with the original. >>>> >>>> It is very similar to what Reflection achieves, but without >>>> alternating the size of the Node, and without the limitations >>>> (specifically, creating the correct Reflection for an object that >>>> has a PerspectiveTransform applied to it already cannot be done >>>> with Reflection). >>>> >>>> I would prefer not to have to make an actual copy of the Node, as >>>> they might get out of sync and not display the same content when >>>> they should be. Something like a NodeReference class, that takes >>>> another Node as parameter but applies different >>>> effects/clips/transforms. >>>> >>>> Since the code I'm using for this is based on Cells getting laid >>>> out, I'm toying with the idea of actually asking the provider of >>>> those cells twice for the same cell and applying different >>>> transformations on each, but they might get out of sync and it >>>> seems there should be a better way. >>>> >>>> Any ideas or suggestions at how I could best achieve this, or would >>>> it be a new feature? >>>> >>>> --John > From swpalmer at gmail.com Thu Mar 21 11:55:57 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 21 Mar 2013 14:55:57 -0400 Subject: TableColumn$SortType Message-ID: I know there is a bunch of working going on to re-work the table sorting.. but I was under the impression that it wasn't going to break existing code. I'm getting a java.lang.NoClassDefFoundError: javafx/scene/control/TableColumn$SortType in my code when I run on JavaFX 8.0-b81 JavaFX Bug? (I hope) Regards, Scott From jonathan.giles at oracle.com Thu Mar 21 12:20:22 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 22 Mar 2013 08:20:22 +1300 Subject: TableColumn$SortType In-Reply-To: References: Message-ID: <514B5D76.5010409@oracle.com> SortType was in TableColumn but recently I moved it up to TableColumnBase, however from the looks of things that wasn't a good move as it breaks things. Please file a bug - I'll probably need to duplicate SortType in TableColumn and TreeTableColumn, which is a shame, but that's the price we pay for not wanting to break API (and the fact that all API is not built in a single big bang!) :-) -- Jonathan On Friday, 22 March 2013 7:55:57 a.m., Scott Palmer wrote: > I know there is a bunch of working going on to re-work the table sorting.. but I was under the impression that it wasn't going to break existing code. > > I'm getting a java.lang.NoClassDefFoundError: javafx/scene/control/TableColumn$SortType in my code when I run on JavaFX 8.0-b81 > > JavaFX Bug? (I hope) > > > Regards, > > Scott > > > From swpalmer at gmail.com Thu Mar 21 12:33:09 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 21 Mar 2013 15:33:09 -0400 Subject: TableColumn$SortType In-Reply-To: <514B5D76.5010409@oracle.com> References: <514B5D76.5010409@oracle.com> Message-ID: Is just using TableColumn.SortType from within TreeTableColumn out of the question? Scott (I'll get that bug filed when Jira is back online) On 2013-03-21, at 3:20 PM, Jonathan Giles wrote: > SortType was in TableColumn but recently I moved it up to TableColumnBase, however from the looks of things that wasn't a good move as it breaks things. > > Please file a bug - I'll probably need to duplicate SortType in TableColumn and TreeTableColumn, which is a shame, but that's the price we pay for not wanting to break API (and the fact that all API is not built in a single big bang!) :-) > > -- Jonathan > > On Friday, 22 March 2013 7:55:57 a.m., Scott Palmer wrote: >> I know there is a bunch of working going on to re-work the table sorting.. but I was under the impression that it wasn't going to break existing code. >> >> I'm getting a java.lang.NoClassDefFoundError: javafx/scene/control/TableColumn$SortType in my code when I run on JavaFX 8.0-b81 >> >> JavaFX Bug? (I hope) >> >> >> Regards, >> >> Scott >> >> >> From jonathan.giles at oracle.com Thu Mar 21 12:35:38 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 22 Mar 2013 08:35:38 +1300 Subject: TableColumn$SortType In-Reply-To: References: <514B5D76.5010409@oracle.com> Message-ID: <514B610A.1000806@oracle.com> Right, to clarify, this change was related to the introduction of TreeTableView ~3 months ago, not the more recent change to sorting. I'll need to research the best option. The downside is that the impl code all depends on TableColumnBase rather than TableColumn and TreeTableColumn, so losing the sortType API from TableColumnBase is the bigger concern. Like I say, file a bug and I'll work out how to resolve this. -- Jonathan On 22/03/2013 8:33 a.m., Scott Palmer wrote: > Is just using TableColumn.SortType from within TreeTableColumn out of the question? > > Scott > (I'll get that bug filed when Jira is back online) > > On 2013-03-21, at 3:20 PM, Jonathan Giles wrote: > >> SortType was in TableColumn but recently I moved it up to TableColumnBase, however from the looks of things that wasn't a good move as it breaks things. >> >> Please file a bug - I'll probably need to duplicate SortType in TableColumn and TreeTableColumn, which is a shame, but that's the price we pay for not wanting to break API (and the fact that all API is not built in a single big bang!) :-) >> >> -- Jonathan >> >> On Friday, 22 March 2013 7:55:57 a.m., Scott Palmer wrote: >>> I know there is a bunch of working going on to re-work the table sorting.. but I was under the impression that it wasn't going to break existing code. >>> >>> I'm getting a java.lang.NoClassDefFoundError: javafx/scene/control/TableColumn$SortType in my code when I run on JavaFX 8.0-b81 >>> >>> JavaFX Bug? (I hope) >>> >>> >>> Regards, >>> >>> Scott >>> >>> >>> From cognitionmission at gmail.com Thu Mar 21 12:59:03 2013 From: cognitionmission at gmail.com (David Ray) Date: Thu, 21 Mar 2013 14:59:03 -0500 Subject: Duplicating a Node In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221678837F65@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <5143634D.9050504@xs4all.nl> <5146DCC3.8010701@oracle.com> <5148810E.40502@xs4all.nl> <5149C9EB.5000907@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216788376E4@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <411E73D23DEC4C46BA48F2B6D8BF3D221678837F65@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <3B5B48F5-C84A-4A64-8950-1926F3A291C3@gmail.com> Thank you for John for taking the time to explain my misinterpretation. And I'm glad I was wrong! :) Also thank you everybody for your hard work! David Sent from my iPhone On Mar 21, 2013, at 12:22 PM, John Smith wrote: >> Why wouldn't the ability to dynamically update nodes with transforms on them, be a priority? > > Hello David, > > It's just my opinion that "the Node duplication request seems to be a relatively infrequent requirement and perhaps it would be difficult to implement, so, though it seems like a nice feature, I'd guess it's implementation wouldn't be high priority". I am not an Oracle employee nor do I choose priorities for the project. > > Also, you can already dynamically update nodes with transforms on them, the opinion I offered was regard to Node duplication, not dynamically updating nodes with transforms. > > If the addition of a Node duplication feature is important, please file a feature request at: http://javafx-jira.kenai.com/ (which is undergoing maintenance at this time). Jira has a voting and commenting system where you can vote for and comment on issues and feature requests. I believe that the JavaFX planning team takes these votes and comments on logged issues into account when planning future work. > > Regards, > John > > -----Original Message----- > From: David Ray [mailto:cognitionmission at gmail.com] > Sent: Thursday, March 21, 2013 6:08 AM > To: John Smith > Cc: Pavel Safrata; openjfx-dev at openjdk.java.net > Subject: Re: Duplicating a Node > > Why wouldn't the ability to dynamically update nodes with transforms on them, be a priority? > > David Ray > > > Sent from my iPhone > > On Mar 20, 2013, at 12:56 PM, John Smith wrote: > >> Another user was encountering a similar (but different) requirement to John where they wanted to take a Reflection and blur it, which seemed a reasonable request, but was quite difficult to achieve with the current APIs, so I can see where the request for "something (an Effect or NodeReference)" is coming from. Today the only way to get such a thing is to chain the input effects on the Node (which doesn't always do what you need), or snapshot the nodes (but then you need to keep retaking snapshots if you have dynamic content). >> >> The Node duplication request seems to be a relatively infrequent requirement and perhaps it would be difficult to implement, so, though it seems like a nice feature, I'd guess it's implementation wouldn't be high priority. Also, maybe in the future it will be easy to create your own custom effects on Nodes, which might obviate the Node duplication request in some cases. >> >>> The best approximation I can suggest is rendering the node to image via Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. >> >> The solution I used for blurring a reflection was the same approximation method Pavel suggests of taking a Snapshot: >> https://forums.oracle.com/forums/thread.jspa?threadID=2496389 "Thread: Effects on effects" >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Pavel >> Safrata >> Sent: Wednesday, March 20, 2013 7:39 AM >> To: openjfx-dev at openjdk.java.net >> Subject: Re: Duplicating a Node >> >> Hi John, >> I'm afraid something like this is not really supported. The best >> approximation I can suggest is rendering the node to image via >> Node.snapshot(...) method (you can specify transform to it) and use this image for the reflection. With dynamic contents, you will have to find your own way to tell when to re-generate the image.. >> Regards, >> Pavel >> >> On 19.3.2013 16:15, John Hendrikx wrote: >>> On 18/03/2013 10:22, Pavel Safrata wrote: >>>> Hi John, >>>> I tried to use reflection on node with PerspectiveTransform and I >>>> don't see anything wrong with it - no alternating size, no incorrect >>>> reflection. Could you please elaborate on what you are trying to >>>> achieve? Code that I used: >>>> >>>> Rectangle rect = new Rectangle(100, 50, Color.RED); >>>> Reflection r = new Reflection(); >>>> r.setInput(new PerspectiveTransform(50, 40, 100, 40, 170, 80, >>>> 0, 80)); >>>> rect.setEffect(r); >>> Look at the reflection for this Rectangle instead: >>> >>> Rectangle rect = new Rectangle(100, 50, Color.RED); >>> Reflection r = new Reflection(); >>> r.setInput(new PerspectiveTransform(50, 40, 100, 50, 100, 70, >>> 50, 80)); >>> rect.setEffect(r); >>> >>> Notice that the Reflection is not what you'd expect for a Node that >>> has the appearance of being 3D. >>> >>> So, that is not the problem. It is perfectly possible to create a >>> Reflection from an object that has a PerspectiveTransform applied to >>> it. The problem is that the reflection created is simplistic in that >>> it assumes the object must be reflected in a horizontal line >>> somewhere below the object (which is fine for 2D stuff, but not if >>> you are trying to make your Nodes look 3D with reflections). Please >>> see http://www.youtube.com/watch?v=8Mb15bOwIyE and look how the >>> reflections there are exactly attached to the bottom of >>> PerspectiveTransform'ed Nodes, no spacing. >>> >>> When you apply a PerspectiveTransform, the idea is to make the object >>> look 3D. The Reflection therefore must also be 3D, which means you >>> cannot just create it by copying an upside-down image of the object >>> below the PerspectiveTransformed object. Instead the Reflection >>> should also be 3D and the line it should reflect in is the bottom >>> line of the object AFTER the PerspectiveTransform was applied (and >>> this line is not always horizontal). Here's some ASCII art: >>> >>> OOOO >>> OOOOOOOO >>> OOOOOOOO >>> OOOOOOOO >>> OOOORRRR >>> RRRRRRRR >>> RRRRRRRR >>> RRRRRR >>> RRR >>> >>> Instead of: >>> >>> OOOO >>> OOOOOOOO >>> OOOOOOOO >>> OOOOOOOO >>> OOOO >>> RRRR >>> RRRRRRRR >>> RRRRRRRR >>> RRRRRRRR >>> RRRR >>> >>> Now, it is possible to achieve this by reversing the inputs, first >>> doing the Reflection, then looking at how Reflection changed the >>> Node, then applying a PerspectiveTransform that gets the correct 3D result. >>> However, this is very cumbersome, makes assumptions about how >>> Reflection will change your Node and does not allow for creation of >>> Reflections for Objects that have more than just a rotation on the Y >>> axis applied to them. >>> >>> This is why I really need something (an Effect or NodeReference) that >>> could create a duplicate of a Node :) >>> >>> --John >>> >>>> >>>> Regards, >>>> Pavel >>>> >>>> On 15.3.2013 19:07, John Hendrikx wrote: >>>>> Hi list, >>>>> >>>>> I'm trying to achieve an effect that requires me to make a copy of >>>>> a Node, apply some effect(s) on it (PerspectiveTransform, Clip, >>>>> Blend and perhaps DisplacementMap) and place it in the same >>>>> scenegraph together with the original. >>>>> >>>>> It is very similar to what Reflection achieves, but without >>>>> alternating the size of the Node, and without the limitations >>>>> (specifically, creating the correct Reflection for an object that >>>>> has a PerspectiveTransform applied to it already cannot be done >>>>> with Reflection). >>>>> >>>>> I would prefer not to have to make an actual copy of the Node, as >>>>> they might get out of sync and not display the same content when >>>>> they should be. Something like a NodeReference class, that takes >>>>> another Node as parameter but applies different >>>>> effects/clips/transforms. >>>>> >>>>> Since the code I'm using for this is based on Cells getting laid >>>>> out, I'm toying with the idea of actually asking the provider of >>>>> those cells twice for the same cell and applying different >>>>> transformations on each, but they might get out of sync and it >>>>> seems there should be a better way. >>>>> >>>>> Any ideas or suggestions at how I could best achieve this, or would >>>>> it be a new feature? >>>>> >>>>> --John >> From hang.vo at oracle.com Thu Mar 21 13:04:41 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 20:04:41 +0000 Subject: hg: openjfx/8/graphics/rt: Add IDEA project generation to the build. This could be factored down all in one spot at the very bottom of the build file instead of spread around, or factored into a separate build script (probably a good idea). Message-ID: <20130321200452.D4E32482F7@hg.openjdk.java.net> Changeset: f43c24767b4c Author: Richard Bair Date: 2013-03-21 13:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f43c24767b4c Add IDEA project generation to the build. This could be factored down all in one spot at the very bottom of the build file instead of spread around, or factored into a separate build script (probably a good idea). ! build.gradle From hang.vo at oracle.com Thu Mar 21 14:34:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 21:34:06 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-21110 [ColorPicker] it is possible for no any pill to be selected. Message-ID: <20130321213419.0998148300@hg.openjdk.java.net> Changeset: d115330120f5 Author: Alexander Kouznetsov Date: 2013-03-21 14:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d115330120f5 Fixed RT-21110 [ColorPicker] it is possible for no any pill to be selected. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Thu Mar 21 16:04:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Mar 2013 23:04:23 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26377: Impl SubScene. Approved by Kevin, David Grieve Message-ID: <20130321230429.DA2F148301@hg.openjdk.java.net> Changeset: f8fdf3242d7c Author: Thor johannesson Date: 2013-03-21 15:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f8fdf3242d7c RT-26377: Impl SubScene. Approved by Kevin, David Grieve ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java + javafx-sg-common/src/com/sun/javafx/sg/PGSubScene.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSubScene.java ! javafx-ui-common/src/com/sun/javafx/scene/input/PickResultChooser.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SubScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Thu Mar 21 18:41:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 01:41:53 +0000 Subject: hg: openjfx/8/master/rt: 86 new changesets Message-ID: <20130322014626.43FA148307@hg.openjdk.java.net> Changeset: fe5a6223ed42 Author: rbair Date: 2013-03-12 09:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe5a6223ed42 RT-28932: TransformChangedEvent TRANSFORM_CHANGED event type has the wrong name Summary: The TransformChangedEvent reused the "ACTION" name, which results in an exception if both the TransformChangedEvent and ActionEvent are used in the same app. Unit test supplied with the fix. ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformChangedEventTest.java Changeset: b93620846ba4 Author: rbair Date: 2013-03-12 16:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b93620846ba4 Merge Changeset: 5fe0d1ba95aa Author: Martin Sladecek Date: 2013-03-13 10:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5fe0d1ba95aa RT-28718 Support permutation changes after add/remove changes in ObservableListBase ! javafx-beans/src/javafx/collections/ListChangeBuilder.java ! javafx-beans/test/javafx/collections/ListChangeBuilderTest.java ! javafx-beans/test/javafx/collections/MockListObserver.java Changeset: abe7e78f8bad Author: Martin Sladecek Date: 2013-03-13 10:24 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/abe7e78f8bad Dead code cleanup ! javafx-beans/src/javafx/collections/ListChangeBuilder.java Changeset: f9de458279a2 Author: dmasada Date: 2013-03-13 08:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f9de458279a2 RT-28764 Ensemble8: use ConditionalFeature to decide what demos to show ! apps/samples/Ensemble8/src/app/ensemble/SampleCategory.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java ! apps/samples/Ensemble8/src/app/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/ensemble/search/IndexSearcher.java + apps/samples/Ensemble8/src/app/ensemble/util/FeatureChecker.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/CodeGenerationUtils.java ! apps/samples/Ensemble8/src/compiletime/ensemble/compiletime/Sample.java ! apps/samples/Ensemble8/src/generated/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/charts/bar/audio/AudioBarChartApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/advancedmedia/AdvancedMediaApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/audioclip/AudioClipApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayerApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/scenegraph/events/multitouch/MultiTouchApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/htmleditor/HTMLEditorApp.java ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/webview/WebViewApp.java Changeset: e403dc5b195c Author: jgodinez Date: 2013-03-13 09:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e403dc5b195c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: d1dbad1c94b9 Author: rbair Date: 2013-03-13 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d1dbad1c94b9 Updated gradle build to work on linux ! build.gradle Changeset: d72a3b54194d Author: rbair Date: 2013-03-13 11:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d72a3b54194d [TEST-ONLY] Updated the test to use a local file instead of package.html because the new build system doesn't put javadoc files in the same places as class files, so this failed. ! javafx-ui-common/test/unit/com/sun/javafx/css/converters/URLConverterTest.java + javafx-ui-common/test/unit/com/sun/javafx/css/converters/some.txt Changeset: 4158528794cd Author: rbair Date: 2013-03-13 11:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4158528794cd RT-28886: Image URL_QUICKMATCH would be better as a cached Pattern Contributed By:neugens ! build.gradle ! javafx-ui-common/src/javafx/scene/image/Image.java Changeset: 61f4628db358 Author: Felipe Heidrich Date: 2013-03-13 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/61f4628db358 [Eclipse only] adding xtext nature to rt project ! .project Changeset: 1c16ab0343bf Author: Felipe Heidrich Date: 2013-03-13 13:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1c16ab0343bf minor: fix double semicolon in css file ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 4d82f948c42f Author: Daniel Blaukopf Date: 2013-03-13 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4d82f948c42f RT-28943 Use ConditionalFeatures instead of PlatformUtil.isEmbedded() ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 88de15f1c7d9 Author: Daniel Blaukopf Date: 2013-03-13 15:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/88de15f1c7d9 Fixed typo that broke the build ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java Changeset: 7a3db91a4561 Author: rbair Date: 2013-03-13 15:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a3db91a4561 RT-28968: javafx-beans not being tested Summary: Now testing javafx-beans again. There were 4 failing tests which were ignored pursuant to a fix for RT-28969 ! javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java Changeset: 3d3dd969e631 Author: Martin Sladecek Date: 2013-03-14 10:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3d3dd969e631 Fixed javafx collections tests + minor code fix that was found after tests were fixed. ! javafx-beans/src/com/sun/javafx/collections/VetoableListDecorator.java ! javafx-beans/src/javafx/collections/ListChangeListener.java ! javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java ! javafx-beans/test/javafx/collections/MockListObserver.java Changeset: 4d5247c56a5d Author: Petr Pchelko Date: 2013-03-14 16:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4d5247c56a5d RT-24453 Mac: ComboBox, ChoiceBox, ListView when selected cause NetBeans RCP Application menubar to disappear Reviewed-by: Anthony ! glass/glass-lib-macosx/src/GlassApplication.m ! glass/glass/src/com/sun/glass/ui/Application.java ! glass/glass/src/com/sun/glass/ui/mac/MacApplication.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassSystemMenu.java Changeset: de3ebe903c58 Author: Petr Pchelko Date: 2013-03-14 17:04 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/de3ebe903c58 RT-28542 cancelling DirectoryChooser selection leads to NPE Reviewed-by: Anthony ! glass/glass/src/com/sun/glass/ui/gtk/GtkCommonDialogs.java ! glass/glass/src/com/sun/glass/ui/win/WinCommonDialogs.java Changeset: c2e2112b523c Author: Eva Krejcirova Date: 2013-03-14 15:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c2e2112b523c RT-26547: Scenegraph doesn't handle null values passed for enum arguments (and other values) ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/DropShadow.java ! javafx-ui-common/src/javafx/scene/effect/InnerShadow.java ! javafx-ui-common/src/javafx/scene/effect/Light.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java ! javafx-ui-common/src/javafx/scene/effect/Shadow.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Arc.java ! javafx-ui-common/test/unit/javafx/scene/effect/ColorInputTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DisplacementMapTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DistantLightTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/DropShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/InnerShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/LightingTest.java ! javafx-ui-common/test/unit/javafx/scene/effect/ShadowTest.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageViewTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/FlowPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/HBoxTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/StackPaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/layout/VBoxTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ArcTest.java Changeset: 1a058c3aeb05 Author: Martin Sladecek Date: 2013-03-14 15:33 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1a058c3aeb05 RT-28961 BooleanExpression created by methods and(), or() are not cleaned ! javafx-beans/nbproject/project.xml ! javafx-beans/src/javafx/beans/binding/Bindings.java Changeset: c01cba0a1e6f Author: Martin Sladecek Date: 2013-03-14 15:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c01cba0a1e6f merge Changeset: eb2fd3306c9a Author: snorthov Date: 2013-03-14 16:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eb2fd3306c9a RT-28993: can't debug on mac inside IDE ! glass/glass-lib-macosx/src/GlassTimer.m Changeset: d0f2b546a80c Author: dmasada Date: 2013-03-15 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d0f2b546a80c RT-28991 Ensemble8: HTMLEditor needs to fit on screen better ! apps/samples/Ensemble8/src/samples/ensemble/samples/web/htmleditor/HTMLEditorApp.java Changeset: 69643789d32a Author: Radko Najman Date: 2013-03-18 10:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/69643789d32a RT-28735: Cover FXCollections methods with unit tests ! javafx-beans/src/javafx/collections/FXCollections.java ! javafx-beans/test/javafx/collections/FXCollectionsTest.java + javafx-beans/test/javafx/collections/ObservableListEmptyTest.java + javafx-beans/test/javafx/collections/ObservableListIteratorTest.java - javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableListTest.java - javafx-beans/test/javafx/collections/ObservableListTestBase.java - javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java - javafx-beans/test/javafx/collections/ObservableList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMapTest.java - javafx-beans/test/javafx/collections/ObservableMapTestBase.java - javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/ObservableSetTest.java - javafx-beans/test/javafx/collections/ObservableSetTestBase.java - javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIteratorTest.java - javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListTest.java - javafx-beans/test/javafx/collections/ObservableSubListTestBase.java - javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java ! javafx-beans/test/javafx/collections/TestedObservableLists.java + javafx-beans/test/javafx/collections/TestedObservableMaps.java + javafx-beans/test/javafx/collections/TestedObservableSets.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMapTest.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java Changeset: a3bfe0d84b14 Author: Richard Bair Date: 2013-03-19 00:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a3bfe0d84b14 Rebuilt the native build support for Gradle so that we don't use the makefiles at all anymore, and the native sub projects were removed and instead are just source directories in the graphics project. Everything was tested on Mac, Linux (32bit) and Windows (64 bit but 32 bit JVM). The code needs to be factored and made much better (lots of nasty details were discovered along the way), but at least things are mostly building. On Windows we need a better mechanism for identifying the build paths -- maybe we need to go back to the VSProperties generation routine, but I hope not. ! build.gradle ! generator.gradle ! settings.gradle Changeset: 2cbe9eff02b2 Author: Lubomir Nerad Date: 2013-03-19 10:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2cbe9eff02b2 Fix for RT-28853: Setting eventDispatcher to null causes NPE later (in event handling) ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java Changeset: fc1e38c49db7 Author: Martin Soch Date: 2013-03-19 10:58 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fc1e38c49db7 SW pipeline: update of input parametrs checks in Pisces renderer ! prism-sw-native/include/PiscesRenderer.h ! prism-sw-native/include/PiscesRenderer.inl ! prism-sw-native/include/PiscesUtil.h ! prism-sw-native/src/JPiscesRenderer.c ! prism-sw/src/com/sun/pisces/GradientColorMap.java ! prism-sw/src/com/sun/pisces/PiscesRenderer.java Changeset: 0d29aa4bde9c Author: Martin Soch Date: 2013-03-19 15:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0d29aa4bde9c SW pipeline: stroke shouldn't be applied when rendering glyph-list (RT-27211) ! prism-sw/src/com/sun/prism/sw/SWGraphics.java Changeset: bca7b8cc76b8 Author: jgodinez Date: 2013-03-19 10:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bca7b8cc76b8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java - javafx-beans/test/javafx/collections/ObservableListTestBase.java - javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java - javafx-beans/test/javafx/collections/ObservableList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableList_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMapTestBase.java - javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java - javafx-beans/test/javafx/collections/ObservableSetTestBase.java - javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java - javafx-beans/test/javafx/collections/ObservableSubListTestBase.java - javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java - javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java - javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java Changeset: 37f21ae48cbb Author: jgiles Date: 2013-03-12 13:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/37f21ae48cbb RT-28849: TableView has no way to clear the selection once one is made ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: d170f53e01db Author: jgiles Date: 2013-03-12 14:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d170f53e01db RT-28849: TableView has no way to clear the selection once one is made (Fix for TreeView) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 401883988dc0 Author: jgiles Date: 2013-03-13 11:23 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/401883988dc0 RT-28615: ListChangeListener on MultipleSelectionModel selectedItems does not always report correct item added. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java Changeset: 21ab95250f8f Author: jgiles Date: 2013-03-13 11:34 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/21ab95250f8f RT-28897: [TableView, TreeTableView] Column 'sortable' prop when disabled allows to sort column. ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java Changeset: e4029c52cf30 Author: jgiles Date: 2013-03-13 11:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e4029c52cf30 Enabling some ignored unit test classes. ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ChoiceBoxSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuBarSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuButtonSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ToolBarSkinTest.java Changeset: 5f1d2d1faa6d Author: jgiles Date: 2013-03-13 14:24 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5f1d2d1faa6d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 795697fbaa9e Author: David Grieve Date: 2013-03-13 15:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/795697fbaa9e RT-28945: not enough to reset to initial value on slowpath, must also reset on fastpath if css set the current value ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: 2ca6c5e94163 Author: jgiles Date: 2013-03-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2ca6c5e94163 Cleanup some controls unit tests. ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/KeyModifier.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/MenuBarSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: bd595da0dd6b Author: jgiles Date: 2013-03-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bd595da0dd6b Very early work on infrastructure for UI controls to better test mouse events (still incomplete) + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java Changeset: 86fbcdbb3e2e Author: jgiles Date: 2013-03-14 10:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/86fbcdbb3e2e Partial fix for RT-28684: [TreeTableView] When graphics is set to tree item the whole tree table row disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: adefcf226e92 Author: jgiles Date: 2013-03-14 10:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/adefcf226e92 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java Changeset: 5f51d88810cd Author: jgiles Date: 2013-03-14 14:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5f51d88810cd RT-23129: Memory Leak in (Context)Menu ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java Changeset: 4f803bb7ab77 Author: jgiles Date: 2013-03-14 14:27 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4f803bb7ab77 Further unit testing infrastructure explorations + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/ContextMenuEventFirer.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: 282078cff182 Author: jgiles Date: 2013-03-14 14:34 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/282078cff182 RT-23129: Memory Leak in (Context)Menu (Fix for NPE) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: ff5b5435295a Author: jgiles Date: 2013-03-14 16:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ff5b5435295a RT-23129: Memory Leak in (Context)Menu (Fix for silly code typo found by Scott Palmer, also other slight optimisations) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: e1871684b3ae Author: jgiles Date: 2013-03-14 18:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e1871684b3ae RT-28678: [TreeView] graphics is not rendered immediately. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/test/ControlAsserts.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 589dff8b15bb Author: "Jasper Potts" Date: 2013-03-14 09:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/589dff8b15bb Fixed RT-28983: Modena dosn't use LCD text on Windows ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: fe41f8a41c08 Author: jgiles Date: 2013-03-15 08:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe41f8a41c08 Reintroduce MouseEventGenerator into javafx-ui-controls. Eclipse tricked me into thinking it would compile but it doesn't when on the command line (clearly different classpaths are being used). + javafx-ui-controls/test/com/sun/javafx/scene/control/infrastructure/MouseEventGenerator.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java Changeset: 7462badb3a1a Author: jgiles Date: 2013-03-15 08:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7462badb3a1a Disabling problematic RT-28678 unit test temporarily. ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: c48ec880d661 Author: jgiles Date: 2013-03-15 08:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c48ec880d661 Fixing up two unit tests that Eclipse noted had errors. ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/javafx/scene/control/MenuItemTest.java Changeset: 30b551d64339 Author: jgiles Date: 2013-03-15 08:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/30b551d64339 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: c2c906a9444a Author: mickf Date: 2013-03-14 19:18 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c2c906a9444a RT-27699 : IndexOutOfBoundsException when dynamic setting TitledPane.setMnemonicParsing(false). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 0096a41dcf0f Author: Paru Somashekar Date: 2013-03-14 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0096a41dcf0f RT-21162 stall bar on same category data add ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 722fd37fc0ff Author: Paru Somashekar Date: 2013-03-14 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/722fd37fc0ff RT-19855 Menu setOnAction not fired. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 148a5ddb6d8d Author: leifs Date: 2013-03-15 16:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/148a5ddb6d8d RT-26147: Tooltip layout issue in RTL orientation. ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java Changeset: df35cfefa6bd Author: Alexander Kouznetsov Date: 2013-03-15 19:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/df35cfefa6bd Modena app: make use of opacity in base, background or accent color ! apps/experiments/Modena/src/modena/Modena.java Changeset: f9cdb400a0d5 Author: Alexander Kouznetsov Date: 2013-03-15 19:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f9cdb400a0d5 Modena skin: Copied pattern-transparent.png for Modena skin to fix NPE in CustomColorDialog with Modena + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png Changeset: 0c08ba3460a0 Author: jgiles Date: 2013-03-18 07:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0c08ba3460a0 RT-29016: CheckBoxTreeItem doesn't have unit tests (this changeset adds ~39 unit tests for CheckBoxTreeItem) ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java + javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java Changeset: 830567b6001f Author: jgiles Date: 2013-03-19 09:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/830567b6001f First batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java + javafx-ui-controls/test/javafx/scene/control/cell/ParameterisedPrebuiltCellTest.java Changeset: 3ff4d721bc61 Author: jgiles Date: 2013-03-19 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3ff4d721bc61 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 54ade0062868 Author: Alexander Kouznetsov Date: 2013-03-18 16:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/54ade0062868 CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: a6ad35da022e Author: Alexander Kouznetsov Date: 2013-03-18 16:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a6ad35da022e javafx-ui-controls-tests: get rid of <> diamond operators to stay with 1.7 source level ! javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: f80b0ddaad6b Author: Alexander Kouznetsov Date: 2013-03-18 16:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f80b0ddaad6b CustomColorDialog: Made things private to ensure proper encapsulation. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java Changeset: b6bcfa23f268 Author: Alexander Kouznetsov Date: 2013-03-18 17:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b6bcfa23f268 Backed out changeset f80b0ddaad6b ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java Changeset: dd2fe0f50947 Author: Alexander Kouznetsov Date: 2013-03-18 17:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dd2fe0f50947 Backed out changeset a6ad35da022e ! javafx-ui-controls/test/javafx/scene/control/CheckBoxTreeItemTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: aa130dbb8265 Author: Alexander Kouznetsov Date: 2013-03-18 17:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/aa130dbb8265 Backed out changeset 54ade0062868 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: d117e7743d33 Author: jgiles Date: 2013-03-19 13:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d117e7743d33 RT-28065: Focus is moved on last item when pressing CTRL+A ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 248f00a654a0 Author: jgiles Date: 2013-03-19 15:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/248f00a654a0 RT-29046: Sliders do not allow you to drag from track ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: f3d2aa1925e2 Author: jgiles Date: 2013-03-19 15:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f3d2aa1925e2 Updating source level of javafx-ui-controls netbeans project.xml from 1.6 to 1.7. ! javafx-ui-controls/nbproject/project.xml Changeset: 8a3ba759e08f Author: jgiles Date: 2013-03-19 15:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8a3ba759e08f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a8a615069941 Author: jgiles Date: 2013-03-19 16:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a8a615069941 Fix unit test failures for multiple selection models. ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 5d973fbafa77 Author: jgiles Date: 2013-03-19 16:28 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5d973fbafa77 Resolve class cast exception in CssStyleHelper where Nodes that were not Parents were being cast to Parent. Casting to Node now instead. ! javafx-ui-common/src/javafx/scene/CssStyleHelper.java Changeset: d077f9331707 Author: jgiles Date: 2013-03-19 20:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d077f9331707 Second batch of unit tests (and minor fixes) for RT-29045: Prebuilt cells in javafx.scene.control.cell are lacking unit tests ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxListCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTableCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! javafx-ui-controls/test/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: bc859a872a95 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bc859a872a95 RT-28997: have SimpleStyleableProperty extend StyleableProperty. Patch supplied by Danno Ferrin (danno.ferrin at shemnon.com), reviewed by David Grieve. ! .idea/compiler.xml ! .idea/libraries/jfxrt_binary_stub.xml ! .idea/modules.xml ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java Changeset: 222a76ee6a38 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/222a76ee6a38 RT-29031: @Ignore Node_effectiveOrientation_Css_Test ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: 1e478f14d2f2 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1e478f14d2f2 RT-29019: check for null or empty style-class before calling StyleClassSet.getStyleClass ! javafx-ui-common/src/com/sun/javafx/css/StyleClassSet.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: e7e4b09677e5 Author: David Grieve Date: 2013-03-19 12:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e7e4b09677e5 RT-28992: additional null checks in StyleManager#removeFromCacheMap ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: dec15223148f Author: Paru Somashekar Date: 2013-03-19 09:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dec15223148f RT-23457 MenuItems should not be selected when a mouse move and mouse up occurs. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 6a275aaf415f Author: Paru Somashekar Date: 2013-03-19 09:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6a275aaf415f RT-21138 BarChart - negative data item is added, animation starts from positive value ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 1b6eab7f1f72 Author: mo.chicharro Date: 2013-03-19 16:56 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1b6eab7f1f72 Fix for RT-28503 - Modena: TreeView disclosure arrow is wrong shape ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 0b251608ae45 Author: mo.chicharro Date: 2013-03-19 17:00 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0b251608ae45 Fix for RT-29069 - Modena: Text inside TreeTableView cells sits 1 pixel too high ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: e78a64bc1998 Author: David Grieve Date: 2013-03-19 13:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e78a64bc1998 revert unintentional changes to rt/.idea files ! .idea/compiler.xml ! .idea/libraries/jfxrt_binary_stub.xml ! .idea/modules.xml Changeset: c215a5924b33 Author: David Grieve Date: 2013-03-19 13:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c215a5924b33 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: ee86f25fc1b3 Author: mo.chicharro Date: 2013-03-19 17:59 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ee86f25fc1b3 Fixed typo in CSS ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 98b8f8052c8b Author: "Jasper Potts" Date: 2013-03-19 11:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/98b8f8052c8b Fixed: RT-29074: When child is more css dirty than parent that gets lost ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: c2ebe930f201 Author: Alexander Kouznetsov Date: 2013-03-19 13:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c2ebe930f201 CustomColorDialog: Fixed RT-29049 Custom color picker dialog title with ellipsis ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: 9cd4222cfa62 Author: Paru Somashekar Date: 2013-03-19 22:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9cd4222cfa62 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java - javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java - javafx-ui-controls/test/javafx/scene/control/KeyModifier.java - javafx-ui-controls/test/javafx/scene/control/MouseEventGenerator.java Changeset: 4a4088d5aaf4 Author: hudson Date: 2013-03-21 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4a4088d5aaf4 Added tag 8.0-b82 for changeset 9cd4222cfa62 ! .hgtags From hang.vo at oracle.com Thu Mar 21 21:19:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 04:19:07 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130322041925.E2E094830C@hg.openjdk.java.net> Changeset: 6fe5f8e3f6fa Author: jgiles Date: 2013-03-21 19:26 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6fe5f8e3f6fa Removing resources related to dialogs, which are not included in JavaFX 8.0. - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/confirm48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/dialog-resources.properties - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/error32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/error48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/info16.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/info48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/java32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/java48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/security_high.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/security_low.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning16.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning48.png Changeset: 9f5fdc3b510f Author: jgiles Date: 2013-03-22 17:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9f5fdc3b510f RT-29133: SortType enum is missing from TableColumn - javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java + javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparatorBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnSortTypeWrapper.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java ! javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java Changeset: 2cbf9d730def Author: jgiles Date: 2013-03-22 17:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2cbf9d730def Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/confirm48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/dialog-resources.properties - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/error32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/error48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/info16.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/info48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/java32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/java48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/security_high.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/security_low.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning16.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning48.png From hang.vo at oracle.com Fri Mar 22 06:04:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 13:04:37 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29127: subSceneComputeContains checks subScene's width and height Message-ID: <20130322130452.B566448339@hg.openjdk.java.net> Changeset: 5aaa2b02c980 Author: Pavel Safrata Date: 2013-03-22 13:52 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5aaa2b02c980 RT-29127: subSceneComputeContains checks subScene's width and height ! javafx-ui-common/src/javafx/scene/SubScene.java From hang.vo at oracle.com Fri Mar 22 07:04:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 14:04:16 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29109: picking handles subScenes correctly. Message-ID: <20130322140426.5B2674833C@hg.openjdk.java.net> Changeset: 926f12bce792 Author: Pavel Safrata Date: 2013-03-22 15:00 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/926f12bce792 RT-29109: picking handles subScenes correctly. ! javafx-ui-common/src/com/sun/javafx/scene/NodeAccess.java + javafx-ui-common/src/com/sun/javafx/scene/SubSceneAccess.java ! javafx-ui-common/src/com/sun/javafx/scene/input/PickResultChooser.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/src/javafx/scene/SubScene.java From chien.yang at oracle.com Fri Mar 22 07:59:53 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 22 Mar 2013 07:59:53 -0700 Subject: hg: openjfx/8/graphics/rt: RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 In-Reply-To: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> References: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> Message-ID: <514C71E9.7020405@oracle.com> Hi August, This went into the main line so it should be in the weekly build release. The restriction is to match the current mesh implementation but we plan to lift or loosen it the near future. In fact there is already a JIRA filed immediately the tightening of face smoothing group value is enforced. https://javafx-jira.kenai.com/browse/RT-29007 Thanks, - Chien On 3/12/2013 3:46 AM, August Lammersdorf, InteractiveMesh wrote: > - Which releases will be affected by this restriction? > > - What are the reasons? > > Thanks, August From hang.vo at oracle.com Fri Mar 22 08:18:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 15:18:49 +0000 Subject: hg: openjfx/8/graphics/rt: Minor cosmetic changes to subScene picking code. Message-ID: <20130322151855.6FEF84833E@hg.openjdk.java.net> Changeset: 2916403f98f3 Author: Pavel Safrata Date: 2013-03-22 16:02 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2916403f98f3 Minor cosmetic changes to subScene picking code. ! javafx-ui-common/src/javafx/scene/SubScene.java From hang.vo at oracle.com Fri Mar 22 08:34:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 15:34:08 +0000 Subject: hg: openjfx/8/graphics/rt: [DOC-ONLY]: SubScene.subSceneComputeContains documented. Message-ID: <20130322153411.79ADC4833F@hg.openjdk.java.net> Changeset: 8d6125cf264a Author: Pavel Safrata Date: 2013-03-22 16:24 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8d6125cf264a [DOC-ONLY]: SubScene.subSceneComputeContains documented. ! javafx-ui-common/src/javafx/scene/SubScene.java From hang.vo at oracle.com Fri Mar 22 11:18:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 18:18:45 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-24840 [ColorPicker] rgb mode tab, has problems with rendering. Message-ID: <20130322181854.63BD54834A@hg.openjdk.java.net> Changeset: 5369b4ba4ae2 Author: Alexander Kouznetsov Date: 2013-03-22 11:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5369b4ba4ae2 Fixed RT-24840 [ColorPicker] rgb mode tab, has problems with rendering. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hang.vo at oracle.com Fri Mar 22 11:49:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 18:49:10 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130322184919.611884834B@hg.openjdk.java.net> Changeset: 4a4088d5aaf4 Author: hudson Date: 2013-03-21 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4a4088d5aaf4 Added tag 8.0-b82 for changeset 9cd4222cfa62 ! .hgtags Changeset: 397294c2196f Author: David Grieve Date: 2013-03-22 14:23 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/397294c2196f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/confirm48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/dialog-resources.properties - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/error32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/error48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/info16.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/info48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/java32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/java48.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/security_high.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/security_low.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning16.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning32.png - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/warning48.png From hang.vo at oracle.com Fri Mar 22 12:04:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 19:04:29 +0000 Subject: hg: openjfx/8/graphics/rt: Various Gradle build improvements. Message-ID: <20130322190439.AFD274834C@hg.openjdk.java.net> Changeset: 2ceb66627308 Author: Richard Bair Date: 2013-03-22 12:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2ceb66627308 Various Gradle build improvements. - Improved documentation - Added "JAVA" property, analogous to JAVAC and JAVAH - Moved Mac / Windows specific native build properties into Mac / Windows specific gradle files - Factored CC / LINK properties so they can be overridden properly in platform specific gradle files - Removed Builder annotation processor from the class path and explicitly added it as a compile time flag for only certain projects - This fixed some issues such as java files in resources being compiled while on the class path (happened during testing) - Block DepthTest from being tested -- the code thought it was a JUnit test and tried to run it! - Update IntelliJ generation to include native directories and some generated sources (jsl) - Fixed dependency between controls & designTime (it was backwards) - Gave FXML stub toolkit for the sake of testing (read the comment) - added TODO for enabling -javafx flag for docs once we have b82 available. ! build.gradle ! generator.gradle ! linux.gradle ! mac.gradle ! win.gradle From richard.bair at oracle.com Fri Mar 22 13:03:15 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 22 Mar 2013 13:03:15 -0700 Subject: Gradle build progress In-Reply-To: <514AC9BF.2020907@redhat.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <514AC9BF.2020907@redhat.com> Message-ID: <8E11C6F2-07F4-4539-AE71-0DC628BA5762@oracle.com> > I can confirm I have the same problem that Peter has (btw, I tried with Gradle 1.3 and seem to work to the same extent that 1.4 does). I guess the real solution is to open another couple of bits of code ;) I know it would make this build work SO MUCH EASIER. I just downloaded JDK b82 and did an open build with no problems. I think maybe there were some interface changes between closed bits and it wouldn't build without the latest closed bits (just released this morning). Can you give it another try? I confirmed that after copying b82/jre/lib/ext/jfxrt.jar into ../artifacts/sdk/rt/lib/ext I could: gradle gradle :javadoc Sadly, the test are broken due to PGStubScene change sets, I am looking into that now (thankfully PGStubScene is in the open so this shouldn't be a "wait another week" kind of mess). >> I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file. >> >> Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss. > > I think this will be a major problem for everybody, indeed. > > I believe the sanest thing to do is not ship OpenJFX in the ext directory for OpenJDK, or it will make rebuilding from sources next to impossible in Linux distributions. Can you explain that a bit more? In the Gradle build I actually have taken care of it because during compilation (of everything including javadocs) I set -Djava.ext.libs= so that it clears JavaFX from the path. That seems to do the trick. The only question I had was about whether that would also handle the loading of native libs properly -- Kevin thinks so but I need to confirm. > I wish Oracle would follow this advice and remove this library from Java 8, people who really rely on the jar to be in part of the external libraries can put it back there any time (i.e. an installer can be provided that put it back there). Eeek, installers are evil :-). Anyway, FX will be staying on the class path by default AFAIK. Thanks!! Richard From hang.vo at oracle.com Fri Mar 22 13:04:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 20:04:53 +0000 Subject: hg: openjfx/8/graphics/rt: Now with b82 available, I have enabled the -javafx javadoc flag and also fixed a bug where I was not omitting the builder generator META-INF during generation of the javafx directory Message-ID: <20130322200501.2363A48352@hg.openjdk.java.net> Changeset: a01b555ebcc5 Author: rbair Date: 2013-03-22 12:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a01b555ebcc5 Now with b82 available, I have enabled the -javafx javadoc flag and also fixed a bug where I was not omitting the builder generator META-INF during generation of the javafx directory ! build.gradle ! generator.gradle From richard.bair at oracle.com Fri Mar 22 13:18:40 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 22 Mar 2013 13:18:40 -0700 Subject: Gradle build progress In-Reply-To: <8E11C6F2-07F4-4539-AE71-0DC628BA5762@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <514AC9BF.2020907@redhat.com> <8E11C6F2-07F4-4539-AE71-0DC628BA5762@oracle.com> Message-ID: <0AA597D4-E195-46AD-AA91-35E4C27B6F10@oracle.com> > Sadly, the test are broken due to PGStubScene change sets, I am looking into that now (thankfully PGStubScene is in the open so this shouldn't be a "wait another week" kind of mess). OK, I just pushed a fix for this that should show up in 20min or so. Now I'm getting a failure when compiling the tests for Controls, which is a crash in javac. I've filed this as JDK-8010659 and have spent the whole day so far trying to track this one down. I think this is the only thing preventing all the tests from running. Which means, we can build, test (almost), and produce javadoc. And I also added the IDEA project file generation. I was wondering if Tom or somebody using Eclipse would want to try their hand at the eclipse project file creation? I'm about to send an email to the NB guys as well. Hopefully we'll have IDE support ready to go here shortly as well. Richard From hang.vo at oracle.com Fri Mar 22 13:18:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 20:18:47 +0000 Subject: hg: openjfx/8/graphics/rt: Gradle build fix. The "stub" source set compilation depends on the results of the "main" source set compilation. Was just getting lucky before. Message-ID: <20130322201853.3A13148356@hg.openjdk.java.net> Changeset: 4b103a235ef5 Author: Richard Bair Date: 2013-03-22 13:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4b103a235ef5 Gradle build fix. The "stub" source set compilation depends on the results of the "main" source set compilation. Was just getting lucky before. ! build.gradle From richard.bair at oracle.com Fri Mar 22 13:49:17 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 22 Mar 2013 13:49:17 -0700 Subject: Gradle build progress In-Reply-To: <0AA597D4-E195-46AD-AA91-35E4C27B6F10@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <514AC9BF.2020907@redhat.com> <8E11C6F2-07F4-4539-AE71-0DC628BA5762@oracle.com> <0AA597D4-E195-46AD-AA91-35E4C27B6F10@oracle.com> Message-ID: BTW, I just used NetBeans 7.3 with its built-in support for Gradle and it worked really well. I was impressed. The only thing I had to do (which was lame) was go to Preferences, Gradle, and set the path to Gradle. I think NB is shipping with an older version of gradle and it needs to point to a 1.4 version. So I think IDEA and NB users are generally able to run with the new project structure, so if any Eclipse user wants to wade in we will then have support for all 3 ides. Yay! Richard On Mar 22, 2013, at 1:18 PM, Richard Bair wrote: >> Sadly, the test are broken due to PGStubScene change sets, I am looking into that now (thankfully PGStubScene is in the open so this shouldn't be a "wait another week" kind of mess). > > OK, I just pushed a fix for this that should show up in 20min or so. Now I'm getting a failure when compiling the tests for Controls, which is a crash in javac. I've filed this as JDK-8010659 and have spent the whole day so far trying to track this one down. I think this is the only thing preventing all the tests from running. > > Which means, we can build, test (almost), and produce javadoc. And I also added the IDEA project file generation. I was wondering if Tom or somebody using Eclipse would want to try their hand at the eclipse project file creation? I'm about to send an email to the NB guys as well. Hopefully we'll have IDE support ready to go here shortly as well. > > Richard From hang.vo at oracle.com Fri Mar 22 15:33:48 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 22:33:48 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130322223358.6EBCC4835E@hg.openjdk.java.net> Changeset: bf4afadf6891 Author: jgiles Date: 2013-03-23 11:20 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bf4afadf6891 RT-19065: TableViewKeyInputTest fails on Hudson with OOM on Windows platform. Improved memory management so that (ListView|TreeView|TableView|TreeTableView)KeyInputTests don't fail. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 51b682cfea96 Author: jgiles Date: 2013-03-23 11:20 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/51b682cfea96 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Fri Mar 22 16:18:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 23:18:44 +0000 Subject: hg: openjfx/8/controls/rt: Fix build failure due to missing StubToolkit. Message-ID: <20130322231850.8926F48360@hg.openjdk.java.net> Changeset: d1301cbce91e Author: jgiles Date: 2013-03-23 12:09 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d1301cbce91e Fix build failure due to missing StubToolkit. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java From hang.vo at oracle.com Fri Mar 22 16:18:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Mar 2013 23:18:55 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130322231904.D514C48361@hg.openjdk.java.net> Changeset: c303428dc4ed Author: rbair Date: 2013-03-22 16:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c303428dc4ed Fixed two bugs related to windows builds. The first is that the property names needed to be WINDOWS_VS_* instead of windows.vs.*. Also newlines were missing (thanks Artem!) ! win.gradle Changeset: af7846abbd28 Author: Richard Bair Date: 2013-03-22 16:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/af7846abbd28 Add ability to supplement the gradle build with additional build instructions (for example, for producing official JavaFX builds) ! build.gradle From hang.vo at oracle.com Sat Mar 23 09:49:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 23 Mar 2013 16:49:26 +0000 Subject: hg: openjfx/8/graphics/rt: Moved IDEA project generation to the bottom of the gradle build file and grouped it together instead of having IDEA generation spread throughout the file. Eclipse & NB generation should happen in the same way. Message-ID: <20130323164937.9729B48378@hg.openjdk.java.net> Changeset: 68f2c14e65f8 Author: Richard Bair Date: 2013-03-23 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/68f2c14e65f8 Moved IDEA project generation to the bottom of the gradle build file and grouped it together instead of having IDEA generation spread throughout the file. Eclipse & NB generation should happen in the same way. ! build.gradle From hang.vo at oracle.com Sat Mar 23 14:19:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 23 Mar 2013 21:19:42 +0000 Subject: hg: openjfx/8/graphics/rt: Updated grouping and description for some tasks that were missing them. Also added the beginnings of support for custom NB project-specific file generation (in general it isn't needed, but just trying to sweeten it up). Message-ID: <20130323211949.1520E4837F@hg.openjdk.java.net> Changeset: 0937881f3f3e Author: Richard Bair Date: 2013-03-23 14:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0937881f3f3e Updated grouping and description for some tasks that were missing them. Also added the beginnings of support for custom NB project-specific file generation (in general it isn't needed, but just trying to sweeten it up). ! build.gradle From richard.bair at oracle.com Sat Mar 23 18:48:53 2013 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 23 Mar 2013 18:48:53 -0700 Subject: Gradle build documentation Message-ID: <57FC4C49-981F-4602-9AAD-788D59E0F204@oracle.com> I've added a whole pile of documentation around building with Gradle to the (still beta) wiki: https://wiki-beta.openjdk.java.net/display/OpenJFX/Building+OpenJFX I've also added some instructions for how to setup a native build environment. I am sure there are gaps in this native build documentation, so any improvements to the doc would be much appreciated. I wrote a chunk at the bottom of the document detailing the issue about the jre/lib/ext/jfxrt.jar file. Note that I'm changing the gradle build script (changed actually, I'm just testing it out) so that you DON'T have to remove the jfxrt.jar file from the SDK and that you DON'T have to have any jar in artifacts/sdk/rt/lib/ext and you DON'T have to specify the binary stub. Hopefully that makes it less cumbersome to build. Richard From hang.vo at oracle.com Sat Mar 23 19:19:32 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 24 Mar 2013 02:19:32 +0000 Subject: hg: openjfx/8/graphics/rt: Changed BINARY_STUB so that by default it will use the jfxrt.jar shipped in the JDK Message-ID: <20130324021938.2EB0048385@hg.openjdk.java.net> Changeset: 8a63bd3d46a3 Author: Richard Bair Date: 2013-03-23 19:16 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8a63bd3d46a3 Changed BINARY_STUB so that by default it will use the jfxrt.jar shipped in the JDK ! build.gradle From rdarrylr at yahoo.com Sat Mar 23 20:59:12 2013 From: rdarrylr at yahoo.com (Darryl R) Date: Sat, 23 Mar 2013 20:59:12 -0700 (PDT) Subject: Gradle build documentation In-Reply-To: <57FC4C49-981F-4602-9AAD-788D59E0F204@oracle.com> References: <57FC4C49-981F-4602-9AAD-788D59E0F204@oracle.com> Message-ID: <1364097552.58653.YahooMailNeo@web122502.mail.ne1.yahoo.com> Thank you very much for that page. I finally am able to build it all on Windows now. I was able to build on Ubuntu very easily last week but i've been really struggling with the Windows build. I just did a clone of master and rt tonight and am using the 1.80 b82 build. I don't see the gradle IDE. I was trying to find if those were not pushed out to everyone yet but didn't find a post about it One thing I'm also confused about is how we make use of the 4 DLLs in?build/sdk/rt/bin/ off of javafx if we want to use the compiled javafxrt.jar Thanks -Darryl ________________________________ From: Richard Bair To: "openjfx-dev at openjdk.java.net Mailing" Sent: Saturday, March 23, 2013 9:48:53 PM Subject: Gradle build documentation I've added a whole pile of documentation around building with Gradle to the (still beta) wiki: https://wiki-beta.openjdk.java.net/display/OpenJFX/Building+OpenJFX I've also added some instructions for how to setup a native build environment. I am sure there are gaps in this native build documentation, so any improvements to the doc would be much appreciated. I wrote a chunk at the bottom of the document detailing the issue about the jre/lib/ext/jfxrt.jar file. Note that I'm changing the gradle build script (changed actually, I'm just testing it out) so that you DON'T have to remove the jfxrt.jar file from the SDK and that you DON'T have to have any jar in artifacts/sdk/rt/lib/ext and you DON'T have to specify the binary stub. Hopefully that makes it less cumbersome to build. Richard From richard.bair at oracle.com Sat Mar 23 22:52:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 23 Mar 2013 22:52:42 -0700 Subject: Gradle build progress In-Reply-To: <514AC9BF.2020907@redhat.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <514AC9BF.2020907@redhat.com> Message-ID: <57D04DB8-7CF7-4381-9A69-83A3EB689545@oracle.com> > I can confirm I have the same problem that Peter has (btw, I tried with Gradle 1.3 and seem to work to the same extent that 1.4 does). I guess the real solution is to open another couple of bits of code ;) I may have found the root cause here (or at least, a root cause). The basic problem is that on Windows the JRE is installed twice -- once in jre8 and once in jdk1.8.0/jre. Which one the developer might have on their path is anyone's guess (but if their system is like mine, it will be jre8). The other platforms don't do this -- at least, definitely not on Mac and I have yet to see this on Linux. The result is that the logic that tried to guess the JDK directory location didn't work on windows. I'm not sure this new logic is really going to work either in the long term, but it works for today. If there is a more bulletproof solution that doesn't require every developer to manually specify JDK_HOME or JAVA_HOME, then I'd like to know it! Here it is, in all its grizzly glory: // Get the JDK_HOME automatically based on the version of Java used to execute gradle. Or, if specified, // use a user supplied JDK_HOME, BINARY_STUB, JAVAC, and/or JAVAH, all of which may be specified // independently (or we'll try to get the right one based on other supplied info). There is a really // odd situation on windows where you can have two JRE's on the same system(!!!): // c:\Program Files (x86)\Java\jdk1.8.0\jre // c:\Program Files (x86)\Java\jre8\ // Because of this, you may sometimes get the jdk's JRE (in which case the logic we used to have here // was correct and consistent with all other platforms), or it might be the standalone JRE (for the love!). // So what we have to do is add some special windows-only logic here to figure out the JDK based on the // wrong JRE, if we happen to have gotten the wrong JRE. ext.JAVA_HOME = System.getProperty("java.home"); def javaHomeFile = file(JAVA_HOME); defineProperty("JDK_HOME", javaHomeFile.name == "jre" ? javaHomeFile.getParent().toString() : javaHomeFile.name.startsWith("jre") ? new File(javaHomeFile.getParent(), "jdk1.${javaHomeFile.name.substring(3)}.0").toString() : JAVA_HOME); // we have to bail and set it to something and this is as good as any! In order to debug your system, run something simple like: gradle projects --info See what is reported for the JAVA_HOME and JDK_HOME and BINARY_STUB. If JDK_HOME isn't pointing to the actual JDK directory (and you haven't manually specified the BINARY_STUB) you will have problems. If the BINARY_STUB isn't pointing to the jfxrt.jar of the latest JDK directory, then you'll have problems (unless you copied that file somewhere else and are pointing at it instead). Richard From richard.bair at oracle.com Sat Mar 23 22:58:00 2013 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 23 Mar 2013 22:58:00 -0700 Subject: Gradle build documentation In-Reply-To: <1364097552.58653.YahooMailNeo@web122502.mail.ne1.yahoo.com> References: <57FC4C49-981F-4602-9AAD-788D59E0F204@oracle.com> <1364097552.58653.YahooMailNeo@web122502.mail.ne1.yahoo.com> Message-ID: On Mar 23, 2013, at 8:59 PM, Darryl R wrote: > Thank you very much for that page. I finally am able to build it all on Windows now. I was able to build on Ubuntu very easily last week but i've been really struggling with the Windows build. Thanks! > I just did a clone of master and rt tonight and am using the 1.80 b82 build. The latest I've been doing has been in the graphics forest instead of master, so some of it may not be visible. As of today, the latest graphics forest will build against b82. > I don't see the gradle IDE. I was trying to find if those were not pushed out to everyone yet but didn't find a post about it Probably it is in graphics and not yet in master. > One thing I'm also confused about is how we make use of the 4 DLLs in build/sdk/rt/bin/ off of javafx if we want to use the compiled javafxrt.jar In theory[1] they should automatically get picked up. What happens is that when Glass or Prism (or whatnot) needs to load a native library, it ends up calling into com.sun.glass.utils.NativeLibLoader (which is open source). The NativeLibLoader will look in the right place relative to where jfxrt.jar is expected to live. [1] I'm not 100% sure it will always work right. For example, if open code tries to load a native lib, will it pick the locally built one, or the one that is included in the JDK? If code in the binary stub (i.e. the jfxrt.jar in the JDK) asks to load a native lib, will it look locally as well or only within the JDK? Is there any closed code that tries to load a native library that is open? These are questions I haven't played with yet to find answers to). From hang.vo at oracle.com Sat Mar 23 23:04:48 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 24 Mar 2013 06:04:48 +0000 Subject: hg: openjfx/8/graphics/rt: Gradle "fix". Message-ID: <20130324060454.0522148388@hg.openjdk.java.net> Changeset: f43272fc4b86 Author: Richard Bair Date: 2013-03-23 22:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f43272fc4b86 Gradle "fix". The basic problem is that on Windows the JRE is installed twice -- once in jre8 and once in jdk1.8.0/jre. Which one the developer might have on their path is anyone's guess (but if their system is like mine, it will be jre8). The other platforms don't do this -- at least, definitely not on Mac and I have yet to see this on Linux. The result is that the logic that tried to guess the JDK directory location didn't work on windows. I'm not sure this new logic is really going to work either in the long term, but it works for today. ! build.gradle From neugens.limasoftware at gmail.com Sun Mar 24 10:30:33 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 24 Mar 2013 18:30:33 +0100 Subject: Gradle build progress In-Reply-To: <8E11C6F2-07F4-4539-AE71-0DC628BA5762@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <514AC9BF.2020907@redhat.com> <8E11C6F2-07F4-4539-AE71-0DC628BA5762@oracle.com> Message-ID: Il giorno 22/mar/2013, alle ore 21:03, Richard Bair ha scritto: > > Can you explain that a bit more? Sure. The issue with Linux builds is that Linux distributions need to be able to build from source even and in an automated way, without disrupting the installed system. Requiring a library to be manually removed from the installed jdk (or even requiring a separate jdk) to build a package that would be distributed in the same distribution would not be allowed for me (hardly allowed on any Linux Distribution). > In the Gradle build I actually have taken care of it because during compilation (of everything including javadocs) I set -Djava.ext.libs= so that it clears JavaFX from the path. That seems to do the trick. The only question I had was about whether that would also handle the loading of native libs properly -- Kevin thinks so but I need to confirm. This is actually a good news! If we can confirm this, then there's no real issue anymore! >> I wish Oracle would follow this advice and remove this library from Java 8, people who really rely on the jar to be in part of the external libraries can put it back there any time (i.e. an installer can be provided that put it back there). > > Eeek, installers are evil :-). Anyway, FX will be staying on the class path by default AFAIK. Eh, yes, indeed :) Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From sdn at interactivemesh.com Sun Mar 24 11:23:21 2013 From: sdn at interactivemesh.com (August Lammersdorf, InteractiveMesh) Date: Sun, 24 Mar 2013 19:23:21 +0100 Subject: hg: openjfx/8/graphics/rt: RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 In-Reply-To: <514C71E9.7020405@oracle.com> References: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> <514C71E9.7020405@oracle.com> Message-ID: <930f64e92369694a9e9f3a863646bff2-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNklbS1kLWkF3AVNLX19cLkQBWV5YRFFRWAk=-webmailer2@server03.webmailer.hosteurope.de> Hi Chien, thanks for this hint. I try to keep my importer implementation flexible, so that I can adapt future changes 'easily'. The first release of the OBJ and STL importers are now available and can be downloaded here : http://www.interactivemesh.org/models/jfx3dimporter.html . August Am Freitag, den 22.03.2013, 07:59 +0100 schrieb Chien Yang : > Hi August, > > This went into the main line so it should be in the weekly build > release. The restriction is to match the current mesh implementation > but we plan to lift or loosen it the near future. In fact there is > already a JIRA filed immediately the tightening of face smoothing > group value is enforced. > > https://javafx-jira.kenai.com/browse/RT-29007 > > Thanks, > - Chien > > On 3/12/2013 3:46 AM, August Lammersdorf, InteractiveMesh wrote: >> - Which releases will be affected by this restriction? >> >> - What are the reasons? >> >> Thanks, August From phidias51 at gmail.com Sun Mar 24 16:13:15 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Sun, 24 Mar 2013 16:13:15 -0700 Subject: Gradle build progress In-Reply-To: <57D04DB8-7CF7-4381-9A69-83A3EB689545@oracle.com> References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> <514AC9BF.2020907@redhat.com> <57D04DB8-7CF7-4381-9A69-83A3EB689545@oracle.com> Message-ID: Just out of curiosity, does anyone know if there's a registry entry on Windows that corresponds to the JAVA_HOME variable? Also, when you use the control panel to determine what the default version of java is, there must be some preference/registry entry being set. I don't have a Windows box to try this on, but perhaps someone who does could take a look. Mark On Mar 23, 2013 10:53 PM, "Richard Bair" wrote: > > I can confirm I have the same problem that Peter has (btw, I tried with > Gradle 1.3 and seem to work to the same extent that 1.4 does). I guess the > real solution is to open another couple of bits of code ;) > > I may have found the root cause here (or at least, a root cause). The > basic problem is that on Windows the JRE is installed twice -- once in jre8 > and once in jdk1.8.0/jre. Which one the developer might have on their path > is anyone's guess (but if their system is like mine, it will be jre8). The > other platforms don't do this -- at least, definitely not on Mac and I have > yet to see this on Linux. The result is that the logic that tried to guess > the JDK directory location didn't work on windows. I'm not sure this new > logic is really going to work either in the long term, but it works for > today. If there is a more bulletproof solution that doesn't require every > developer to manually specify JDK_HOME or JAVA_HOME, then I'd like to know > it! > > Here it is, in all its grizzly glory: > > // Get the JDK_HOME automatically based on the version of Java used to > execute gradle. Or, if specified, > // use a user supplied JDK_HOME, BINARY_STUB, JAVAC, and/or JAVAH, all of > which may be specified > // independently (or we'll try to get the right one based on other > supplied info). There is a really > // odd situation on windows where you can have two JRE's on the same > system(!!!): > // c:\Program Files (x86)\Java\jdk1.8.0\jre > // c:\Program Files (x86)\Java\jre8\ > // Because of this, you may sometimes get the jdk's JRE (in which case the > logic we used to have here > // was correct and consistent with all other platforms), or it might be > the standalone JRE (for the love!). > // So what we have to do is add some special windows-only logic here to > figure out the JDK based on the > // wrong JRE, if we happen to have gotten the wrong JRE. > ext.JAVA_HOME = System.getProperty("java.home"); > def javaHomeFile = file(JAVA_HOME); > defineProperty("JDK_HOME", > javaHomeFile.name == "jre" ? > javaHomeFile.getParent().toString() : > javaHomeFile.name.startsWith("jre") ? > new File(javaHomeFile.getParent(), > "jdk1.${javaHomeFile.name.substring(3)}.0").toString() : > JAVA_HOME); // we have to bail and set it to something and this is > as good as any! > > > > > > > In order to debug your system, run something simple like: > > gradle projects --info > > See what is reported for the JAVA_HOME and JDK_HOME and BINARY_STUB. If > JDK_HOME isn't pointing to the actual JDK directory (and you haven't > manually specified the BINARY_STUB) you will have problems. If the > BINARY_STUB isn't pointing to the jfxrt.jar of the latest JDK directory, > then you'll have problems (unless you copied that file somewhere else and > are pointing at it instead). > > Richard From tbee at tbee.org Sun Mar 24 23:03:24 2013 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 25 Mar 2013 07:03:24 +0100 Subject: SkinBehaviour and JavaFX 8? In-Reply-To: <510B8818.8030409@oracle.com> References: <23D5144B-7038-4EB6-BC29-E3D6AA43A7AF@ultramixer.com> <510B8818.8030409@oracle.com> Message-ID: <514FE8AC.7000005@tbee.org> Yesterday I've ported JFXtras to J(FX)8 and basically are two issues remaining: 1. Where do I go with the code that is in the @Override layoutChildren method in skin classes? Currently there are two types of skin classes in JFXtras; one which uses properties plus binding and one that overrides layoutChilderen. The first approach is actually not really encouraged in JavaFX because it may be slower (may take more than one cycle to render), but they turn out to be very easy to migrate. The other approach (override) does not compile anymore. Since I chose to develop propety based, I'm not sure how to best fix the other controls. Should I override the control's layoutChildren en forward it to the skin's? 2. Behavior classes 99% of the behavior classes are empty but I have one control that actually has some sensible code in it. Since the email below is a bit older already; are there any insights where to go with this code? Or can I clean out the behavior classes all together and simply move it into the skin class? Regards, Tom On 2013-02-01 10:17, Jonathan Giles wrote: > Tobi, > > To start with I need to be clear that in JavaFX 2.x SkinBase and BehaviorBase were private APIs (that is, they both resided in com.sun.* packages). This means that they shouldn't have been used by third parties. Instead, third parties should have been building from the Skin interface. Of course, most people used SkinBase, and whenever I went to conferences I would promise people that the day of reckoning would come when I broke them. Well, that day is fast approaching.... :-) > > JavaFX 8.0 brings SkinBase to public API, but we are not prepared to bring BehaviorBase along with it just yet. This is because the concept of a behavior needs to be fleshed out further in a number of directions, including: > > * Making behaviors less opaque (i.e. more easily accessible to developers via the control - in other words bringing the concepts of actions and input/action maps to JavaFX), > * Improving toolability of behaviors / actions (so tools such as Scene Builder can know that a TextField offers cut/copy/paste, for example), > * Making it possible for developers to override and provide custom input mappings / actions more easily. > > It's late here and I'm sure there were other reasons for wanting more bake time on behaviors, but this was the general gist of things. > > What this means is that SkinBase in JavaFX 8.0 has no notion whatsoever of a behavior for specifying key/mouse input event handling. In other words, your code will need to manually handle keyboard and mouse interactions. In the future I am sure we will get to this point, but we are not there yet. > > Finally, don't look at how we in the UI controls team do it. I wouldn't want you to see the (very private!!!) BehaviorSkinBase class that is essentially a drop-in replacement for the old SkinBase class. Of course, if you did see this I'm sure you wouldn't use it as it is private API that I (once again) promise to change in the future when we resolve the behavior discussion. > > -- Jonathan > > On 1/02/2013 9:38 p.m., Tobias Bley wrote: >> Hi, >> >> there seams to be some changes from JavaFX 2 to JavaFX8 concerning SkinBase and SkinBehavior. In JFX2 you could call the constructor from SkinBase with a component (e.g. slider) and a skin behavior. In JFX8 it's not possible any more, I could only call the constructor of SkinBase with the control, not with the SkinBehavior. >> >> So my question is: How do I have to specify the SkinBehavior in JavaFX8? >> >> Best regards, >> Tobi >> > From jonathan.giles at oracle.com Sun Mar 24 23:18:03 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 25 Mar 2013 19:18:03 +1300 Subject: SkinBehaviour and JavaFX 8? In-Reply-To: <514FE8AC.7000005@tbee.org> References: <23D5144B-7038-4EB6-BC29-E3D6AA43A7AF@ultramixer.com> <510B8818.8030409@oracle.com> <514FE8AC.7000005@tbee.org> Message-ID: I'm on my phone so I'll keep this brief. 1) Replace with layoutChildren(x,y,w,h) in the skin class. 2) Behavior continues to be private API in JavaFX 8. I note that there have been some suggestions in the JFXtras mailing list and in my email below. Those continue to be the best options, along with folding Behavior back into your skin class. -- Jonathan Sent from a touch device. Please excuse my brevity. Tom Eugelink wrote: > >Yesterday I've ported JFXtras to J(FX)8 and basically are two issues >remaining: > >1. Where do I go with the code that is in the @Override layoutChildren >method in skin classes? >Currently there are two types of skin classes in JFXtras; one which >uses properties plus binding and one that overrides layoutChilderen. >The first approach is actually not really encouraged in JavaFX because >it may be slower (may take more than one cycle to render), but they >turn out to be very easy to migrate. The other approach (override) does >not compile anymore. Since I chose to develop propety based, I'm not >sure how to best fix the other controls. Should I override the >control's layoutChildren en forward it to the skin's? > >2. Behavior classes >99% of the behavior classes are empty but I have one control that >actually has some sensible code in it. Since the email below is a bit >older already; are there any insights where to go with this code? Or >can I clean out the behavior classes all together and simply move it >into the skin class? > >Regards, > >Tom > > > >On 2013-02-01 10:17, Jonathan Giles wrote: >> Tobi, >> >> To start with I need to be clear that in JavaFX 2.x SkinBase and >BehaviorBase were private APIs (that is, they both resided in com.sun.* >packages). This means that they shouldn't have been used by third >parties. Instead, third parties should have been building from the Skin >interface. Of course, most people used SkinBase, and whenever I went to >conferences I would promise people that the day of reckoning would come >when I broke them. Well, that day is fast approaching.... :-) >> >> JavaFX 8.0 brings SkinBase to public API, but we are not prepared to >bring BehaviorBase along with it just yet. This is because the concept >of a behavior needs to be fleshed out further in a number of >directions, including: >> >> * Making behaviors less opaque (i.e. more easily accessible to >developers via the control - in other words bringing the concepts of >actions and input/action maps to JavaFX), >> * Improving toolability of behaviors / actions (so tools such as >Scene Builder can know that a TextField offers cut/copy/paste, for >example), >> * Making it possible for developers to override and provide custom >input mappings / actions more easily. >> >> It's late here and I'm sure there were other reasons for wanting more >bake time on behaviors, but this was the general gist of things. >> >> What this means is that SkinBase in JavaFX 8.0 has no notion >whatsoever of a behavior for specifying key/mouse input event handling. >In other words, your code will need to manually handle keyboard and >mouse interactions. In the future I am sure we will get to this point, >but we are not there yet. >> >> Finally, don't look at how we in the UI controls team do it. I >wouldn't want you to see the (very private!!!) BehaviorSkinBase class >that is essentially a drop-in replacement for the old SkinBase class. >Of course, if you did see this I'm sure you wouldn't use it as it is >private API that I (once again) promise to change in the future when we >resolve the behavior discussion. >> >> -- Jonathan >> >> On 1/02/2013 9:38 p.m., Tobias Bley wrote: >>> Hi, >>> >>> there seams to be some changes from JavaFX 2 to JavaFX8 concerning >SkinBase and SkinBehavior. In JFX2 you could call the constructor from >SkinBase with a component (e.g. slider) and a skin behavior. In JFX8 >it's not possible any more, I could only call the constructor of >SkinBase with the control, not with the SkinBehavior. >>> >>> So my question is: How do I have to specify the SkinBehavior in >JavaFX8? >>> >>> Best regards, >>> Tobi >>> >> From hang.vo at oracle.com Mon Mar 25 00:33:32 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Mar 2013 07:33:32 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29097 Mac: Crash on moving mouse cursor with touchpad over window without scene Message-ID: <20130325073340.8F8DF4839E@hg.openjdk.java.net> Changeset: b7db1df9a5e1 Author: Petr Pchelko Date: 2013-03-25 11:33 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b7db1df9a5e1 RT-29097 Mac: Crash on moving mouse cursor with touchpad over window without scene Reviewed-by: Anthony ! glass/glass-lib-macosx/src/GlassGestureSupport.m ! glass/glass-lib-macosx/src/GlassStatics.h ! glass/glass-lib-macosx/src/GlassStatics.m ! glass/glass-lib-macosx/src/GlassTouches.m ! glass/glass-lib-macosx/src/GlassViewDelegate.m From hang.vo at oracle.com Mon Mar 25 01:18:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Mar 2013 08:18:45 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29108: SubScene's default fill changed to null. Message-ID: <20130325081848.B95E94839F@hg.openjdk.java.net> Changeset: 2b2365f95b76 Author: Pavel Safrata Date: 2013-03-25 09:02 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2b2365f95b76 RT-29108: SubScene's default fill changed to null. ! javafx-ui-common/src/javafx/scene/SubScene.java From hang.vo at oracle.com Mon Mar 25 06:48:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Mar 2013 13:48:10 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-28775: PopupWindow with content with Shadow Effect, wrong position Message-ID: <20130325134818.6D26D483A8@hg.openjdk.java.net> Changeset: aaf819fd09f9 Author: Lubomir Nerad Date: 2013-03-25 14:36 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/aaf819fd09f9 Fix for RT-28775: PopupWindow with content with Shadow Effect, wrong position ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java ! javafx-ui-common/test/unit/javafx/stage/WindowTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java From phidias51 at gmail.com Mon Mar 25 07:44:31 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 25 Mar 2013 07:44:31 -0700 Subject: Packaging Application Metadata Message-ID: I've been wondering if there were any plans to standardize packaging metadata? It strikes me that we should be able to specify dock and desktop icons, splashscreens, application names, OS-specific packaging properties (like the ones used in Mac OS X) and dependencies in a single place that can be used by both an application packaging tool, and on application startup. The JNLP file has most of these elements already and could serve as a useful starting point. Any thoughts? Mark From zonski at gmail.com Mon Mar 25 08:06:52 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 25 Mar 2013 10:06:52 -0500 Subject: Packaging Application Metadata In-Reply-To: References: Message-ID: I'd recommend creating a JIRA for this as the deployment guys are (hopefully) working on improvements in this area. They may have inclinations in this direction but I'd be surprised if there was anything solid in the pipeline or on the horizon. There's a 'deployment' category or something like that where it should end up with the right people. I looked at JNLP as a basis for this sort of stuff but it has a lot of legacy that complicates areas that don't need it (e.g. native packaging). I'd suggest (and have suggested in some long emails in the past) an application profile of some kind that can be used as the main deployment descriptor for Java apps regardless of how it gets deployed and may also form the base of Auto Updating. Having said that, I'd personally leave JNLP and Applet completely alone and only look at the newer deployment options for this sort of stuff. They are likely to be unusable options before too long as browsers stop plugins and OS's lock into app stores. The horrid legacy of JNLP and Applet hinder all the new options (app stores, native installers, mobile, etc) from evolving quickly. Some people will likely object to that though, just my opinion. Also be aware there are complications with things like icon formats (need to convert between .ico and .png, etc), image sizes, allowed characters and lengths in names (e.g. wix supports different things to mac, etc), licencing information needed for different platforms (e.g. app stores), etc, etc. So standardising will be quite a complicated process that would likely take a fair bit of time to nail down if work was started on it. As usual don't pin your hopes on any good solution arriving soon (Java8 would be extremely optimistic I imagine). On Mon, Mar 25, 2013 at 9:44 AM, Mark Fortner wrote: > I've been wondering if there were any plans to standardize packaging > metadata? It strikes me that we should be able to specify dock and desktop > icons, splashscreens, application names, OS-specific packaging properties > (like the ones used in Mac OS X) and dependencies in a single place that > can be used by both an application packaging tool, and on application > startup. The JNLP file has most of these elements already and could serve > as a useful starting point. > > Any thoughts? > > Mark > From chien.yang at oracle.com Mon Mar 25 08:12:05 2013 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 25 Mar 2013 08:12:05 -0700 Subject: hg: openjfx/8/graphics/rt: RT-28746 Need to tighten the specification to restrict the value for face smooth group from 0 to 31 In-Reply-To: <930f64e92369694a9e9f3a863646bff2-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNklbS1kLWkF3AVNLX19cLkQBWV5YRFFRWAk=-webmailer2@server03.webmailer.hosteurope.de> References: <6ea7254a292a143fa11e560cff452ce5-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNkdfS1wWWldoAF1RMl5cR0YCV19YR18=-webmailer2@server05.webmailer.hosteurope.de> <514C71E9.7020405@oracle.com> <930f64e92369694a9e9f3a863646bff2-EhVcX1lFTABZRwAdGwEGZ1dfaANWUkNeXENbA19cNklbS1kLWkF3AVNLX19cLkQBWV5YRFFRWAk=-webmailer2@server03.webmailer.hosteurope.de> Message-ID: <51506945.5000205@oracle.com> This is very neat! :-) Thanks, - Chien On 3/24/2013 11:23 AM, August Lammersdorf, InteractiveMesh wrote: > Hi Chien, thanks for this hint. > > I try to keep my importer implementation flexible, so that I can adapt > future changes 'easily'. > > The first release of the OBJ and STL importers are now available and > can be downloaded here : > http://www.interactivemesh.org/models/jfx3dimporter.html . > > August > > Am Freitag, den 22.03.2013, 07:59 +0100 schrieb Chien Yang > : >> Hi August, >> >> This went into the main line so it should be in the weekly build >> release. The restriction is to match the current mesh implementation >> but we plan to lift or loosen it the near future. In fact there is >> already a JIRA filed immediately the tightening of face smoothing >> group value is enforced. >> >> https://javafx-jira.kenai.com/browse/RT-29007 >> >> Thanks, >> - Chien >> >> On 3/12/2013 3:46 AM, August Lammersdorf, InteractiveMesh wrote: >>> - Which releases will be affected by this restriction? >>> >>> - What are the reasons? >>> >>> Thanks, August > From richard.bair at oracle.com Mon Mar 25 09:01:27 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 25 Mar 2013 09:01:27 -0700 Subject: Packaging Application Metadata In-Reply-To: References: Message-ID: <7B808DA5-EFCF-4B40-AC5C-41C8919CAE55@oracle.com> > I'd recommend creating a JIRA for this as the deployment guys are > (hopefully) working on improvements in this area. They may have > inclinations in this direction but I'd be surprised if there was anything > solid in the pipeline or on the horizon. There's a 'deployment' category or > something like that where it should end up with the right people. +1 Thanks! Richard From phidias51 at gmail.com Mon Mar 25 10:29:09 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 25 Mar 2013 10:29:09 -0700 Subject: Packaging Application Metadata In-Reply-To: References: Message-ID: Hi Daniel, Thought I would jibber-jabber first on the list till there's some sort consensus before filing an issue. :-) My earlier thought was that JNLP could serve as a starting point for discussions, since people might already be familiar with it. Could you elaborate on this remark a bit: "[JNLP] has a lot of legacy that complicates areas that don't need it (e.g. native packaging)". What legacy are you referring to? I'm probably in the minority as far as webstart is concerned, but I've found it useful in the past as a means of keeping desktop apps in a company up-to-date. I haven't seen any cross-platform approach that comes close to being able to solve this problem (except perhaps Marimba back in the day). We don't really have a corporate Java App Store, where you could easily register an app and keep it up to date. There are some platform-specific solutions in the Winblows world, but I haven't seen anything that works everywhere. As for icon formats, I was thinking that we could register PNGs in the project, and the packaging tool/maven plugin could handle any platform-specific conversions. Cheers, Mark PS Welcome back from vacation! On Mon, Mar 25, 2013 at 8:06 AM, Daniel Zwolenski wrote: > I'd recommend creating a JIRA for this as the deployment guys are > (hopefully) working on improvements in this area. They may have > inclinations in this direction but I'd be surprised if there was anything > solid in the pipeline or on the horizon. There's a 'deployment' category or > something like that where it should end up with the right people. > > I looked at JNLP as a basis for this sort of stuff but it has a lot of > legacy that complicates areas that don't need it (e.g. native packaging). > I'd suggest (and have suggested in some long emails in the past) an > application profile of some kind that can be used as the main deployment > descriptor for Java apps regardless of how it gets deployed and may also > form the base of Auto Updating. > > Having said that, I'd personally leave JNLP and Applet completely alone > and only look at the newer deployment options for this sort of stuff. They > are likely to be unusable options before too long as browsers stop plugins > and OS's lock into app stores. The horrid legacy of JNLP and Applet hinder > all the new options (app stores, native installers, mobile, etc) from > evolving quickly. Some people will likely object to that though, just my > opinion. > > Also be aware there are complications with things like icon formats (need > to convert between .ico and .png, etc), image sizes, allowed characters and > lengths in names (e.g. wix supports different things to mac, etc), > licencing information needed for different platforms (e.g. app stores), > etc, etc. So standardising will be quite a complicated process that would > likely take a fair bit of time to nail down if work was started on it. As > usual don't pin your hopes on any good solution arriving soon (Java8 would > be extremely optimistic I imagine). > > > > > On Mon, Mar 25, 2013 at 9:44 AM, Mark Fortner wrote: > >> I've been wondering if there were any plans to standardize packaging >> metadata? It strikes me that we should be able to specify dock and >> desktop >> icons, splashscreens, application names, OS-specific packaging properties >> (like the ones used in Mac OS X) and dependencies in a single place that >> can be used by both an application packaging tool, and on application >> startup. The JNLP file has most of these elements already and could serve >> as a useful starting point. >> >> Any thoughts? >> >> Mark >> > > From richard.bair at oracle.com Mon Mar 25 10:35:51 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 25 Mar 2013 10:35:51 -0700 Subject: Proposal: Deprecate Builders Message-ID: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> We made a mistake. When we released JavaFX 2.0 we included a (large) set of *Builder classes to provide a builder-pattern approach to building JavaFX UIs. The builder-pattern approach provides several very nice features: - Ability to setup generic configuration once and "stamp out" multiple copies - Structured code style that closely approximates the "container hierarchy" of the UI - Strongly-typed "declarative" style programming The Builders did come at a cost. There are a lot of them, and if used, require more class loading which slows down startup. When Pack200 is not being used, they represent a sizable fraction of the code base. They clutter up the JavaDoc (although this could be solved by having a "Builder" section like there is an "Enum" section and "Interface" section). But all those advantages and costs were weighed and we concluded Builders were worth it, and they went in. Based on the above, I would still conclude that Builders are OK. However, it turns out our implementation has some intractable problems with respect to binary compatibility. In order to ensure our Builders are always up-to-date with the latest API added to the core classes, the Builders are auto-generated using an annotation processor. Also, in order to keep the size of the builders small relative to the rest of the platform, we employ complex use of generics in order to allow the builders to inherit. That is, ControlBuilder extends from ParentBuilder extends from NodeBuilder just as Control extends from Parent extends from Node. But accomplishing this was no easy feat. Although the "id(String)" method is defined on NodeBuilder, it must return a ControlBuilder when used from the ControlBuilder. All of this was accomplished using generics, and as it turns out, depended on two bugs in JDK 6 and JDK 7 in order to work (although we didn't know it at the time). Those bugs were fixed in JDK 8, and as a result, the builders no longer work correctly for certain cases. Just about any option we take is going to lead to a binary incompatibility in 8, however we find this unacceptable. If we cannot avoid it, then whatever we choice we make for 8 had better be a final solution -- not something we will later decide we need to tweak further. And this is what puts us in a tight spot. After having painfully looked over all of the alternatives, it seems to come down to this: a) Flatten the builder hierarchy so that ControlBuilder extends Object the same as ParentBuilder would and all other Builders. b) Stop using builders. Phase them out in a controlled manner. Option (a) works because we remove all generics from the equation. There are some 73 or so methods on NodeBuilder. These would be redefined on the Builder for each class that extends from Node. This solution works by solving the root problem -- generic use in builder subclassing scenarios. This solution however changes the cost/benefit analysis for Builders, because now they would then comprise a much larger fraction of the overall platform size. And this runs at cross purposes with embedded use cases. Option (b) works by removing Builders from the scenario entirely. Because this would be a *huge* breaking change, it would have to be managed carefully in a way that, in fact, won't break anybody (for at least several years). To implement this option, we would: 1) Add @Deprecate to all Builders with a URL in the description to a page describing the change and how to migrate 2) Stop auto-generating builders. We'd take whatever we had in the latest 2.x line and reuse them as-is. - This means that as new API is added to the platform, the builders wouldn't be updated to match 3) Remove the Builders from the Java 8 JavaDoc 4) Split the builders into a separate jar from jfxrt.jar. It would also be on the java.ext.libs path so that it is automatically picked up so that people are not broken when running FX 2.x apps on 8.x without modification. They'd still work. 5) Provide a download link to the fx2-builders.jar containing all these builders. 6) Encourage people to use fx2-builders.jar instead of relying on builders being on the class path by default 7) In Java 9, remove the builders from the class path (this is several years down the road) This proposal is essentially saying that the fix to make Builders work correctly reduces the value of the builders to the point where they just aren't worth it, and when considering Mobile / Embedded use cases, the extra cost of the builders is prohibitive. It also is based on the theory that the Builders are not being used by everybody, and so many people would not be negatively impacted but rather only positively impacted by no longer paying for the additional cost in bytes for the builders. It also recognizes that people who *are* using the builders and *do* like the programming style (including Jasper and many of our own) will see a loss of functionality that they have grown to like. The other thing to bear in mind is that most of the benefits of Builders don't have to come from Builders -- there are alternatives. For example, the 'Ability to setup generic configuration once and "stamp out" multiple copies' benefit can also be achieved by helper methods. The 'Structured code style that closely approximates the "container hierarchy" of the UI' advantage can be accomplished using FXML instead, or by using this pattern (which creates a boat-load of inner classes so it has its own problems): // The first set of braces defines it as an anonymous subclass, the second set as an initializer Group g = new Group() {{ getChildren().add(new Button() {{ setText("Hello"); }}); }}; Another option which we've discussed a bit is whether we could use lambda's to do configuration in a builder-like style in Java 8, somewhat like Groovy does. So for example: Group g = new Group(gg -> { gg.getChildren().addAll(new Button(b -> { b.setText("Hello"); }); }); This approach doesn't generate the mass of anonymous inner classes that the other double-brace approach does, but accomplishes the same basic job of using builders for (more or less) declarative construction of a container-hierarchy in code. So this is the long and the short of it. Eva can follow up with an in-depth post about the binary compatibility concerns if you wish. My proposal after having weighed the options is to phase out the Builders by deprecating them in 8 and removing them from the class path in 9. I believe that FXML or Lambda's or alternative languages all provide other avenues for achieving the same goals as builders but without the additional cost in byte codes or classes. We have some cases where SceneBuilder is presently relying on the Builders, and we'd have to provide alternatives for that functionality it is presently using (such as annotations for constructor arguments). Richard From tbee at tbee.org Mon Mar 25 10:45:40 2013 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 25 Mar 2013 18:45:40 +0100 Subject: Proposal: Deprecate Builders In-Reply-To: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> References: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> Message-ID: <51508D44.6050009@tbee.org> Clear message Richard. I'm wondering if people are really using the "stamp out multiple copies" feature a lot (after all, how many objects of the same stamp do you need?). But the structured code style probably is a high appriciated alternative. A different approach to have the same, could be the use of so called withers; Group g = new Group() .addChild( new Button() .withText("Hello") ) ); This would only add a number of fairly small methods (withers forward to setters and return "this") to the existing classes. Tom On 2013-03-25 18:35, Richard Bair wrote: > We made a mistake. When we released JavaFX 2.0 we included a (large) set of *Builder classes to provide a builder-pattern approach to building JavaFX UIs. The builder-pattern approach provides several very nice features: > - Ability to setup generic configuration once and "stamp out" multiple copies > - Structured code style that closely approximates the "container hierarchy" of the UI > - Strongly-typed "declarative" style programming > > The Builders did come at a cost. There are a lot of them, and if used, require more class loading which slows down startup. When Pack200 is not being used, they represent a sizable fraction of the code base. They clutter up the JavaDoc (although this could be solved by having a "Builder" section like there is an "Enum" section and "Interface" section). > > But all those advantages and costs were weighed and we concluded Builders were worth it, and they went in. Based on the above, I would still conclude that Builders are OK. However, it turns out our implementation has some intractable problems with respect to binary compatibility. > > In order to ensure our Builders are always up-to-date with the latest API added to the core classes, the Builders are auto-generated using an annotation processor. Also, in order to keep the size of the builders small relative to the rest of the platform, we employ complex use of generics in order to allow the builders to inherit. That is, ControlBuilder extends from ParentBuilder extends from NodeBuilder just as Control extends from Parent extends from Node. But accomplishing this was no easy feat. Although the "id(String)" method is defined on NodeBuilder, it must return a ControlBuilder when used from the ControlBuilder. All of this was accomplished using generics, and as it turns out, depended on two bugs in JDK 6 and JDK 7 in order to work (although we didn't know it at the time). Those bugs were fixed in JDK 8, and as a result, the builders no longer work correctly for certain cases. Just about any option we take is going to lead to a binary incompatibility in 8, however we find this unacceptable. If we cannot avoid it, then whatever we choice we make for 8 had better be a final solution -- not something we will later decide we need to tweak further. > > And this is what puts us in a tight spot. After having painfully looked over all of the alternatives, it seems to come down to this: > a) Flatten the builder hierarchy so that ControlBuilder extends Object the same as ParentBuilder would and all other Builders. > b) Stop using builders. Phase them out in a controlled manner. > > Option (a) works because we remove all generics from the equation. There are some 73 or so methods on NodeBuilder. These would be redefined on the Builder for each class that extends from Node. This solution works by solving the root problem -- generic use in builder subclassing scenarios. This solution however changes the cost/benefit analysis for Builders, because now they would then comprise a much larger fraction of the overall platform size. And this runs at cross purposes with embedded use cases. > > Option (b) works by removing Builders from the scenario entirely. Because this would be a *huge* breaking change, it would have to be managed carefully in a way that, in fact, won't break anybody (for at least several years). To implement this option, we would: > 1) Add @Deprecate to all Builders with a URL in the description to a page describing the change and how to migrate > 2) Stop auto-generating builders. We'd take whatever we had in the latest 2.x line and reuse them as-is. > - This means that as new API is added to the platform, the builders wouldn't be updated to match > 3) Remove the Builders from the Java 8 JavaDoc > 4) Split the builders into a separate jar from jfxrt.jar. It would also be on the java.ext.libs path so that it is automatically picked up so that people are not broken when running FX 2.x apps on 8.x without modification. They'd still work. > 5) Provide a download link to the fx2-builders.jar containing all these builders. > 6) Encourage people to use fx2-builders.jar instead of relying on builders being on the class path by default > 7) In Java 9, remove the builders from the class path (this is several years down the road) > > This proposal is essentially saying that the fix to make Builders work correctly reduces the value of the builders to the point where they just aren't worth it, and when considering Mobile / Embedded use cases, the extra cost of the builders is prohibitive. It also is based on the theory that the Builders are not being used by everybody, and so many people would not be negatively impacted but rather only positively impacted by no longer paying for the additional cost in bytes for the builders. It also recognizes that people who *are* using the builders and *do* like the programming style (including Jasper and many of our own) will see a loss of functionality that they have grown to like. > > The other thing to bear in mind is that most of the benefits of Builders don't have to come from Builders -- there are alternatives. For example, the 'Ability to setup generic configuration once and "stamp out" multiple copies' benefit can also be achieved by helper methods. The 'Structured code style that closely approximates the "container hierarchy" of the UI' advantage can be accomplished using FXML instead, or by using this pattern (which creates a boat-load of inner classes so it has its own problems): > > // The first set of braces defines it as an anonymous subclass, the second set as an initializer > Group g = new Group() {{ > getChildren().add(new Button() {{ > setText("Hello"); > }}); > }}; > > Another option which we've discussed a bit is whether we could use lambda's to do configuration in a builder-like style in Java 8, somewhat like Groovy does. So for example: > > Group g = new Group(gg -> { > gg.getChildren().addAll(new Button(b -> { > b.setText("Hello"); > }); > }); > > This approach doesn't generate the mass of anonymous inner classes that the other double-brace approach does, but accomplishes the same basic job of using builders for (more or less) declarative construction of a container-hierarchy in code. > > So this is the long and the short of it. Eva can follow up with an in-depth post about the binary compatibility concerns if you wish. My proposal after having weighed the options is to phase out the Builders by deprecating them in 8 and removing them from the class path in 9. I believe that FXML or Lambda's or alternative languages all provide other avenues for achieving the same goals as builders but without the additional cost in byte codes or classes. > > We have some cases where SceneBuilder is presently relying on the Builders, and we'd have to provide alternatives for that functionality it is presently using (such as annotations for constructor arguments). > > Richard From danno.ferrin at shemnon.com Mon Mar 25 11:09:09 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 25 Mar 2013 12:09:09 -0600 Subject: Packaging Application Metadata In-Reply-To: References: Message-ID: Of course this discussion starts while I am away on spring break. The current way icons are handled are per-platform. Windows wants a ICO and BMP, mac wants an ICNS, and linux wants a PNG. And the 'location' for them is in the classpath under a package 'platform/windows', 'platform/mac', and 'platform/linux.' That's not the worst. The names of the icons are based upon the name of the application, so it would be 'platform/mac/My Awesome App.icn