From anthony.petrov at oracle.com Mon Apr 1 01:27:41 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 01 Apr 2013 12:27:41 +0400 Subject: Threads completely freak out In-Reply-To: References: Message-ID: <515944FD.1080001@oracle.com> Happening on Mac, right? It's fixed already: https://javafx-jira.kenai.com/browse/RT-28993 Please wait for the next build. -- best regards, Anthony On 3/30/2013 5:29, Hendrik Ebbers wrote: > Hi, > today I tried to debug a JFX8 app with eclipse and used build 81 for this. But by using JavaFX in JDK8 the VM seems to create and destroy so many short living threads that the eclipse debugger can't handle this behavior. Is this a wanted behavior? And if yes, why isn't this done by thread pools? > > Cheers, > Hendrik From hendrik.ebbers at me.com Mon Apr 1 04:15:50 2013 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Mon, 01 Apr 2013 13:15:50 +0200 Subject: Threads completely freak out In-Reply-To: <515944FD.1080001@oracle.com> References: <515944FD.1080001@oracle.com> Message-ID: Cool thx! Am 01.04.2013 um 10:27 schrieb Anthony Petrov : > Happening on Mac, right? It's fixed already: > > https://javafx-jira.kenai.com/browse/RT-28993 > > Please wait for the next build. > > -- > best regards, > Anthony > > On 3/30/2013 5:29, Hendrik Ebbers wrote: >> Hi, >> today I tried to debug a JFX8 app with eclipse and used build 81 for this. But by using JavaFX in JDK8 the VM seems to create and destroy so many short living threads that the eclipse debugger can't handle this behavior. Is this a wanted behavior? And if yes, why isn't this done by thread pools? >> Cheers, >> Hendrik From hang.vo at oracle.com Mon Apr 1 05:47:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 01 Apr 2013 12:47:36 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29312: Quantum cleanup: get rid of PrismPen Message-ID: <20130401124749.10525484FB@hg.openjdk.java.net> Changeset: 310abf468b7b Author: Artem Ananiev Date: 2013-04-01 05:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/310abf468b7b RT-29312: Quantum cleanup: get rid of PrismPen Reviewed-by: David Hill, Kevin Rushforth ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/EmbeddedPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/EmbeddedScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/OverlayWarning.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/PrismPen.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/UploadingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/ViewPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/ViewScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/WindowStage.java From swpalmer at gmail.com Mon Apr 1 07:02:10 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 1 Apr 2013 10:02:10 -0400 Subject: JavaFX Toolkit and Pipeline details Message-ID: The About Box for Scene Builder shows: JavaFX Toolkit = QuantumToolkit Pipeline = D3DPipeline Hardware acceleration ENABLED How can I get this information to show something similar in my application about box? (I looked for system properties along the lines of AWT/Swing's "awt.toolkit", "java.awt.graphicsenv" etc.. but didn't see anything). Thanks, Scott From kevin.rushforth at oracle.com Mon Apr 1 07:31:53 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 Apr 2013 07:31:53 -0700 Subject: JavaFX Toolkit and Pipeline details In-Reply-To: References: Message-ID: <51599A59.9010308@oracle.com> There is no public API for this information. -- Kevin Scott Palmer wrote: > The About Box for Scene Builder shows: > > JavaFX > Toolkit = QuantumToolkit > Pipeline = D3DPipeline > Hardware acceleration ENABLED > > How can I get this information to show something similar in my application > about box? > (I looked for system properties along the lines of AWT/Swing's > "awt.toolkit", "java.awt.graphicsenv" etc.. but didn't see anything). > > > Thanks, > > Scott > From swpalmer at gmail.com Mon Apr 1 08:37:55 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 1 Apr 2013 11:37:55 -0400 Subject: JavaFX Toolkit and Pipeline details In-Reply-To: <51599A59.9010308@oracle.com> References: <51599A59.9010308@oracle.com> Message-ID: Okay. Next question? should there be a public API for this? I realize that most applications shouldn't care about it, but tech support people might. If a customer complains that my app is flickering, or slow, etc. and I can grab this information and see that hardware acceleration is not enabled for some reason, that would be helpful. Presumably someone at Oracle agrees because I doubt the Scene Builder devs put it there just for fun :-) Scott On 2013-04-01, at 10:31 AM, Kevin Rushforth wrote: > There is no public API for this information. > > -- Kevin > > > Scott Palmer wrote: >> The About Box for Scene Builder shows: >> >> JavaFX >> Toolkit = QuantumToolkit >> Pipeline = D3DPipeline >> Hardware acceleration ENABLED >> >> How can I get this information to show something similar in my application >> about box? >> (I looked for system properties along the lines of AWT/Swing's >> "awt.toolkit", "java.awt.graphicsenv" etc.. but didn't see anything). >> >> >> Thanks, >> >> Scott >> From kevin.rushforth at oracle.com Mon Apr 1 08:52:45 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 Apr 2013 08:52:45 -0700 Subject: JavaFX Toolkit and Pipeline details In-Reply-To: References: <51599A59.9010308@oracle.com> Message-ID: <5159AD4D.6030704@oracle.com> Most of these are internal details that we would not want to provide via public API, but knowing whether it is running as HW versus SW is helpful, as long as it is exposed as some sort of capability rather than a specific pipeline name. Can you log a new JIRA (Tweak) for this? -- Kevin Scott Palmer wrote: > Okay. Next question? should there be a public API for this? I realize that most applications shouldn't care about it, but tech support people might. If a customer complains that my app is flickering, or slow, etc. and I can grab this information and see that hardware acceleration is not enabled for some reason, that would be helpful. > Presumably someone at Oracle agrees because I doubt the Scene Builder devs put it there just for fun :-) > > Scott > > > > On 2013-04-01, at 10:31 AM, Kevin Rushforth wrote: > > >> There is no public API for this information. >> >> -- Kevin >> >> >> Scott Palmer wrote: >> >>> The About Box for Scene Builder shows: >>> >>> JavaFX >>> Toolkit = QuantumToolkit >>> Pipeline = D3DPipeline >>> Hardware acceleration ENABLED >>> >>> How can I get this information to show something similar in my application >>> about box? >>> (I looked for system properties along the lines of AWT/Swing's >>> "awt.toolkit", "java.awt.graphicsenv" etc.. but didn't see anything). >>> >>> >>> Thanks, >>> >>> Scott >>> >>> > > From swpalmer at gmail.com Mon Apr 1 09:03:34 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 1 Apr 2013 12:03:34 -0400 Subject: JavaFX Toolkit and Pipeline details In-Reply-To: <5159AD4D.6030704@oracle.com> References: <51599A59.9010308@oracle.com> <5159AD4D.6030704@oracle.com> Message-ID: <71EBD63B-A7B3-4710-BE1C-80E0894DDD80@gmail.com> RT-29368 - Provide a method to determine if HW vs SW rendering is used Done. On 2013-04-01, at 11:52 AM, Kevin Rushforth wrote: > Most of these are internal details that we would not want to provide via public API, but knowing whether it is running as HW versus SW is helpful, as long as it is exposed as some sort of capability rather than a specific pipeline name. > > Can you log a new JIRA (Tweak) for this? > > -- Kevin > > > Scott Palmer wrote: >> >> Okay. Next question? should there be a public API for this? I realize that most applications shouldn't care about it, but tech support people might. If a customer complains that my app is flickering, or slow, etc. and I can grab this information and see that hardware acceleration is not enabled for some reason, that would be helpful. >> Presumably someone at Oracle agrees because I doubt the Scene Builder devs put it there just for fun :-) >> >> Scott >> >> >> >> On 2013-04-01, at 10:31 AM, Kevin Rushforth wrote: >> >> >>> There is no public API for this information. >>> >>> -- Kevin >>> >>> >>> Scott Palmer wrote: >>> >>>> The About Box for Scene Builder shows: >>>> >>>> JavaFX >>>> Toolkit = QuantumToolkit >>>> Pipeline = D3DPipeline >>>> Hardware acceleration ENABLED >>>> >>>> How can I get this information to show something similar in my application >>>> about box? >>>> (I looked for system properties along the lines of AWT/Swing's >>>> "awt.toolkit", "java.awt.graphicsenv" etc.. but didn't see anything). >>>> >>>> >>>> Thanks, >>>> >>>> Scott >>>> >>>> >> >> From hang.vo at oracle.com Mon Apr 1 09:48:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 01 Apr 2013 16:48:06 +0000 Subject: hg: openjfx/8/graphics/rt: [Eclipse only] fix .classpath to exclude SwingNode as it requires Java8 Message-ID: <20130401164813.5BF4148501@hg.openjdk.java.net> Changeset: 907c01d3625a Author: Felipe Heidrich Date: 2013-04-01 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/907c01d3625a [Eclipse only] fix .classpath to exclude SwingNode as it requires Java8 ! .classpath From hang.vo at oracle.com Mon Apr 1 11:03:20 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 01 Apr 2013 18:03:20 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-29157 CustomColorDialog doesn't support resizing. Message-ID: <20130401180329.CE32C48502@hg.openjdk.java.net> Changeset: dcf80f478939 Author: Alexander Kouznetsov Date: 2013-04-01 10:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dcf80f478939 Fixed RT-29157 CustomColorDialog doesn't support resizing. Reviewed by Paru ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Mon Apr 1 11:32:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 01 Apr 2013 18:32:37 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29379 Ensemble8: ServiceApp doesn't fit smaller pages Message-ID: <20130401183243.B2A7448503@hg.openjdk.java.net> Changeset: 13a4a4ba90d1 Author: dmasada Date: 2013-04-01 11:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/13a4a4ba90d1 RT-29379 Ensemble8: ServiceApp doesn't fit smaller pages ! apps/samples/Ensemble8/src/samples/ensemble/samples/concurrency/service/ServiceApp.java From hang.vo at oracle.com Mon Apr 1 11:47:40 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 01 Apr 2013 18:47:40 +0000 Subject: hg: openjfx/8/controls/rt: RT-28152 tickLabelFill property not bound to tick labels and unit test. Message-ID: <20130401184749.5785B48504@hg.openjdk.java.net> Changeset: e6c525fe6aac Author: Paru Somashekar Date: 2013-04-01 11:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e6c525fe6aac RT-28152 tickLabelFill property not bound to tick labels and unit test. ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java From phidias51 at gmail.com Mon Apr 1 12:05:03 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 1 Apr 2013 12:05:03 -0700 Subject: Platform#runLater Question Message-ID: In the past, I've found the *Platform#runLater* method to be a useful way to run tasks. However, I've noticed that the code that runs my thread is not really configurable or accessible. For example, it would be nice to be able to specify and configure a top-level *ThreadPoolExecutor* to handle my tasks. Or be able to switch out *Executor* implementations. I was wondering if there was some reason for implementing runLater this way, or if there are any plans to change it in the future? Cheers, Mark From richard.bair at oracle.com Mon Apr 1 12:31:47 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 1 Apr 2013 12:31:47 -0700 Subject: Platform#runLater Question In-Reply-To: References: Message-ID: <79DDC21F-3081-4CFA-9A09-2AC440F8F274@oracle.com> I'm not sure I follow. #runLater is a means for putting some runnable on the event queue for execution on the event thread at some point in the future. The event queue is typically a native one (hence no means to replace it via setting another executor). Of course on the Service is an executor that you could specify for running background jobs. Richard On Apr 1, 2013, at 12:05 PM, Mark Fortner wrote: > In the past, I've found the *Platform#runLater* method to be a useful way > to run tasks. However, I've noticed that the code that runs my thread is > not really configurable or accessible. For example, it would be nice to be > able to specify and configure a top-level *ThreadPoolExecutor* to handle my > tasks. Or be able to switch out *Executor* implementations. > > I was wondering if there was some reason for implementing runLater this > way, or if there are any plans to change it in the future? > > > Cheers, > > Mark From hang.vo at oracle.com Mon Apr 1 14:47:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 01 Apr 2013 21:47:53 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28214: Disallow Camera belonging to one scene to be set as the camera of another scene Message-ID: <20130401214800.2A2D74850D@hg.openjdk.java.net> Changeset: 68122b30b843 Author: Yao Wang Date: 2013-04-01 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/68122b30b843 RT-28214: Disallow Camera belonging to one scene to be set as the camera of another scene ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SubScene.java ! javafx-ui-common/test/unit/javafx/scene/SceneTest.java + javafx-ui-common/test/unit/javafx/scene/SubSceneTest.java From hang.vo at oracle.com Mon Apr 1 20:17:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Apr 2013 03:17:44 +0000 Subject: hg: openjfx/8/graphics/rt: fix camera property for RT-28214 Disallow Camera belonging to one scene to be set as the camera of another scene Message-ID: <20130402031751.78A1448518@hg.openjdk.java.net> Changeset: c83e4d489d14 Author: Yao Wang Date: 2013-04-01 20:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c83e4d489d14 fix camera property for RT-28214 Disallow Camera belonging to one scene to be set as the camera of another scene ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SubScene.java From anthony.petrov at oracle.com Tue Apr 2 01:18:11 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 02 Apr 2013 12:18:11 +0400 Subject: Platform#runLater Question In-Reply-To: References: Message-ID: <515A9443.1020408@oracle.com> Platform#runLater is not a general purpose mechanism to execute deferred tasks. Its purpose is to schedule execution of runnables on the event thread in order to perform GUI-related operations. As Richard says, the event thread is a native GUI thread. There's only one such thread per application, hence the design of this machinery. Note that running code that is unrelated to GUI on the event thread may only make your application UI more sluggish and jerky, or even appearing frozen sometimes. If you need to execute general-purpose tasks asynchronously, you have to create an executor service instance (such as a ForkJoinPool) yourself and submit your runnables there. -- best regards, Anthony On 4/1/2013 23:05, Mark Fortner wrote: > In the past, I've found the *Platform#runLater* method to be a useful way > to run tasks. However, I've noticed that the code that runs my thread is > not really configurable or accessible. For example, it would be nice to be > able to specify and configure a top-level *ThreadPoolExecutor* to handle my > tasks. Or be able to switch out *Executor* implementations. > > I was wondering if there was some reason for implementing runLater this > way, or if there are any plans to change it in the future? > > > Cheers, > > Mark From hang.vo at oracle.com Tue Apr 2 02:03:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Apr 2013 09:03:27 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29301 Clarify Stage.resizableProperty().bindBidirectional() Message-ID: <20130402090336.D3B8548523@hg.openjdk.java.net> Changeset: 4ba1d26b27a8 Author: Martin Sladecek Date: 2013-04-02 10:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4ba1d26b27a8 RT-29301 Clarify Stage.resizableProperty().bindBidirectional() ! javafx-ui-common/src/javafx/stage/Stage.java From hang.vo at oracle.com Tue Apr 2 05:04:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Apr 2013 12:04:00 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29401: fixed click event's scene coordinates in 3D. Message-ID: <20130402120406.6EDF848527@hg.openjdk.java.net> Changeset: 6a2d0bf083cd Author: Pavel Safrata Date: 2013-04-02 12:56 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a2d0bf083cd RT-29401: fixed click event's scene coordinates in 3D. ! javafx-ui-common/src/javafx/scene/Scene.java From hang.vo at oracle.com Tue Apr 2 05:17:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Apr 2013 12:17:50 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130402121759.5A59748529@hg.openjdk.java.net> Changeset: 584ac4f66a55 Author: Pavel Safrata Date: 2013-04-02 13:05 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/584ac4f66a55 Improved 3D picking tests to use real scenegraph-computed pick ray. Removed temporary workaround in perspective camera. ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/test/unit/javafx/scene/Mouse3DTest.java Changeset: 87ebb6d34a00 Author: Eva Krejcirova Date: 2013-04-02 13:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/87ebb6d34a00 [DOC-ONLY] RT-29043: A typo in the BorderPane class description ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java From hang.vo at oracle.com Tue Apr 2 05:47:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Apr 2013 12:47:31 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130402124740.8DC344852A@hg.openjdk.java.net> Changeset: 3229601bda3f Author: Martin Sladecek Date: 2013-04-02 14:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3229601bda3f RT-16882 Changing BorderPane contraints (adding and removing same component) causes component to disappear ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/BorderPaneTest.java Changeset: fcef89ba5594 Author: Martin Sladecek Date: 2013-04-02 14:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fcef89ba5594 merge ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java From zonski at gmail.com Tue Apr 2 06:24:42 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 2 Apr 2013 08:24:42 -0500 Subject: IntelliJ 12.1 - FXML support added Message-ID: http://youtrack.jetbrains.com/issue/IDEA-75173 From anthony.petrov at oracle.com Tue Apr 2 06:31:47 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 02 Apr 2013 17:31:47 +0400 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> Message-ID: <515ADDC3.7080108@oracle.com> (Please use "Reply All" when replying to a mailing list. Thank you.) I'm not sure what Task you mean here, and how you started its execution in the first place. But if I assume you've followed my advice and created your own executor service and submitted your task to it, then the answer is no. The executor service doesn't know anything about FX or its event thread. I suggest to use runLater() in your onSucceeded and onFailed implementations for your task if you need this code to perform some GUI-related operations. -- best regards, Anthony On 4/2/2013 17:23, Mark Fortner wrote: > Thanks, Anthony. The light came on after I saw Richard's reply. Are the > onSucceeded, onFailed methods of Tasks executed on the Application > thread or do I need to call runLater? > > Mark > > On Apr 2, 2013 1:18 AM, "Anthony Petrov" > wrote: > > Platform#runLater is not a general purpose mechanism to execute > deferred tasks. Its purpose is to schedule execution of runnables on > the event thread in order to perform GUI-related operations. As > Richard says, the event thread is a native GUI thread. There's only > one such thread per application, hence the design of this machinery. > > Note that running code that is unrelated to GUI on the event thread > may only make your application UI more sluggish and jerky, or even > appearing frozen sometimes. > > If you need to execute general-purpose tasks asynchronously, you > have to create an executor service instance (such as a ForkJoinPool) > yourself and submit your runnables there. > > -- > best regards, > Anthony > > On 4/1/2013 23:05, Mark Fortner wrote: > > In the past, I've found the *Platform#runLater* method to be a > useful way > to run tasks. However, I've noticed that the code that runs my > thread is > not really configurable or accessible. For example, it would be > nice to be > able to specify and configure a top-level *ThreadPoolExecutor* > to handle my > tasks. Or be able to switch out *Executor* implementations. > > I was wondering if there was some reason for implementing > runLater this > way, or if there are any plans to change it in the future? > > > Cheers, > > Mark > From richard.bair at oracle.com Tue Apr 2 08:21:16 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 2 Apr 2013 08:21:16 -0700 Subject: Gradle build progress In-Reply-To: References: <84351F9A-271B-482A-B1B8-09D6A87F8331@oracle.com> Message-ID: <3A2406FC-A8BD-4B43-B2AA-6C4DDCDA907E@oracle.com> Hi Ali, I will apply. Thanks for the patch! Richard On Mar 30, 2013, at 4:37 AM, Ali Ebrahimi wrote: > Hi, > I just provide patch for getting Win Sdk dir from system variable: > > diff -r 28fd91194a80 win.gradle > --- a/win.gradle Fri Mar 29 17:06:43 2013 -0700 > +++ b/win.gradle Sat Mar 30 15:54:08 2013 +0430 > @@ -71,7 +71,7 @@ > windows_tools_stream = new FileInputStream(windows_tools); > windows_tools_properties.load(windows_tools_stream); > defineProperty("WINDOWS_VS_VSINSTALLDIR", windows_tools_properties, "absolute garbage"); > - defineProperty("WINDOWS_SDK_DIR", windows_tools_properties, "C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A") > + defineProperty("WINDOWS_SDK_DIR", windows_tools_properties, System.getenv().get("WindowsSdkDir")) > defineProperty("WINDOWS_VS_VCINSTALLDIR", windows_tools_properties, "$WINDOWS_VS_VSINSTALLDIR/VC") > defineProperty("WINDOWS_VS_DEVENVDIR", windows_tools_properties, "$WINDOWS_VS_VSINSTALLDIR/Common7/IDE") > defineProperty("WINDOWS_VS_DEVENVCMD", windows_tools_properties, "$WINDOWS_VS_DEVENVDIR/VCExpress.exe") > > > Ali Ebrahimi > > > > On Wed, Mar 20, 2013 at 10:25 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. > > 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 richard.bair at oracle.com Tue Apr 2 08:27:46 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 2 Apr 2013 08:27:46 -0700 Subject: Platform#runLater Question In-Reply-To: <515ADDC3.7080108@oracle.com> References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: Hi Anthony, he's talking about http://docs.oracle.com/javafx/2/api/javafx/concurrent/Task.html and related API in the javafx.concurrent package. The answer is yes, the onXXX methods of Task are called on the FX thread, and as such, you don't need to perform another runLater. There's a large amount of documentation that should (hopefully) clearly detail which threads which methods are called on (and which methods can be called from any thread vs. only the FX thread). But in general on Task only the "call" method is called on a background thread, and you may call any of the updateXXX methods from the background thread but all other methods are on the FX thread. Cheers Richard On Apr 2, 2013, at 6:31 AM, Anthony Petrov wrote: > (Please use "Reply All" when replying to a mailing list. Thank you.) > > I'm not sure what Task you mean here, and how you started its execution in the first place. But if I assume you've followed my advice and created your own executor service and submitted your task to it, then the answer is no. The executor service doesn't know anything about FX or its event thread. I suggest to use runLater() in your onSucceeded and onFailed implementations for your task if you need this code to perform some GUI-related operations. > > -- > best regards, > Anthony > > On 4/2/2013 17:23, Mark Fortner wrote: >> Thanks, Anthony. The light came on after I saw Richard's reply. Are the onSucceeded, onFailed methods of Tasks executed on the Application thread or do I need to call runLater? >> Mark >> On Apr 2, 2013 1:18 AM, "Anthony Petrov" > wrote: >> Platform#runLater is not a general purpose mechanism to execute >> deferred tasks. Its purpose is to schedule execution of runnables on >> the event thread in order to perform GUI-related operations. As >> Richard says, the event thread is a native GUI thread. There's only >> one such thread per application, hence the design of this machinery. >> Note that running code that is unrelated to GUI on the event thread >> may only make your application UI more sluggish and jerky, or even >> appearing frozen sometimes. >> If you need to execute general-purpose tasks asynchronously, you >> have to create an executor service instance (such as a ForkJoinPool) >> yourself and submit your runnables there. >> -- >> best regards, >> Anthony >> On 4/1/2013 23:05, Mark Fortner wrote: >> In the past, I've found the *Platform#runLater* method to be a >> useful way >> to run tasks. However, I've noticed that the code that runs my >> thread is >> not really configurable or accessible. For example, it would be >> nice to be >> able to specify and configure a top-level *ThreadPoolExecutor* >> to handle my >> tasks. Or be able to switch out *Executor* implementations. >> I was wondering if there was some reason for implementing >> runLater this >> way, or if there are any plans to change it in the future? >> Cheers, >> Mark From zonski at gmail.com Tue Apr 2 09:25:58 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 2 Apr 2013 11:25:58 -0500 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: Just on the topic, I've had situations where I've wanted Tasks (and Services) to run in my own threading model (e.g. for unit testing). So I've had similar wants to Mark's original request (but not directly with Platform.runLater, though that may also be useful). It would be nice if the Task API was really just a way of saying what I want done at each stage (i.e. doThisStuffBefore, doTaskStuff, doThisStuffAfter), then I could/should be able to call those methods directly myself from my own execution framework that may or may not be FX related or even thread related (in much the same way Runnable doesnt necessairly have anything to do with Threads). >From memory this wasnt (cleanly/easily) achievable because of the tight interdependency between Tasks and the FX threading model and property change events, etc. A couple of use cases: - unit or integration testing, where I want to make sure certain things/tasks happen in a certain sequence. - reusing tasks (particularly the background bit of them) outside of JFX eg. reuse of REST style calls in an Android, Swing, Command line, GWT, or AJAX based app (Java compiled to JScript). On Tue, Apr 2, 2013 at 10:27 AM, Richard Bair wrote: > Hi Anthony, he's talking about > http://docs.oracle.com/javafx/2/api/javafx/concurrent/Task.html and > related API in the javafx.concurrent package. > > The answer is yes, the onXXX methods of Task are called on the FX thread, > and as such, you don't need to perform another runLater. There's a large > amount of documentation that should (hopefully) clearly detail which > threads which methods are called on (and which methods can be called from > any thread vs. only the FX thread). But in general on Task only the "call" > method is called on a background thread, and you may call any of the > updateXXX methods from the background thread but all other methods are on > the FX thread. > > Cheers > Richard > > On Apr 2, 2013, at 6:31 AM, Anthony Petrov > wrote: > > > (Please use "Reply All" when replying to a mailing list. Thank you.) > > > > I'm not sure what Task you mean here, and how you started its execution > in the first place. But if I assume you've followed my advice and created > your own executor service and submitted your task to it, then the answer is > no. The executor service doesn't know anything about FX or its event > thread. I suggest to use runLater() in your onSucceeded and onFailed > implementations for your task if you need this code to perform some > GUI-related operations. > > > > -- > > best regards, > > Anthony > > > > On 4/2/2013 17:23, Mark Fortner wrote: > >> Thanks, Anthony. The light came on after I saw Richard's reply. Are the > onSucceeded, onFailed methods of Tasks executed on the Application thread > or do I need to call runLater? > >> Mark > >> On Apr 2, 2013 1:18 AM, "Anthony Petrov" anthony.petrov at oracle.com>> wrote: > >> Platform#runLater is not a general purpose mechanism to execute > >> deferred tasks. Its purpose is to schedule execution of runnables on > >> the event thread in order to perform GUI-related operations. As > >> Richard says, the event thread is a native GUI thread. There's only > >> one such thread per application, hence the design of this machinery. > >> Note that running code that is unrelated to GUI on the event thread > >> may only make your application UI more sluggish and jerky, or even > >> appearing frozen sometimes. > >> If you need to execute general-purpose tasks asynchronously, you > >> have to create an executor service instance (such as a ForkJoinPool) > >> yourself and submit your runnables there. > >> -- > >> best regards, > >> Anthony > >> On 4/1/2013 23:05, Mark Fortner wrote: > >> In the past, I've found the *Platform#runLater* method to be a > >> useful way > >> to run tasks. However, I've noticed that the code that runs my > >> thread is > >> not really configurable or accessible. For example, it would be > >> nice to be > >> able to specify and configure a top-level *ThreadPoolExecutor* > >> to handle my > >> tasks. Or be able to switch out *Executor* implementations. > >> I was wondering if there was some reason for implementing > >> runLater this > >> way, or if there are any plans to change it in the future? > >> Cheers, > >> Mark > > From hang.vo at oracle.com Tue Apr 2 10:02:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Apr 2013 17:02:54 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130402170303.4606A4853B@hg.openjdk.java.net> Changeset: b5866e91dc0b Author: hudson Date: 2013-03-28 15:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b5866e91dc0b Added tag 8.0-b83 for changeset b1da897ab209 ! .hgtags Changeset: bc233d4feaac Author: Yao Wang Date: 2013-04-02 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bc233d4feaac Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PrismPen.java From phidias51 at gmail.com Tue Apr 2 10:17:30 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 2 Apr 2013 10:17:30 -0700 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: Here's the genesis of the original question, this may give you some ideas for the future. I have an app where initially I had a lot of point-to-point event listening. I created a generic event helper -- basically a mixin with an executor to let me easily add event support to any class. I then realized that what I really wanted was to centralize all event management in a single place within my app. The main reason for this was that it becomes very easy to lose track of who's listening to what when that code is scattered throughout a project. So, I created an event manager, added it to my application context so that I could easily access it from anywhere in my code, and added the event helpers to the event manager. Ultimately, the use cases that I'd like to cover cleanly are: MyContext.fireEvent(event) // lets you fire an event, and notify all relevant listeners MyContext.addListener(eventHandler, eventType...) // let a listener listen to a variety of event types MyContext.removeListener(event, eventType...) // remove the listener from the event types I haven't yet figured out a clean way of removing listeners. It would be nice if components had a life cycle with a "destructor" to let them do this kind of cleanup. I don't think *finalize()* is the appropriate place to take care of things like that. Perhaps by making *WeakListeners*, this problem might go away on it's own and no specific "removeListener" method is necessary. I'm also planning on making the event helpers Spring-configurable so that it's easy to tune the performance of specific types of events. I have some events that trigger immediate responses in the GUI, and others that happen in the background and only require the GUI to update when they complete (either onSuccess, or onFailure). In order to make the GUI performance more tuneable, I'll set the executor's thread pool size in the Spring config. When I tried unit testing some of this, the threading got in the way of JUnit, and I haven't figured out a good alternative for this yet. A JUnitExecutor might be a useful addition. The other thing I'd like to be able to do, is inject a component capable of monitoring either a single event helper, or the event manager in general. I have some events that are cached, and only persisted to the database when the user decides that he's finished making adjustments. If I attempted to persist each small change the user makes, there would be too much chatter going on and performance would suffer. I'd like to simply attach a component that would monitor all tasks and give the user feedback when things have updated properly. If there are any problems, the progress bars (one per task) would turn red, and the user could click on a specific bar to get detailed error information. In cases where the events are not cached, I'm planning on a creating a simple generic Task that shows success or failure dialogs when the task completes. If I take Anthony's suggestion correctly, the *call* method is the equivalent of Dan's *doTaskStuff*, and the *onSuccess* or *onFailure*is the equivalent of *doThisStuffAfter. * From the docs, it sounds like Services are (aside from being confusingly named) reusable Tasks. Hope this helps, Mark On Tue, Apr 2, 2013 at 9:25 AM, Daniel Zwolenski wrote: > Just on the topic, I've had situations where I've wanted Tasks (and > Services) to run in my own threading model (e.g. for unit testing). So I've > had similar wants to Mark's original request (but not directly with > Platform.runLater, though that may also be useful). > > It would be nice if the Task API was really just a way of saying what I > want done at each stage (i.e. doThisStuffBefore, doTaskStuff, > doThisStuffAfter), then I could/should be able to call those methods > directly myself from my own execution framework that may or may not be FX > related or even thread related (in much the same way Runnable doesnt > necessairly have anything to do with Threads). > > >From memory this wasnt (cleanly/easily) achievable because of the tight > interdependency between Tasks and the FX threading model and property > change events, etc. > > A couple of use cases: > > - unit or integration testing, where I want to make sure certain > things/tasks happen in a certain sequence. > - reusing tasks (particularly the background bit of them) outside of JFX > eg. reuse of REST style calls in an Android, Swing, Command line, GWT, > or > AJAX based app (Java compiled to JScript). > > > > > > > > > > > > On Tue, Apr 2, 2013 at 10:27 AM, Richard Bair >wrote: > > > Hi Anthony, he's talking about > > http://docs.oracle.com/javafx/2/api/javafx/concurrent/Task.html and > > related API in the javafx.concurrent package. > > > > The answer is yes, the onXXX methods of Task are called on the FX thread, > > and as such, you don't need to perform another runLater. There's a large > > amount of documentation that should (hopefully) clearly detail which > > threads which methods are called on (and which methods can be called from > > any thread vs. only the FX thread). But in general on Task only the > "call" > > method is called on a background thread, and you may call any of the > > updateXXX methods from the background thread but all other methods are on > > the FX thread. > > > > Cheers > > Richard > > > > On Apr 2, 2013, at 6:31 AM, Anthony Petrov > > wrote: > > > > > (Please use "Reply All" when replying to a mailing list. Thank you.) > > > > > > I'm not sure what Task you mean here, and how you started its execution > > in the first place. But if I assume you've followed my advice and created > > your own executor service and submitted your task to it, then the answer > is > > no. The executor service doesn't know anything about FX or its event > > thread. I suggest to use runLater() in your onSucceeded and onFailed > > implementations for your task if you need this code to perform some > > GUI-related operations. > > > > > > -- > > > best regards, > > > Anthony > > > > > > On 4/2/2013 17:23, Mark Fortner wrote: > > >> Thanks, Anthony. The light came on after I saw Richard's reply. Are > the > > onSucceeded, onFailed methods of Tasks executed on the Application thread > > or do I need to call runLater? > > >> Mark > > >> On Apr 2, 2013 1:18 AM, "Anthony Petrov" > anthony.petrov at oracle.com>> wrote: > > >> Platform#runLater is not a general purpose mechanism to execute > > >> deferred tasks. Its purpose is to schedule execution of runnables > on > > >> the event thread in order to perform GUI-related operations. As > > >> Richard says, the event thread is a native GUI thread. There's only > > >> one such thread per application, hence the design of this > machinery. > > >> Note that running code that is unrelated to GUI on the event thread > > >> may only make your application UI more sluggish and jerky, or even > > >> appearing frozen sometimes. > > >> If you need to execute general-purpose tasks asynchronously, you > > >> have to create an executor service instance (such as a > ForkJoinPool) > > >> yourself and submit your runnables there. > > >> -- > > >> best regards, > > >> Anthony > > >> On 4/1/2013 23:05, Mark Fortner wrote: > > >> In the past, I've found the *Platform#runLater* method to be a > > >> useful way > > >> to run tasks. However, I've noticed that the code that runs my > > >> thread is > > >> not really configurable or accessible. For example, it would > be > > >> nice to be > > >> able to specify and configure a top-level *ThreadPoolExecutor* > > >> to handle my > > >> tasks. Or be able to switch out *Executor* implementations. > > >> I was wondering if there was some reason for implementing > > >> runLater this > > >> way, or if there are any plans to change it in the future? > > >> Cheers, > > >> Mark > > > > > From lehmann at media-interactive.de Tue Apr 2 10:20:21 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 2 Apr 2013 19:20:21 +0200 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: <515B1355.808@media-interactive.de> As far as I understand this, javafx.concurrent.Task exists to simplify communication between a background thread and the FX application thread. It is basically its main or sole purpose. If you don't want this you can still use a plain FutureTask (which it extends). Then of course you are on your own with runLater's sprinkled throughout the code to update progress, message, and GUI status after success/cancel/failure. Werner On 02.04.2013 18:25, Daniel Zwolenski wrote: > Just on the topic, I've had situations where I've wanted Tasks (and > Services) to run in my own threading model (e.g. for unit testing). So I've > had similar wants to Mark's original request (but not directly with > Platform.runLater, though that may also be useful). > > It would be nice if the Task API was really just a way of saying what I > want done at each stage (i.e. doThisStuffBefore, doTaskStuff, > doThisStuffAfter), then I could/should be able to call those methods > directly myself from my own execution framework that may or may not be FX > related or even thread related (in much the same way Runnable doesnt > necessairly have anything to do with Threads). > >> From memory this wasnt (cleanly/easily) achievable because of the tight > interdependency between Tasks and the FX threading model and property > change events, etc. > > A couple of use cases: > > - unit or integration testing, where I want to make sure certain > things/tasks happen in a certain sequence. > - reusing tasks (particularly the background bit of them) outside of JFX > eg. reuse of REST style calls in an Android, Swing, Command line, GWT, or > AJAX based app (Java compiled to JScript). From richard.bair at oracle.com Tue Apr 2 10:42:25 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 2 Apr 2013 10:42:25 -0700 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: <72245ED6-3AB4-460C-B28C-F49421AAD51A@oracle.com> > Just on the topic, I've had situations where I've wanted Tasks (and Services) to run in my own threading model (e.g. for unit testing). So I've had similar wants to Mark's original request (but not directly with Platform.runLater, though that may also be useful). Yes, I faced the same issue when writing unit tests for the concurrent package itself, and promptly cheated. There is a package-private API for calling runLater. In my tests I hook into that so that I don't call the real run later but instead a faked out one for the sake of testing. Also for checking whether I'm on the FX thread. There is an issue around making it possible to call more of the Task / Service from a background thread. Although notifications always happen on the FX thread, you ought to be able to setup listeners and call start / stop etc from any thread (and I should properly make the classes thread safe). I'm hoping to get that done still in Lombard. Richard From richard.bair at oracle.com Tue Apr 2 10:42:39 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 2 Apr 2013 10:42:39 -0700 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: <151CD36F-81B9-4992-AF1B-2E3B775357DE@oracle.com> > Ultimately, the use cases that I'd like to cover cleanly are: > > MyContext.fireEvent(event) // lets you fire an event, and notify all relevant listeners > MyContext.addListener(eventHandler, eventType...) // let a listener listen to a variety of event types > MyContext.removeListener(event, eventType...) // remove the listener from the event types Ye Olde Event Bus! From paulo_torrens at hotmail.com Tue Apr 2 11:12:25 2013 From: paulo_torrens at hotmail.com (Paulo Henrique Torrens) Date: Tue, 2 Apr 2013 18:12:25 +0000 Subject: JavaFX Script Language Reference Message-ID: Hi, Some of the JavaFX Script language constructs and keywords have low or no documentation at all... I'm working on a compiler suite project (http://black.nongnu.org), and I'd like to provide an implementation of the language, specially now that it won't be used anymore. Could someone involved with the language or with knowledge about it help me gather the needed information for the compiler? Thank you! =D From richard.bair at oracle.com Tue Apr 2 11:27:33 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 2 Apr 2013 11:27:33 -0700 Subject: JavaFX Script Language Reference In-Reply-To: References: Message-ID: <07A78A60-1E99-4412-9926-D812512B6ECE@oracle.com> CC'ing Brian Goetz. The compiler was open source (https://kenai.com/projects/openjfx-compiler) and is probably the best resource available. Richard On Apr 2, 2013, at 11:12 AM, Paulo Henrique Torrens wrote: > Hi, > > Some of the JavaFX Script language constructs and keywords have low or no documentation at all... I'm working on a compiler suite project (http://black.nongnu.org), and I'd like to provide an implementation of the language, specially now that it won't be used anymore. > > Could someone involved with the language or with knowledge about it help me gather the needed information for the compiler? > > > Thank you! =D > From richard.bair at oracle.com Tue Apr 2 11:28:56 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 2 Apr 2013 11:28:56 -0700 Subject: JavaFX Script Language Reference In-Reply-To: References: Message-ID: https://kenai.com/projects/openjfx-compiler/sources/presidio-master/show "Presidio" was the most recent (If memory serves!) and so you will want to be looking in this repo. Richard On Apr 2, 2013, at 11:12 AM, Paulo Henrique Torrens wrote: > Hi, > > Some of the JavaFX Script language constructs and keywords have low or no documentation at all... I'm working on a compiler suite project (http://black.nongnu.org), and I'd like to provide an implementation of the language, specially now that it won't be used anymore. > > Could someone involved with the language or with knowledge about it help me gather the needed information for the compiler? > > > Thank you! =D > From chien.yang at oracle.com Tue Apr 2 11:49:33 2013 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 02 Apr 2013 11:49:33 -0700 Subject: JavaFX 3D : TriangleMesh specification questions In-Reply-To: References: <5127294D.50707@oracle.com> Message-ID: <515B283D.2060600@oracle.com> Hi August, I want to give you a heads up. We plan to make this change to the face smoothing group specification. Will this change works better for you or do you have any concern we should consider? https://javafx-jira.kenai.com/browse/RT-29236 Thanks, - Chien On 2/22/2013 6:39 AM, August Lammersdorf, InteractiveMesh wrote: > Thanks Chien! > > - So, a single texCoord (0,0) referenced by all vertices would be > sufficient if no texture is specified in the PhongMaterial !? > > - Flat shading, triangles with all three edges creased, is just an > existing 3D rendering feature. Helpful to visualize face structures or > a red backlight glass ;-), etc.. > > - Wavefront's OBJ files (.obj) provide a smoothing group statement (s > 1, s 2, ..) to collect subsequent faces into the specified group. The > statement 's 0' or 's off' turns off smoothing and all following faces > must be rendered in the flat manner. If no number is reserved for flat > faces, assigning an exclusive number to each flat face should produce > the same result in JavaFX 3D. > > - Even if a 3D file format supports smoothing groups, e.g. 3DS and OBJ > (Collada, VRML2, and X3D don't), its use isn't mandatory. > Alternatively normals or a crease angle might be delivered. Will > JavaFX 3D provide a smoothing group generator utility, as normals are > not implemented yet? Otherwise importer/loader have to include such a > feature. > > August > > Am Freitag, den 22.02.2013, 00:16 +0100 schrieb Chien Yang > : >> Hi August, >> >> Please see my reply inline. >> >> On 2/21/2013 1:41 AM, August Lammersdorf, InteractiveMesh wrote: >>> While converting 3D model importer following questions occurred : >>> >>> - Are texCoords and texCoord indices required even if no texture is >>> applied because NUM_COMPONENTS_PER_FACE is final and has a value of >>> 6 (3 point indices and 3 texCoord indices per face)? >>> >> >> Yes, you will need to for JavaFX 8 since there is only one vertex >> format. We have plan to add more in future releases. >> >>> - Are normals or other vertex attributes planned? >> >> Yes. >> >>> >>> - Is flat shading supported? Does a corresponding smoothing group >>> number exist for the faceSmoothingGroups array (like '0' in *.obj >>> files)? >>> >> >> Flat shading isn't in our plan but we may consider it if you have a >> good 3D use case. Can you elaborate your question on smoothing group >> number? >> >>> - Must smoothing group numbers be consecutive and positive? >>> >> >> No, we didn't specify much about its restriction. It may be good to >> keep this within a small positive range. We may have to tighten later >> as we work out some of the details. >> >> Thanks, >> - Chien >> >>> Thanks, August > From zonski at gmail.com Tue Apr 2 13:57:53 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 2 Apr 2013 15:57:53 -0500 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: Inline responses. On Tue, Apr 2, 2013 at 12:17 PM, Mark Fortner wrote: > Here's the genesis of the original question, this may give you some ideas > for the future. > > I have an app where initially I had a lot of point-to-point event > listening. I created a generic event helper -- basically a mixin with an > executor to let me easily add event support to any class. I then realized > that what I really wanted was to centralize all event management in a > single place within my app. The main reason for this was that it becomes > very easy to lose track of who's listening to what when that code is > scattered throughout a project. So, I created an event manager, added it > to my application context so that I could easily access it from anywhere in > my code, and added the event helpers to the event manager. > I used to use this architecture a lot a while back but found it messy much as you describe. One of the (many) problems is error handling - if something goes wrong it usually goes wrong in a lot of places (like network connection lost) so you suddenly have 20 independent elements all wanting to tell the user that they failed and now you have to put logic in around not showing 20 error dialogs to the user. I ended up settling on an architecture that is much more inline with the way webapps work, i.e. page based, where there is basically a presenter for the page. In this model you really only handle one user request at a time (in general) and one boss (the presenter) handling that. When the user clicks a button, the presenter handles that action and blocks the UI (or the relevant parts of it). When the action is finished, the presenter updates the relevant parts of the UI, which generally is a case of updating the current 'page' or redirecting to a new 'page' (i.e. new presenter). This simplifies the programming model a lot and the EventBus just quietly disappeared from my apps. The user experience was in general actually better, as most people prefer the focused, simplified, single-action style of web pages - less is more. JFX Flow (http://www.zenjava.com/jfx-flow/) is an early incarnation of this approach, but my later architectures are a lot cleaner (I just don't have the time/energy to open source this when basic fundamentals like deployment arent usable and need work first). This is all subjective and a matter of personal style, but for me this has worked really well and I now use things like the 'need' for an EventBus as a bit of an alarm bell for me that I am over complicating the UI for the user and probably should step back and relook at the User experience. Again, subjective, and there are exceptions to every rule, but I haven't hit an app yet that didn't work better with this page based model (just look at web, iPhone, iPad, Android apps). Having said all that sometimes it's nice to have multiple windows onto your data (usually a changing main page area which has a more static side bar or tool window). Instead of using an EventBus for this I have, in some cases, introduced a 'shared model'. The Presenter updates the model, which fires an event, which other components react to. It's sort of a hidden event bus, but putting the focus on 'data was updated' instead of 'action should be carried out' really simplifies a lot of things for me (e.g. error handling is needed in the doAction based evets but not in the dataUpdated based events). > Ultimately, the use cases that I'd like to cover cleanly are: > > MyContext.fireEvent(event) // lets you fire an event, and notify all > relevant listeners > MyContext.addListener(eventHandler, eventType...) // let a listener listen > to a variety of event types > MyContext.removeListener(event, eventType...) // remove the listener from > the event types > As Richard says, ye olde event bus. If you want this it is pretty simple to implement and using Spring's Annotation based autowiring very trivial to get access to. Give me a shout if you need any help on putting one together. There have been calls to have an EventBus in JFX but I'd vote 'no' on this one as there are as many flavours of EventBus as there are developers (e.g a JFX based one could not take advantage of Spring). Probably an open source based library of a simple EventBus would be a good idea to pre-empt it becoming part of the JFX core libraries and locking us into something. Maybe if I have some free time when I get home, or if someone else wants to do it, I'd be happy to input. > I haven't yet figured out a clean way of removing listeners. It would be > nice if components had a life cycle with a "destructor" to let them do this > kind of cleanup. I don't think *finalize()* is the appropriate place to > take care of things like that. Perhaps by making *WeakListeners*, this > problem might go away on it's own and no specific "removeListener" method > is necessary. > Definitely a challenge in the atomic, floating around small window style UI of tradtional desktops as everything has its own life cycle and its hard to know whats going on where. Definitely not a fan of finalize for this (or much of anything) and I'm always a little distrusting of WeakListeners but they potentially may work here. The page based solution side steps this as you pretty much swap in one Page Presenter for another and so have a very clear load/die moments (Page Presenters can be aggregates of other re-usable presenters and the event just perculates down the hierarchy). You decide in your presenter what you should ditch and what you should keep (and it may be a lot more than just event listening, such as ditching cached data, stopping video capture, checking if a save is needed, etc). > > I'm also planning on making the event helpers Spring-configurable so that > it's easy to tune the performance of specific types of events. I have some > events that trigger immediate responses in the GUI, and others that happen > in the background and only require the GUI to update when they complete > (either onSuccess, or onFailure). In order to make the GUI performance > more tuneable, I'll set the executor's thread pool size in the Spring > config. > > When I tried unit testing some of this, the threading got in the way of > JUnit, and I haven't figured out a good alternative for this yet. A > JUnitExecutor might be a useful addition. > I ended up creating my own Task framework and not using Richard's directly so it was JFX agnostic and then could be united tested. Then I wrap my own framework in Richard's Tasks that can call my framework as appropriate. Way too much work and code, especially since some of the stuff I needed was hidden or final in Richard's stuff (hence my previous comment about a framework that was not tied into JFX threading), but it did work in the end. > > The other thing I'd like to be able to do, is inject a component capable > of monitoring either a single event helper, or the event manager in > general. I have some events that are cached, and only persisted to the > database when the user decides that he's finished making adjustments. If I > attempted to persist each small change the user makes, there would be too > much chatter going on and performance would suffer. > > In the page based approach, all edits, etc are related to that page lifecycle and can be queued/cached by that page's presenter until the page is either saved or ditched. As a bonus you can easily add the old 'are you sure you want to leave this page?' prompt, etc. > > I'd like to simply attach a component that would monitor all tasks and > give the user feedback when things have updated properly. If there are any > problems, the progress bars (one per task) would turn red, and the user > could click on a specific bar to get detailed error information. > If you want this model it is also pretty simple to implement. Just have a TaskManager, similar to the EventBus, that Tasks register themselves with. Use Spring's Autowiring to easily pass this task manager around your presenters (or whatever starts your tasks). Then have your toolbar (or whatever) monitor the TaskManager (obersvable list of active tasks) and update the UI accordingly. In the page based approach, the Presenter does this job really. Since it has more fine grained information about the task being executed it can handle it much better. e.g. save failed, then keep the current page and show a popup dialog allowing a retry; but if a background refresh of some data failed to load (e.g. scrolling over a map), maybe you show a placeholder image while you retry to load that bit and only give up if it fails after a certain number of attempts, etc, etc. Basically Presenters are totally aware of everything happening in their context and for me provide a really nice 'controller' for everything that is going on, on that page, resulting in a better UI exeperience. > > In cases where the events are not cached, I'm planning on a creating a > simple generic Task that shows success or failure dialogs when the task > completes. If I take Anthony's suggestion correctly, the *call* method > is the equivalent of Dan's *doTaskStuff*, and the *onSuccess* or * > onFailure* is the equivalent of *doThisStuffAfter. * From the docs, it > sounds like Services are (aside from being confusingly named) reusable > Tasks. > I've nearly always ended up falling back onto Tasks and very rarely use Services. Generally I find there's little to reuse - the Presenter is basically the Task 'factory' so adding a Service within this is, for me at least, a double-up and doesn't give me much of an advantage for the added complexity. A lot of broad stroke responses as this is a hugely complex, and subjective area (the art of architecture!). Just throwing some other ideas your way for you to include in the mix of your architecture. > Hope this helps, > > Mark > > > > On Tue, Apr 2, 2013 at 9:25 AM, Daniel Zwolenski wrote: > >> Just on the topic, I've had situations where I've wanted Tasks (and >> Services) to run in my own threading model (e.g. for unit testing). So >> I've >> had similar wants to Mark's original request (but not directly with >> Platform.runLater, though that may also be useful). >> >> It would be nice if the Task API was really just a way of saying what I >> want done at each stage (i.e. doThisStuffBefore, doTaskStuff, >> doThisStuffAfter), then I could/should be able to call those methods >> directly myself from my own execution framework that may or may not be FX >> related or even thread related (in much the same way Runnable doesnt >> necessairly have anything to do with Threads). >> >> >From memory this wasnt (cleanly/easily) achievable because of the tight >> interdependency between Tasks and the FX threading model and property >> change events, etc. >> >> A couple of use cases: >> >> - unit or integration testing, where I want to make sure certain >> >> things/tasks happen in a certain sequence. >> - reusing tasks (particularly the background bit of them) outside of >> JFX >> >> eg. reuse of REST style calls in an Android, Swing, Command line, GWT, >> or >> AJAX based app (Java compiled to JScript). >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Apr 2, 2013 at 10:27 AM, Richard Bair > >wrote: >> >> > Hi Anthony, he's talking about >> > http://docs.oracle.com/javafx/2/api/javafx/concurrent/Task.html and >> > related API in the javafx.concurrent package. >> > >> > The answer is yes, the onXXX methods of Task are called on the FX >> thread, >> > and as such, you don't need to perform another runLater. There's a large >> > amount of documentation that should (hopefully) clearly detail which >> > threads which methods are called on (and which methods can be called >> from >> > any thread vs. only the FX thread). But in general on Task only the >> "call" >> > method is called on a background thread, and you may call any of the >> > updateXXX methods from the background thread but all other methods are >> on >> > the FX thread. >> > >> > Cheers >> > Richard >> > >> > On Apr 2, 2013, at 6:31 AM, Anthony Petrov >> > wrote: >> > >> > > (Please use "Reply All" when replying to a mailing list. Thank you.) >> > > >> > > I'm not sure what Task you mean here, and how you started its >> execution >> > in the first place. But if I assume you've followed my advice and >> created >> > your own executor service and submitted your task to it, then the >> answer is >> > no. The executor service doesn't know anything about FX or its event >> > thread. I suggest to use runLater() in your onSucceeded and onFailed >> > implementations for your task if you need this code to perform some >> > GUI-related operations. >> > > >> > > -- >> > > best regards, >> > > Anthony >> > > >> > > On 4/2/2013 17:23, Mark Fortner wrote: >> > >> Thanks, Anthony. The light came on after I saw Richard's reply. Are >> the >> > onSucceeded, onFailed methods of Tasks executed on the Application >> thread >> > or do I need to call runLater? >> > >> Mark >> > >> On Apr 2, 2013 1:18 AM, "Anthony Petrov" > > > anthony.petrov at oracle.com>> wrote: >> > >> Platform#runLater is not a general purpose mechanism to execute >> > >> deferred tasks. Its purpose is to schedule execution of runnables >> on >> > >> the event thread in order to perform GUI-related operations. As >> > >> Richard says, the event thread is a native GUI thread. There's >> only >> > >> one such thread per application, hence the design of this >> machinery. >> > >> Note that running code that is unrelated to GUI on the event >> thread >> > >> may only make your application UI more sluggish and jerky, or even >> > >> appearing frozen sometimes. >> > >> If you need to execute general-purpose tasks asynchronously, you >> > >> have to create an executor service instance (such as a >> ForkJoinPool) >> > >> yourself and submit your runnables there. >> > >> -- >> > >> best regards, >> > >> Anthony >> > >> On 4/1/2013 23:05, Mark Fortner wrote: >> > >> In the past, I've found the *Platform#runLater* method to be a >> > >> useful way >> > >> to run tasks. However, I've noticed that the code that runs my >> > >> thread is >> > >> not really configurable or accessible. For example, it would >> be >> > >> nice to be >> > >> able to specify and configure a top-level *ThreadPoolExecutor* >> > >> to handle my >> > >> tasks. Or be able to switch out *Executor* implementations. >> > >> I was wondering if there was some reason for implementing >> > >> runLater this >> > >> way, or if there are any plans to change it in the future? >> > >> Cheers, >> > >> Mark >> > >> > >> > > From phdoerfler at gmail.com Tue Apr 2 18:33:14 2013 From: phdoerfler at gmail.com (=?windows-1252?Q?Philipp_D=F6rfler?=) Date: Wed, 3 Apr 2013 03:33:14 +0200 Subject: FXML plugin for SBT Message-ID: <8CDC8A56-75F1-459D-8076-4B529F4F6CA9@gmail.com> Hi, I've started a SBT plugin [1] (shameless self promotion?) which - based on FXML files - automatically generates controller classes and thus gives you compile time checks, code completion and other goodies. It's an early beta but it's already capable of parsing FXML files using any of the standard nodes (= everything in jfxrt.jar) and emitting beautiful code? (e.g. reasonable white space handling). The project page contains some example output. It is quite similar to SceneBuilder's "Show Sample Controller Skeleton", to the Android IDE and to playframework in that it removes the burden of manually having to create wrapper or controller classes to access your GUI nodes. I hope some of you guys find it interesting. Cheers, ~ Philipp [1] https://bitbucket.org/phdoerfler/sbt-fxml P.S.: I wasn't sure if it's okay to promote an own plugin etc. on this list, but it might be of some use to others. Please let me know if that's not okay for you. From hang.vo at oracle.com Tue Apr 2 20:03:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 03 Apr 2013 03:03:50 +0000 Subject: hg: openjfx/8/controls/rt: CustomColorDialog: Fixed RT-29278 CustomColorDialog incorrectly shows color saturation vs. brightness rectangle for transparent colors Message-ID: <20130403030400.59B1848573@hg.openjdk.java.net> Changeset: 87f740814206 Author: Alexander Kouznetsov Date: 2013-04-02 19:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/87f740814206 CustomColorDialog: Fixed RT-29278 CustomColorDialog incorrectly shows color saturation vs. brightness rectangle for transparent colors ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From milan.kubec at oracle.com Wed Apr 3 01:16:47 2013 From: milan.kubec at oracle.com (Milan Kubec) Date: Wed, 03 Apr 2013 10:16:47 +0200 Subject: Proposal: Deprecate Builders In-Reply-To: <5151AE81.2030202@oracle.com> References: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> <5150AEE5.50908@tbee.org> <94C403B6-AEF1-4924-9DB8-6F885E9B9508@oracle.com> <5151AE81.2030202@oracle.com> Message-ID: <515BE56F.8000003@oracle.com> Hello, I did simple analysis of Builder deprecation impact on FXML, it's sumarized in JIRA issue: https://javafx-jira.kenai.com/browse/RT-29409 Milan Dne 26.3.2013 15:19, Milan Kubec napsal(a): > Hello, > I've inherited FXML codebase from Greg Brown, unfortunatelly I haven't > inherited the history of design decision process and Greg's experience > with declarative UI languages. FXML uses some builders from JavaFX API, > but only those that cannot be substituted by other means of creating > scene graph nodes, i.e. default constructor, valueOf(), fx:factory, etc. > There are also some builders implemented even in FXML package itself for > special cases (i.e. ImageBuilder). > > I will do deeper analysis of what would deprecation of Builders mean to > FXML and post it to the mailing list. > > Milan > > > Dne 25.3.2013 21:53, Richard Bair napsal(a): >> Aren't you on vacation too?? :-) >> >>> I think there are a few things in standard FXML that are fairly dependent on Builders. I cant remember exactly and its hard for me to look up currently (there's no way to browse the OpenJFX source online is there?) but from memory often when I tried to port between FXML and code there were magic methods not available in the code so I assumed builders were the source. >> I know there is some stuff in SceneBuilder (where it tries to determine the default value of a constructor parameter I think), I'm not sure how much of it leaks into FXML. I *think* they are separable for the core libraries but I'm not totally sure. >> >>> e.g. can you create a colour in FXML directly, fonts, images? Stuff like that. I suspect at a minimum some of the tutorials will need updating to not use convenience builder methods. >> These things end up using the "valueOf" methods that were added to the various classes IIRC >> >>> Also, Im again guessing but for FXML to optionally use builders doesn't it need to have a dependency on the builder class? I suppose it could all be reflection based, avoiding the comp?ler dependency, but it would still be quite weird for the core JFX code to be looking for a class that is now effectively third party. >> I think the Builder class itself would stay, but the various builders that we built would be deprecated. >> >>> Who inherited FXML after Greg? >> Milan Kubec! >> >>> Dont get me wrong, Im in the "strip them out camp", but just making sure all the consequences are thought through. Probably any such problems can be fixed but only if done in advance. >> +1 >> >> Thanks >> Richard >> From alexander.zvegintsev at oracle.com Wed Apr 3 01:58:20 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 03 Apr 2013 12:58:20 +0400 Subject: [API Review]: RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes In-Reply-To: <7A30C9E3-917A-42B5-8582-5F2445A06EF6@oracle.com> References: <51373EAF.9050709@oracle.com> <7A30C9E3-917A-42B5-8582-5F2445A06EF6@oracle.com> Message-ID: <515BEF2C.9000202@oracle.com> Hi Richard, Looks like discussion in JIRA almost stopped, so I see this API for FolderChooser as follows: > This property is used to pre-select extension filter for the next > displayed dialog and to get selected extension filter from > dismissed file > dialog. > > When file dialog is invoked the extension filter stored in this > property > will be activated. If value of property is null or not presented in > extensionFilters list the first extension filter will be selected. > > After file dialog is dismissed the value of property is updated to > selected extension filter or to null if the dialog has been > canceled. > > public final ObjectProperty > selectedExtensionFilterProperty() > > public final void setSelectedExtensionFilter(ExtensionFilter > extensionFilter) > > public final ExtensionFilter getSelectedExtensionFilter() Thanks, Alexander. On 03/08/2013 02:10 AM, Richard Bair wrote: > 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 hang.vo at oracle.com Wed Apr 3 02:18:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 03 Apr 2013 09:18:09 +0000 Subject: hg: openjfx/8/graphics/rt: [DOC-ONLY] RT-29082: fixed documentation of Clipboard. Message-ID: <20130403091821.9DB7948584@hg.openjdk.java.net> Changeset: d6c859a4cca1 Author: Pavel Safrata Date: 2013-04-03 10:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d6c859a4cca1 [DOC-ONLY] RT-29082: fixed documentation of Clipboard. ! javafx-ui-common/src/javafx/scene/input/Clipboard.java From lehmann at media-interactive.de Wed Apr 3 02:33:50 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 3 Apr 2013 11:33:50 +0200 Subject: Platform#runLater Question In-Reply-To: References: <515A9443.1020408@oracle.com> <515ADDC3.7080108@oracle.com> Message-ID: <515BF77E.3070601@media-interactive.de> Google's EventBus seems decent enough. http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/eventbus/package-summary.html On 02.04.2013 22:57, Daniel Zwolenski wrote: > Probably an open source based library of a simple EventBus would be a > good idea to pre-empt it becoming part of the JFX core libraries and > locking us into something. From stroshin at yandex.ru Wed Apr 3 03:02:23 2013 From: stroshin at yandex.ru (Sergey Troshin) Date: Wed, 03 Apr 2013 14:02:23 +0400 Subject: JavaFX application packaging & deployment with dependent libraries Message-ID: <515BFE2F.1040605@yandex.ru> Hi all, I have one question on the packaging of a JavaFX application dependent on additional user libraries. My project consists of the command-line tool designed as the standalone JAR package (tool.jar), and of the UI tool created as the JavaFX application (tool-ui.jar). The UI tool uses the command-line tool JAR as the library, and on its own implements the FX application classes and related UI elements. The project wizard of NetBeans 7.3 created for me the FX project with a number of XMLs. When I instruct NetBeans to use tool.jar as the required library for the FX application, it copies the JAR to dist/lib/tool.jar during the build and hard-codes the property "JavaFX-Class-Path: lib/tool.jar" to the FX MANIFEST of ui-tool.jar. That's the problem for me, since I want to make the both tools to be available to the users in the same binary directory, like this bin/ tool.jar ui-tool.jar It should be possible for my users to use either standalone tool.jar, or to use them both over ui-tool.jar launching. However, ui-tool.jar is hard-coded to depend on lib/tool.jar, that cannot be changed anyway over NetBeans. Surely, I can patch/hack the project XMLs files with build rules and targets generated by NB. However, they are pretty messy and complex, can be regenerated by NB anytime. Moreover, seems they do use a service code from the JDK. Placing my JARs as described above leads to ClassNotFoundException when trying to start `java -jar ui-tool.jar', because lib/tools.jar doesn't exist. The workaround is to start the UI tool like this `java -classpath tool.jar:ui-tool.jar com/javafx/main/Main'. That works, but I would prefer to control the generated JavaFX-Class-Path property, or to change the path for dependent libraries in NB. I've seen in NB project the settings "Libraries/Library Folder". It doesn't work for me in the wanted way - just points to the directory where to get the library, but embeds the same property value to the MANIFEST as before. Please kindly advise how can I deal with this issue, Thank you, Sergey Troshin From richard.bair at oracle.com Wed Apr 3 07:08:37 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 3 Apr 2013 07:08:37 -0700 Subject: Proposal: Deprecate Builders In-Reply-To: <515BE56F.8000003@oracle.com> References: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> <5150AEE5.50908@tbee.org> <94C403B6-AEF1-4924-9DB8-6F885E9B9508@oracle.com> <5151AE81.2030202@oracle.com> <515BE56F.8000003@oracle.com> Message-ID: <002EFB90-194E-417B-BBE0-02414AA575B0@oracle.com> Thank you Milan. On Apr 3, 2013, at 1:16 AM, Milan Kubec wrote: > Hello, > I did simple analysis of Builder deprecation impact on FXML, it's > sumarized in JIRA issue: https://javafx-jira.kenai.com/browse/RT-29409 > > Milan > > > Dne 26.3.2013 15:19, Milan Kubec napsal(a): >> Hello, >> I've inherited FXML codebase from Greg Brown, unfortunatelly I haven't >> inherited the history of design decision process and Greg's experience >> with declarative UI languages. FXML uses some builders from JavaFX API, >> but only those that cannot be substituted by other means of creating >> scene graph nodes, i.e. default constructor, valueOf(), fx:factory, etc. >> There are also some builders implemented even in FXML package itself for >> special cases (i.e. ImageBuilder). >> >> I will do deeper analysis of what would deprecation of Builders mean to >> FXML and post it to the mailing list. >> >> Milan >> >> >> Dne 25.3.2013 21:53, Richard Bair napsal(a): >>> Aren't you on vacation too?? :-) >>> >>>> I think there are a few things in standard FXML that are fairly dependent on Builders. I cant remember exactly and its hard for me to look up currently (there's no way to browse the OpenJFX source online is there?) but from memory often when I tried to port between FXML and code there were magic methods not available in the code so I assumed builders were the source. >>> I know there is some stuff in SceneBuilder (where it tries to determine the default value of a constructor parameter I think), I'm not sure how much of it leaks into FXML. I *think* they are separable for the core libraries but I'm not totally sure. >>> >>>> e.g. can you create a colour in FXML directly, fonts, images? Stuff like that. I suspect at a minimum some of the tutorials will need updating to not use convenience builder methods. >>> These things end up using the "valueOf" methods that were added to the various classes IIRC >>> >>>> Also, Im again guessing but for FXML to optionally use builders doesn't it need to have a dependency on the builder class? I suppose it could all be reflection based, avoiding the comp?ler dependency, but it would still be quite weird for the core JFX code to be looking for a class that is now effectively third party. >>> I think the Builder class itself would stay, but the various builders that we built would be deprecated. >>> >>>> Who inherited FXML after Greg? >>> Milan Kubec! >>> >>>> Dont get me wrong, Im in the "strip them out camp", but just making sure all the consequences are thought through. Probably any such problems can be fixed but only if done in advance. >>> +1 >>> >>> Thanks >>> Richard > From hang.vo at oracle.com Wed Apr 3 07:33:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 03 Apr 2013 14:33:12 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28793 [Save dialog] don't show an assert, when file name is typed Message-ID: <20130403143318.3B8624858C@hg.openjdk.java.net> Changeset: 242ede38f3f7 Author: Alexander Zvegintsev Date: 2013-04-03 18:21 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/242ede38f3f7 RT-28793 [Save dialog] don't show an assert, when file name is typed ! glass/glass-lib-windows/src/CommonDialogs_COM.cpp ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java From richard.bair at oracle.com Wed Apr 3 07:52:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 3 Apr 2013 07:52:12 -0700 Subject: [API Review]: RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes In-Reply-To: <515BEF2C.9000202@oracle.com> References: <51373EAF.9050709@oracle.com> <7A30C9E3-917A-42B5-8582-5F2445A06EF6@oracle.com> <515BEF2C.9000202@oracle.com> Message-ID: <49F1D84A-0865-4FC9-B5EB-BA5170A419E1@oracle.com> >> This property is used to pre-select extension filter for the next >> displayed dialog and to get selected extension filter from dismissed file >> dialog. >> >> When file dialog is invoked the extension filter stored in this property >> will be activated. If value of property is null or not presented in >> extensionFilters list the first extension filter will be selected. >> >> After file dialog is dismissed the value of property is updated to >> selected extension filter or to null if the dialog has been canceled. Some suggested changes to the text: This property is used to pre-select the extension filter for the next displayed dialog and to read the user-selected extension filter from the dismissed dialog. When the file dialog is shown, the selectedExtensionFilter will be checked. If the value of selectedExtensionFilter is null or is not contained in the list of selection filters, then the first extension filter in the list of extension filters will be selected instead. Otherwise, the specified selectedExtensionFilter will be activated. After the dialog is dismissed the value of this property is updated to match the user-selected extension filter from the dialog. >> public final ObjectProperty selectedExtensionFilterProperty() >> >> public final void setSelectedExtensionFilter(ExtensionFilter extensionFilter) >> >> public final ExtensionFilter getSelectedExtensionFilter() Also this seems wrong: >> After file dialog is dismissed the value of property is updated to >> selected extension filter or to null if the dialog has been canceled. I don't think we should be clearing the selectedExtensionFilter if the dialog has been cancelled. Thanks! Richard From richard.bair at oracle.com Wed Apr 3 07:54:26 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 3 Apr 2013 07:54:26 -0700 Subject: FXML plugin for SBT In-Reply-To: <8CDC8A56-75F1-459D-8076-4B529F4F6CA9@gmail.com> References: <8CDC8A56-75F1-459D-8076-4B529F4F6CA9@gmail.com> Message-ID: Hi Philipp, When tactfully done (like yours) I don't mind such messages on the mailing list. Of course future discussion about your particular library should continue off-thread, but I think people on the list appreciate the occasional pointer to 3rd party libraries being built up around JavaFX. If it ever grows to get out of hand we might have to setup a separate "announce" list or disallow such posts all together, but for now, I appreciate the occasional pointer to relevant 3rd party projects around JavaFX. Cheers Richard On Apr 2, 2013, at 6:33 PM, Philipp D?rfler wrote: > Hi, > > I've started a SBT plugin [1] (shameless self promotion?) which - based on FXML files - automatically generates controller classes and thus gives you compile time checks, code completion and other goodies. It's an early beta but it's already capable of parsing FXML files using any of the standard nodes (= everything in jfxrt.jar) and emitting beautiful code? (e.g. reasonable white space handling). The project page contains some example output. > It is quite similar to SceneBuilder's "Show Sample Controller Skeleton", to the Android IDE and to playframework in that it removes the burden of manually having to create wrapper or controller classes to access your GUI nodes. > > I hope some of you guys find it interesting. > > Cheers, > ~ Philipp > > [1] https://bitbucket.org/phdoerfler/sbt-fxml > > P.S.: I wasn't sure if it's okay to promote an own plugin etc. on this list, but it might be of some use to others. Please let me know if that's not okay for you. From hang.vo at oracle.com Wed Apr 3 08:03:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 03 Apr 2013 15:03:31 +0000 Subject: hg: openjfx/8/controls/rt: 28 new changesets Message-ID: <20130403150458.CA47C4858E@hg.openjdk.java.net> Changeset: b5866e91dc0b Author: hudson Date: 2013-03-28 15:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b5866e91dc0b Added tag 8.0-b83 for changeset b1da897ab209 ! .hgtags Changeset: efcc8dfcca37 Author: Richard Bair Date: 2013-03-26 18:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/efcc8dfcca37 Fixed missing javadoc images & resources for Gradle. Also switched usage of BINARY_STUB because I found then when supplying it from the command line it wasn't working as expected (a mystery here to be followed up on). Added code to skip any inner classes when generating headers that are Foo$1 style anonymous classes. Fixed the individual javadoc runs (mistakenly was trying to execute java instead of javadoc). Removed all empty dirs after javafx generation. Copied javadoc doc-files into javadocs (gradle lacked support. Oh my!). Implemented Css2Bin converter for caspian and other built in css files. Fixed list of things to omit when building on something other than windows. I don't have this completely correct and have more work to do here. Made sdk depend on javadoc generation. ! build.gradle ! generator.gradle Changeset: 7034e216b49f Author: Richard Bair Date: 2013-03-26 18:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7034e216b49f Gradle: Moved javadoc-to-sdk logic to build.gradle ! build.gradle Changeset: 614832776c99 Author: Jan Valenta Date: 2013-03-26 14:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/614832776c99 removing trailing spaces ! deploy/packager/src/com/sun/javafx/tools/packager/Main.java Changeset: 1a007f146395 Author: Jan Valenta Date: 2013-03-27 15:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1a007f146395 RT-28925: callbacks usage in packager depends on ant ! deploy/packager/src/com/sun/javafx/tools/packager/DeployParams.java + deploy/packager/src/com/sun/javafx/tools/packager/JSCallback.java ! deploy/packager/src/com/sun/javafx/tools/packager/Main.java ! deploy/packager/src/com/sun/javafx/tools/packager/PackagerLib.java Changeset: 831e55bdf773 Author: Jan Valenta Date: 2013-03-27 15:32 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/831e55bdf773 merge Changeset: eee50af9e4d7 Author: jgodinez Date: 2013-03-27 11:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/eee50af9e4d7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 61e62cb173b6 Author: Yao Wang Date: 2013-03-27 14:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/61e62cb173b6 RT-28625: Shape3D should have a default material if it doesn't have a material set to it ! javafx-ui-common/src/javafx/scene/shape/Shape3D.java Changeset: 5b5682fbcd8a Author: Yao Wang Date: 2013-03-28 11:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5b5682fbcd8a add StubPhongMaterial for smoke test + test-stub-toolkit/src/com/sun/javafx/pgstub/StubPhongMaterial.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 3f73888525a3 Author: dmasada Date: 2013-03-28 18:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3f73888525a3 RT-29282 Ensemble8: Don't use group for coloful circles ! apps/samples/Ensemble8/src/samples/ensemble/samples/graphics/colorfulcircles/ColorfulCirclesApp.java Changeset: 74e044617e96 Author: Alexander Kouznetsov Date: 2013-03-28 18:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74e044617e96 Ensemble8: Performance optimizations ! apps/samples/Ensemble8/src/app/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesCaspian.css + apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesCaspianDesktop.css ! apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesCommon.css + apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesCommonDesktop.css ! apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesIOS.css + apps/samples/Ensemble8/src/app/ensemble/EnsembleStylesIOSDesktop.css ! apps/samples/Ensemble8/src/app/ensemble/HomePage.java ! apps/samples/Ensemble8/src/app/ensemble/SampleInfo.java + apps/samples/Ensemble8/src/app/ensemble/ScrollEventSynthesizer.java Changeset: 8105bb179397 Author: ant Date: 2013-03-29 15:06 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8105bb179397 RT-27887: introduce a node to embed Swing into JavaFX Reviewed-by: art, kcr ! javafx-embed-swing/build-closed.xml ! javafx-embed-swing/build-common.xml ! javafx-embed-swing/src/javafx/embed/swing/SwingEvents.java + javafx-embed-swing/src/javafx/embed/swing/SwingNode.java + javafx-sg-common/src/com/sun/javafx/sg/PGExternalNode.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGExternalNode.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubExternalNode.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 3a2a2a75190e Author: Artem Ananiev Date: 2013-03-29 05:19 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3a2a2a75190e R-29259: Get rid of DesktopToolkit Reviewed-by: Kevin Rushforth + javafx-ui-common/src/com/sun/javafx/tk/AppletWindow.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassAppletWindow.java + javafx-ui-quantum/src/com/sun/javafx/tk/quantum/MasterTimer.java + javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PerformanceTrackerHelper.java + javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PerformanceTrackerImpl.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: cd1c891fe695 Author: Yao Wang Date: 2013-03-29 10:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cd1c891fe695 RT-29251 PhongMaterial.setSpecularMap: a typo bug ! javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java ! javafx-ui-common/test/unit/javafx/scene/paint/PhongMaterialTest.java + javafx-ui-common/test/unit/javafx/scene/paint/javafx.png Changeset: 28fd91194a80 Author: dmasada Date: 2013-03-29 17:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/28fd91194a80 RT-28609 Task sample doesn't fit the page ! apps/samples/Ensemble8/src/samples/ensemble/samples/concurrency/task/TaskApp.java Changeset: 310abf468b7b Author: Artem Ananiev Date: 2013-04-01 05:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/310abf468b7b RT-29312: Quantum cleanup: get rid of PrismPen Reviewed-by: David Hill, Kevin Rushforth ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/EmbeddedPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/EmbeddedScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/OverlayWarning.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/PrismPen.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/UploadingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/ViewPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/ViewScene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/WindowStage.java Changeset: 907c01d3625a Author: Felipe Heidrich Date: 2013-04-01 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/907c01d3625a [Eclipse only] fix .classpath to exclude SwingNode as it requires Java8 ! .classpath Changeset: 13a4a4ba90d1 Author: dmasada Date: 2013-04-01 11:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/13a4a4ba90d1 RT-29379 Ensemble8: ServiceApp doesn't fit smaller pages ! apps/samples/Ensemble8/src/samples/ensemble/samples/concurrency/service/ServiceApp.java Changeset: 68122b30b843 Author: Yao Wang Date: 2013-04-01 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/68122b30b843 RT-28214: Disallow Camera belonging to one scene to be set as the camera of another scene ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SubScene.java ! javafx-ui-common/test/unit/javafx/scene/SceneTest.java + javafx-ui-common/test/unit/javafx/scene/SubSceneTest.java Changeset: c83e4d489d14 Author: Yao Wang Date: 2013-04-01 20:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c83e4d489d14 fix camera property for RT-28214 Disallow Camera belonging to one scene to be set as the camera of another scene ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SubScene.java Changeset: 4ba1d26b27a8 Author: Martin Sladecek Date: 2013-04-02 10:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4ba1d26b27a8 RT-29301 Clarify Stage.resizableProperty().bindBidirectional() ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: 6a2d0bf083cd Author: Pavel Safrata Date: 2013-04-02 12:56 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6a2d0bf083cd RT-29401: fixed click event's scene coordinates in 3D. ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 584ac4f66a55 Author: Pavel Safrata Date: 2013-04-02 13:05 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/584ac4f66a55 Improved 3D picking tests to use real scenegraph-computed pick ray. Removed temporary workaround in perspective camera. ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/test/unit/javafx/scene/Mouse3DTest.java Changeset: 87ebb6d34a00 Author: Eva Krejcirova Date: 2013-04-02 13:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/87ebb6d34a00 [DOC-ONLY] RT-29043: A typo in the BorderPane class description ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java Changeset: 3229601bda3f Author: Martin Sladecek Date: 2013-04-02 14:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3229601bda3f RT-16882 Changing BorderPane contraints (adding and removing same component) causes component to disappear ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/BorderPaneTest.java Changeset: fcef89ba5594 Author: Martin Sladecek Date: 2013-04-02 14:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fcef89ba5594 merge ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java Changeset: bc233d4feaac Author: Yao Wang Date: 2013-04-02 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bc233d4feaac Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PrismPen.java Changeset: 793ae0cbf60a Author: David Grieve Date: 2013-04-03 10:55 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/793ae0cbf60a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From alexander.zvegintsev at oracle.com Wed Apr 3 08:55:47 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 03 Apr 2013 19:55:47 +0400 Subject: [API Review]: RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes In-Reply-To: <49F1D84A-0865-4FC9-B5EB-BA5170A419E1@oracle.com> References: <51373EAF.9050709@oracle.com> <7A30C9E3-917A-42B5-8582-5F2445A06EF6@oracle.com> <515BEF2C.9000202@oracle.com> <49F1D84A-0865-4FC9-B5EB-BA5170A419E1@oracle.com> Message-ID: <515C5103.7030503@oracle.com> Looks great, thanks for the corrections. I have only one minor comment: > in the list of selection filters Should I read this as extension filters? > I don't think we should be clearing the selectedExtensionFilter if the dialog has been cancelled. It was intended as extra check for cancelled dialog, but you are right, it's unnecessary. Thanks, Alexander. On 04/03/2013 06:52 PM, Richard Bair wrote: >>> This property is used to pre-select extension filter for the next >>> displayed dialog and to get selected extension filter from dismissed file >>> dialog. >>> >>> When file dialog is invoked the extension filter stored in this property >>> will be activated. If value of property is null or not presented in >>> extensionFilters list the first extension filter will be selected. >>> >>> After file dialog is dismissed the value of property is updated to >>> selected extension filter or to null if the dialog has been canceled. > Some suggested changes to the text: > > This property is used to pre-select the extension filter for the next displayed > dialog and to read the user-selected extension filter from the dismissed dialog. > > When the file dialog is shown, the selectedExtensionFilter will be checked. > If the value of selectedExtensionFilter is null or is not contained in the list > of selection filters, then the first extension filter in the list of extension filters > will be selected instead. Otherwise, the specified selectedExtensionFilter will > be activated. > > After the dialog is dismissed the value of this property is updated to match the > user-selected extension filter from the dialog. > >>> public final ObjectProperty selectedExtensionFilterProperty() >>> >>> public final void setSelectedExtensionFilter(ExtensionFilter extensionFilter) >>> >>> public final ExtensionFilter getSelectedExtensionFilter() > Also this seems wrong: > >>> After file dialog is dismissed the value of property is updated to >>> selected extension filter or to null if the dialog has been canceled. > I don't think we should be clearing the selectedExtensionFilter if the dialog has been cancelled. > > Thanks! > Richard From richard.bair at oracle.com Wed Apr 3 09:14:33 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 3 Apr 2013 09:14:33 -0700 Subject: [API Review]: RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes In-Reply-To: <515C5103.7030503@oracle.com> References: <51373EAF.9050709@oracle.com> <7A30C9E3-917A-42B5-8582-5F2445A06EF6@oracle.com> <515BEF2C.9000202@oracle.com> <49F1D84A-0865-4FC9-B5EB-BA5170A419E1@oracle.com> <515C5103.7030503@oracle.com> Message-ID: > I have only one minor comment: >> in the list of selection filters > Should I read this as extension filters? Yes thanks! >> I don't think we should be clearing the selectedExtensionFilter if the dialog has been cancelled. > It was intended as extra check for cancelled dialog, but you are right, it's unnecessary. Good, lets fix that and then I think we're good to go. Richard From John_Smith at symantec.com Wed Apr 3 13:15:06 2013 From: John_Smith at symantec.com (John Smith) Date: Wed, 3 Apr 2013 13:15:06 -0700 Subject: JavaFX application packaging & deployment with dependent libraries In-Reply-To: <515BFE2F.1040605@yandex.ru> References: <515BFE2F.1040605@yandex.ru> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221678F7925F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> I understand that you don't want to hack the NetBeans build directly for this, however, the quickest solution might be to: replace the following line in your /nbproject/jfx-impl.xml file: with The above solution would be fragile in that a NetBeans version upgrade would likely overwrite your hack (also I haven't tried it myself so you might need to make a few more build script hacks to get everything working). ----------- The defaulting of the lib/ prefix to the dependent classpaths would seem to be a NetBeans implementation specific thing, so if you wish more flexibility there, you should file an issue against the NetBeans project: https://netbeans.org/community/issues.html ----------- In the build.xml file for your project which has been automatically generated by NetBeans, there is documentation for user added callback stubs for the netbeans build process (-post-jfx-jar: and -post-jfx-deploy:), possibly by providing these callback stubs in the build.xml, you could post manipulate the manifest in the created jar file to achieve the settings you require. Because you will be making use of documented user supplied callbacks, NetBeans should continue to support whatever you put in there going forward so that your project won't break if NetBeans generates new project build files (as it seems to do with every NetBeans version upgrade). ----------- The solutions below are significantly more work, so you may not wish to undertake them. I believe that if you just use the standard JavaFX packaging tools which come with JavaFX rather than using the NetBeans autogenerated build project files, you will be able to get the flexibility you want as I don't think these tools default a lib/ directory prefix for dependent jars. You can use either the JavaFX Ant Tasks: http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference001.htm Or the javafxpackager tool: http://docs.oracle.com/javafx/2/deployment/packager.htm There is also a JavaFX maven and gradle plugins you could try to see if they package how you want (if you are open to using a different build system): https://github.com/zonski/javafx-maven-plugin https://bitbucket.org/shemnon/javafx-gradle Some advantages of the alternate tools approaches are that your build is not NetBeans specific, your build won't be broken by a NetBeans version upgrade and your build can be used easily in other contexts (though you do lose a lot of the simplicity of auto-generating build scripts just by clicking GUI options). -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Sergey Troshin Sent: Wednesday, April 03, 2013 3:02 AM To: openjfx-dev at openjdk.java.net Subject: JavaFX application packaging & deployment with dependent libraries Hi all, I have one question on the packaging of a JavaFX application dependent on additional user libraries. My project consists of the command-line tool designed as the standalone JAR package (tool.jar), and of the UI tool created as the JavaFX application (tool-ui.jar). The UI tool uses the command-line tool JAR as the library, and on its own implements the FX application classes and related UI elements. The project wizard of NetBeans 7.3 created for me the FX project with a number of XMLs. When I instruct NetBeans to use tool.jar as the required library for the FX application, it copies the JAR to dist/lib/tool.jar during the build and hard-codes the property "JavaFX-Class-Path: lib/tool.jar" to the FX MANIFEST of ui-tool.jar. That's the problem for me, since I want to make the both tools to be available to the users in the same binary directory, like this bin/ tool.jar ui-tool.jar It should be possible for my users to use either standalone tool.jar, or to use them both over ui-tool.jar launching. However, ui-tool.jar is hard-coded to depend on lib/tool.jar, that cannot be changed anyway over NetBeans. Surely, I can patch/hack the project XMLs files with build rules and targets generated by NB. However, they are pretty messy and complex, can be regenerated by NB anytime. Moreover, seems they do use a service code from the JDK. Placing my JARs as described above leads to ClassNotFoundException when trying to start `java -jar ui-tool.jar', because lib/tools.jar doesn't exist. The workaround is to start the UI tool like this `java -classpath tool.jar:ui-tool.jar com/javafx/main/Main'. That works, but I would prefer to control the generated JavaFX-Class-Path property, or to change the path for dependent libraries in NB. I've seen in NB project the settings "Libraries/Library Folder". It doesn't work for me in the wanted way - just points to the directory where to get the library, but embeds the same property value to the MANIFEST as before. Please kindly advise how can I deal with this issue, Thank you, Sergey Troshin From fbrunnerlist at gmx.ch Wed Apr 3 14:30:37 2013 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Wed, 03 Apr 2013 23:30:37 +0200 Subject: Platform#runLater Question In-Reply-To: References: Message-ID: <4029382.fXQ6hNesnM@shire> Hi Mark, I'm not sure if it fits your needs exactly, but I've implemented something like this for Drombler FX. The JavaFX agnostic interface is here: http://sourceforge.net/p/drombler/drombler-acp/ci/f2c9da0d549677805fbcb3c5250e139a5d8925fb/tree/drombler-acp-core-application/src/main/java/org/drombler/acp/core/application/ApplicationExecutorProvider.java The JavaFX specific implementation class and helpers are here: http://sourceforge.net/p/drombler/drombler-fx/ci/9639d43d9c015b15f770df1b92c716c8d86def46/tree/drombler-fx-core-application/src/main/java/org/drombler/fx/core/application/impl/FXApplicationExecutorProvider.java http://sourceforge.net/p/drombler/drombler-fx/ci/9639d43d9c015b15f770df1b92c716c8d86def46/tree/drombler-fx-core-application/src/main/java/org/drombler/fx/core/application/impl/FXApplicationExecutor.java http://sourceforge.net/p/drombler/drombler-fx/ci/9639d43d9c015b15f770df1b92c716c8d86def46/tree/drombler-fx-core-commons/src/main/java/org/drombler/fx/core/commons/fx/application/PlatformUtils.java So instead of calling Platform.runLater() directly, I inject an implementation of ApplicationExecuterProvider and call ApplicationExecuterProvider.getApplicationExecutor().execute(). Here is an example how you can use it with OSGi Declarative Services (using the Apache Felix SCR annotations): http://sourceforge.net/p/drombler/drombler-acp/ci/f2c9da0d549677805fbcb3c5250e139a5d8925fb/tree/drombler-acp-core-action-spi/src/main/java/org/drombler/acp/core/action/spi/impl/ToolBarsHandler.java#l41 (The reason I'm doing this is because Drombler ACP, the base framework of Drombler FX, is GUI-toolkit agnostic and thus doesn't know anything about JavaFX.) -Florian Am Montag, 1. April 2013, 12.05:03 schrieb Mark Fortner: > In the past, I've found the *Platform#runLater* method to be a useful way > to run tasks. However, I've noticed that the code that runs my thread is > not really configurable or accessible. For example, it would be nice to be > able to specify and configure a top-level *ThreadPoolExecutor* to handle my > tasks. Or be able to switch out *Executor* implementations. > > I was wondering if there was some reason for implementing runLater this > way, or if there are any plans to change it in the future? > > > Cheers, > > Mark From hang.vo at oracle.com Wed Apr 3 15:17:32 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 03 Apr 2013 22:17:32 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130403221748.020FF485A6@hg.openjdk.java.net> Changeset: 8ee0ab8e0b22 Author: Alexander Kouznetsov Date: 2013-04-03 15:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8ee0ab8e0b22 CustomColorDialog: Fixed RT-29429 CustomColorDialog has not default and no cancel button ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: 5986c8a63341 Author: Alexander Kouznetsov Date: 2013-04-03 15:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5986c8a63341 CustomColorDialog: Fixed RT-29428 CustomColorDialog: problems with mouse ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java From hjohn at xs4all.nl Wed Apr 3 16:34:15 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 04 Apr 2013 01:34:15 +0200 Subject: Proposal: Deprecate Builders In-Reply-To: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> References: <6E54F3F1-CB0B-48D0-A18D-3B36938BC501@oracle.com> Message-ID: <515CBC77.2030308@xs4all.nl> I don't use Builders, but they exist in my opinion because of a lack in C style languages to access objects through a (possibly nested) hidden reference. The second example shows the problem that always occurs when building object structures: > Group g = new Group(gg -> { > gg.getChildren().addAll(new Button(b -> { > b.setText("Hello"); > }); > }); What names should the variables have? When constructing a deeply nested set of objects I rapidly run out of good names for my variables. Giving them long descriptive names is incredibly counter-productive when you have to call several methods on them (ie, centerPanelWestBorderListGroup.setText() gets cumbersome). Inevitable we end up with a mess of variables g1, g2, g3, button1, button2, etc... This exactly what Builders prevent and also what the subclass-initializer pattern prevents. These patterns allow for code to be moved around without having to worry about variable naming conflicts -- or having to worry about keeping variable names updated (let's add another panel around the centerPanel...) I'm curious however what generic problem you are running into. Long ago I wrote code that solved the casting and generics problems with the with-pattern. It basically looked like this: public final Button extends AbstractButton