From randahl at rockit.dk Mon Oct 1 04:00:12 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 1 Oct 2012 13:00:12 +0200 Subject: Does JavaFX have a mouse transparency problem? Message-ID: I have two panes of components that I show directly on top of each other. In the bottom pane I have input controls like text fields and in the top pane I have floating stuff like tool tips that are shown on top of (in front of) the input controls. To make this work I have set mouseTransparent to true for the top pane, so any clicks on that pane passes through to the input controls below (behind it). This works like a charm except I now want to make the tooltips clickable. It seems I cannot do that, since when the top pane is made mouse transparent all children of that pane are mouse transparent too, meaning my tooltips are mouse transparent. I am thinking there's got to be a way I can work around this, but so far my experiments have not come to fruition. Is it possible to have a transparent parent with non-transparent children, or is this a missing feature, or is there some other, better way? Randahl From randahl at rockit.dk Mon Oct 1 04:53:31 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 1 Oct 2012 13:53:31 +0200 Subject: Does JavaFX have a mouse transparency problem? In-Reply-To: <9013102366680535891@unknownmsgid> References: <9013102366680535891@unknownmsgid> Message-ID: Wonderful? Thanks Scott! It works! Randahl On Oct 1, 2012, at 13:23 , Scott Palmer wrote: > You could try using a Group for the top pane and turning off the mouse > transparency. > > Scott > > On 2012-10-01, at 7:01 AM, Randahl Fink Isaksen wrote: > >> I have two panes of components that I show directly on top of each other. In the bottom pane I have input controls like text fields and in the top pane I have floating stuff like tool tips that are shown on top of (in front of) the input controls. >> >> To make this work I have set mouseTransparent to true for the top pane, so any clicks on that pane passes through to the input controls below (behind it). This works like a charm except I now want to make the tooltips clickable. It seems I cannot do that, since when the top pane is made mouse transparent all children of that pane are mouse transparent too, meaning my tooltips are mouse transparent. >> >> I am thinking there's got to be a way I can work around this, but so far my experiments have not come to fruition. >> >> Is it possible to have a transparent parent with non-transparent children, or is this a missing feature, or is there some other, better way? >> >> Randahl From richard.bair at oracle.com Mon Oct 1 05:41:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 1 Oct 2012 05:41:39 -0700 Subject: Does JavaFX have a mouse transparency problem? In-Reply-To: References: Message-ID: <0158C50E-8122-40E2-94AF-BE2EC8CEC102@oracle.com> I believe pickInBounds of the region is what you're looking for? In the case that isn't it, subclass your top pane and override contains to only answer true based on the children. Cheers Richard On Oct 1, 2012, at 4:00 AM, Randahl Fink Isaksen wrote: > I have two panes of components that I show directly on top of each other. In the bottom pane I have input controls like text fields and in the top pane I have floating stuff like tool tips that are shown on top of (in front of) the input controls. > > To make this work I have set mouseTransparent to true for the top pane, so any clicks on that pane passes through to the input controls below (behind it). This works like a charm except I now want to make the tooltips clickable. It seems I cannot do that, since when the top pane is made mouse transparent all children of that pane are mouse transparent too, meaning my tooltips are mouse transparent. > > I am thinking there's got to be a way I can work around this, but so far my experiments have not come to fruition. > > Is it possible to have a transparent parent with non-transparent children, or is this a missing feature, or is there some other, better way? > > Randahl From hang.vo at oracle.com Tue Oct 2 09:18:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Oct 2012 16:18:27 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121002161832.4326647165@hg.openjdk.java.net> Changeset: 7c436f8509c8 Author: hudson Date: 2012-09-27 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7c436f8509c8 Added tag 8.0-b58 for changeset 174647284655 ! .hgtags Changeset: eac2df24a6c0 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-02 09:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eac2df24a6c0 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt From hang.vo at oracle.com Tue Oct 2 12:18:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 02 Oct 2012 19:18:32 +0000 Subject: hg: openjfx/8/controls/rt: 7 new changesets Message-ID: <20121002191841.A2D2E47168@hg.openjdk.java.net> Changeset: 7c436f8509c8 Author: hudson Date: 2012-09-27 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7c436f8509c8 Added tag 8.0-b58 for changeset 174647284655 ! .hgtags Changeset: a30e7be8621e Author: Anthony Petrov Date: 2012-09-26 17:38 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a30e7be8621e RT-24632: JFXPanel ComboBox item list not moved/closed ! javafx-ui-common/src/com/sun/javafx/embed/EmbeddedStageInterface.java ! javafx-ui-common/src/com/sun/javafx/embed/HostInterface.java Changeset: e5267f8c80af Author: kcr Date: 2012-09-26 17:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e5267f8c80af Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 7ee6a11abbbf Author: Felipe Heidrich Date: 2012-09-28 14:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7ee6a11abbbf fix .classpath ! .classpath Changeset: 08067ae69c0c Author: snorthov Date: 2012-09-28 17:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/08067ae69c0c fix .classpath ! .classpath Changeset: eac2df24a6c0 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-02 09:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/eac2df24a6c0 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt Changeset: da3f3de73066 Author: leifs Date: 2012-10-02 12:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/da3f3de73066 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt From hang.vo at oracle.com Wed Oct 3 09:18:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 03 Oct 2012 16:18:51 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121003161856.20A0F47179@hg.openjdk.java.net> Changeset: 07c0a2cbf8f3 Author: leifs Date: 2012-09-27 15:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/07c0a2cbf8f3 Fixed RT-25267: [Label] Ellipsis is not working ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: da3f3de73066 Author: leifs Date: 2012-10-02 12:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/da3f3de73066 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt From tbee at tbee.org Thu Oct 4 05:51:56 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 04 Oct 2012 14:51:56 +0200 Subject: Layout Message-ID: <506D866C.1000204@tbee.org> Not seeing my post from this morning appear, so I'm reposting but without the attachment this time. I've posted a thread on the JavaFX forums with problems I run into when writing a Google Calendar style control. I could use advice on how to best do this nested Panes layout. https://forums.oracle.com/forums/thread.jspa?threadID=2447739&stqc=true Tom From randahl at rockit.dk Thu Oct 4 06:09:13 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 4 Oct 2012 15:09:13 +0200 Subject: Layout In-Reply-To: <506D866C.1000204@tbee.org> References: <506D866C.1000204@tbee.org> Message-ID: Tom, the problem is, extending Pane directly is a lot of work. Pane does not implement a layout strategy and therefore does not implement computePrefWidth and computePrefHeight; consequently if you just nest a lot of Panes inside one another, none knows anything about size. So, instead of extending Pane directly I have found it much more useful to extend one of the subclasses which has a layout strategy such as BorderPane, GridPane, etc. And up until this point I have not yet seen a layout that could not be implemented as an (arguably bloated) tree of subclasses of Pane. Once you extend, say, BorderPane, invoking setPrefSize(double, double) *does* have an effect. Yours Randahl In short: Either invoke setSize and ensure On Oct 4, 2012, at 14:51 , Tom Eugelink wrote: > Not seeing my post from this morning appear, so I'm reposting but without the attachment this time. > > I've posted a thread on the JavaFX forums with problems I run into when writing a Google Calendar style control. I could use advice on how to best do this nested Panes layout. > > https://forums.oracle.com/forums/thread.jspa?threadID=2447739&stqc=true > > Tom From tbee at tbee.org Thu Oct 4 06:30:59 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 04 Oct 2012 15:30:59 +0200 Subject: Layout In-Reply-To: References: <506D866C.1000204@tbee.org> Message-ID: <506D8F93.2030007@tbee.org> But extending one of these Panes would no longer allow me to position the children myself? On 2012-10-04 15:09, Randahl Fink Isaksen wrote: > Tom, the problem is, extending Pane directly is a lot of work. Pane does not implement a layout strategy and therefore does not implement computePrefWidth and computePrefHeight; consequently if you just nest a lot of Panes inside one another, none knows anything about size. > > So, instead of extending Pane directly I have found it much more useful to extend one of the subclasses which has a layout strategy such as BorderPane, GridPane, etc. And up until this point I have not yet seen a layout that could not be implemented as an (arguably bloated) tree of subclasses of Pane. > > Once you extend, say, BorderPane, invoking setPrefSize(double, double) *does* have an effect. > > Yours > > Randahl > From randahl at rockit.dk Thu Oct 4 06:35:53 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 4 Oct 2012 15:35:53 +0200 Subject: Layout In-Reply-To: <506D866C.1000204@tbee.org> References: <506D866C.1000204@tbee.org> Message-ID: But it would! Only, instead of writing a lot of setLayoutX calls you write a lot of BorderPane.setMargin and BorderPane.setAlignment, etc. The beauty of this is your layout becomes independent of font sizes (which may be OS specific). R. On Oct 4, 2012, at 14:51 , Tom Eugelink wrote: > Not seeing my post from this morning appear, so I'm reposting but without the attachment this time. > > I've posted a thread on the JavaFX forums with problems I run into when writing a Google Calendar style control. I could use advice on how to best do this nested Panes layout. > > https://forums.oracle.com/forums/thread.jspa?threadID=2447739&stqc=true > > Tom From tbee at tbee.org Thu Oct 4 06:44:26 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 04 Oct 2012 15:44:26 +0200 Subject: Layout In-Reply-To: References: <506D866C.1000204@tbee.org> Message-ID: <506D92BA.7040304@tbee.org> I need to research this, but my initial reaction is something along the lines of "YIKES!!!". And "that is not how this should be working?". But I was already planning on creating my own "AbsolutePane" which would have a nice setXYWH method. How it is implemented internally is less relevant. Thanks for the suggestion! Tom On 2012-10-04 15:35, Randahl Fink Isaksen wrote: > But it would! Only, instead of writing a lot of setLayoutX calls you write a lot of BorderPane.setMargin and BorderPane.setAlignment, etc. > > The beauty of this is your layout becomes independent of font sizes (which may be OS specific). > > R. > From randahl at rockit.dk Thu Oct 4 06:53:35 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 4 Oct 2012 15:53:35 +0200 Subject: Layout In-Reply-To: <506D866C.1000204@tbee.org> References: <506D866C.1000204@tbee.org> Message-ID: <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> I strongly recommend you avoid absolute positioning. In most applications you never know anything about the size of the end user's screen and the fonts used. Dynamic layouts like the ones JavaFX has can adapt to individual user preferences, absolute layouts cannot. R. On Oct 4, 2012, at 14:51 , Tom Eugelink wrote: > Not seeing my post from this morning appear, so I'm reposting but without the attachment this time. > > I've posted a thread on the JavaFX forums with problems I run into when writing a Google Calendar style control. I could use advice on how to best do this nested Panes layout. > > https://forums.oracle.com/forums/thread.jspa?threadID=2447739&stqc=true > > Tom From randahl at rockit.dk Thu Oct 4 07:18:30 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 4 Oct 2012 16:18:30 +0200 Subject: Layout In-Reply-To: <506D97AB.4020005@tbee.org> References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> Message-ID: <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> Looks nice, Tom. But trust me: You could make exactly the same by using an adaptive layout approach (nested subclasses of Pane), and then your layout would work smoothly when resizing the window or changing the fonts or other aspects of the CSS styling of the calendar (padding, etc.). A GridPane would probably be a good place to start ? it supports the row spanning you need. Yours Randahl On Oct 4, 2012, at 16:05 , Tom Eugelink wrote: > Have you seen the screenshot? > > http://www.softworks.nl/stuff/agenda.png > > No can do without absolute positioning. But it's dynamic; it uses things like new Text("X").prefWidth(0). > > > On 2012-10-04 15:53, Randahl Fink Isaksen wrote: >> I strongly recommend you avoid absolute positioning. In most applications you never know anything about the size of the end user's screen and the fonts used. Dynamic layouts like the ones JavaFX has can adapt to individual user preferences, absolute layouts cannot. >> >> R. >> >> >> On Oct 4, 2012, at 14:51 , Tom Eugelink wrote: >> >>> Not seeing my post from this morning appear, so I'm reposting but without the attachment this time. >>> >>> I've posted a thread on the JavaFX forums with problems I run into when writing a Google Calendar style control. I could use advice on how to best do this nested Panes layout. >>> >>> https://forums.oracle.com/forums/thread.jspa?threadID=2447739&stqc=true >>> >>> Tom > From tbee at tbee.org Thu Oct 4 07:27:02 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 04 Oct 2012 16:27:02 +0200 Subject: Layout In-Reply-To: <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> Message-ID: <506D9CB6.2050108@tbee.org> I can see how the hours / week / day would fit into a GridPane. But the overlapping appointments? And syncing the day-headers width exactly with the days in the scrollpane... #indoubt On 2012-10-04 16:18, Randahl Fink Isaksen wrote: > Looks nice, Tom. But trust me: You could make exactly the same by using an adaptive layout approach (nested subclasses of Pane), and then your layout would work smoothly when resizing the window or changing the fonts or other aspects of the CSS styling of the calendar (padding, etc.). > > A GridPane would probably be a good place to start ? it supports the row spanning you need. > > Yours > > Randahl > From tbee at tbee.org Thu Oct 4 13:05:57 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 04 Oct 2012 22:05:57 +0200 Subject: Layout In-Reply-To: <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> Message-ID: <506DEC25.6010703@tbee.org> Interesting; calling prefWidth(w) & prefHeight(h) on a Pane does not do a thing, but using setPrefSize(w,h) works fine. Tom From hang.vo at oracle.com Thu Oct 4 14:53:59 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 04 Oct 2012 21:53:59 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121004215405.528D6471AD@hg.openjdk.java.net> Changeset: c15a91781139 Author: David Grieve Date: 2012-10-04 17:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c15a91781139 RT-25118: replace code removed by bad merge, and other optimizations ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Match.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: bedd78e543a0 Author: David Grieve Date: 2012-10-04 17:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bedd78e543a0 RT-25133: strip off package when comparing class name in css selector ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-controls/test/javafx/scene/control/PopupControlTest.java From hang.vo at oracle.com Thu Oct 4 17:07:59 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 05 Oct 2012 00:07:59 +0000 Subject: hg: openjfx/8/master/rt: 8 new changesets Message-ID: <20121005000810.5B991471B8@hg.openjdk.java.net> Changeset: a30e7be8621e Author: Anthony Petrov Date: 2012-09-26 17:38 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a30e7be8621e RT-24632: JFXPanel ComboBox item list not moved/closed ! javafx-ui-common/src/com/sun/javafx/embed/EmbeddedStageInterface.java ! javafx-ui-common/src/com/sun/javafx/embed/HostInterface.java Changeset: e5267f8c80af Author: kcr Date: 2012-09-26 17:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e5267f8c80af Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 7ee6a11abbbf Author: Felipe Heidrich Date: 2012-09-28 14:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7ee6a11abbbf fix .classpath ! .classpath Changeset: 08067ae69c0c Author: snorthov Date: 2012-09-28 17:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/08067ae69c0c fix .classpath ! .classpath Changeset: eac2df24a6c0 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-02 09:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eac2df24a6c0 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt Changeset: 07c0a2cbf8f3 Author: leifs Date: 2012-09-27 15:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/07c0a2cbf8f3 Fixed RT-25267: [Label] Ellipsis is not working ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: da3f3de73066 Author: leifs Date: 2012-10-02 12:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/da3f3de73066 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt Changeset: 3c29ef369f0c Author: hudson Date: 2012-10-04 16:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3c29ef369f0c Added tag 8.0-b59 for changeset da3f3de73066 ! .hgtags From swpalmer at gmail.com Thu Oct 4 18:56:08 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 4 Oct 2012 21:56:08 -0400 Subject: Layout In-Reply-To: <506DEC25.6010703@tbee.org> References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> <506DEC25.6010703@tbee.org> Message-ID: On Thu, Oct 4, 2012 at 4:05 PM, Tom Eugelink wrote: > Interesting; calling prefWidth(w) & prefHeight(h) on a Pane does not do a > thing, but using setPrefSize(w,h) works fine. > > Tom > That because they are for getting the pref width and height during layout, you've labelled the parameter wrong. It's: public double prefWidth(double height) public double prefHeight(double width) i.e. given width X what is your preferred height? prefHeight prefWidth Scott From tbee at tbee.org Fri Oct 5 00:34:09 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 05 Oct 2012 09:34:09 +0200 Subject: Layout In-Reply-To: References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> <506DEC25.6010703@tbee.org> Message-ID: <506E8D71.5050305@tbee.org> I've solved it. It takes a different approach: instead of extending layoutChildren, you should register to all kinds of properties and then do a relayout. For example: I've registered to the ScrollPane's viewportBounds and react to the changing width and height. Also I'm now refactoring to not do a getChildren().clear on every relayout, but modify the sized. Looking good. From randahl at rockit.dk Fri Oct 5 00:39:24 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 5 Oct 2012 09:39:24 +0200 Subject: Layout In-Reply-To: <506E8D71.5050305@tbee.org> References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> <506DEC25.6010703@tbee.org> <506E8D71.5050305@tbee.org> Message-ID: <7B6DB26A-FAF7-4625-A557-1EE20F606BC0@rockit.dk> Others may have more insight here, but I would guess that completely removing every node and building from scratch leads to poor performance in situations like when resizing a window. Randahl On Oct 5, 2012, at 9:34 , Tom Eugelink wrote: > I've solved it. It takes a different approach: instead of extending layoutChildren, you should register to all kinds of properties and then do a relayout. For example: I've registered to the ScrollPane's viewportBounds and react to the changing width and height. > > Also I'm now refactoring to not do a getChildren().clear on every relayout, but modify the sized. > > Looking good. > > From tbee at tbee.org Fri Oct 5 00:45:15 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 05 Oct 2012 09:45:15 +0200 Subject: Layout In-Reply-To: <7B6DB26A-FAF7-4625-A557-1EE20F606BC0@rockit.dk> References: <506D866C.1000204@tbee.org> <9F7A113B-B1CA-412D-99F5-193C65D5FC2F@rockit.dk> <506D97AB.4020005@tbee.org> <88A2EB27-CCB4-43D1-A97D-2BECBD2137AE@rockit.dk> <506DEC25.6010703@tbee.org> <506E8D71.5050305@tbee.org> <7B6DB26A-FAF7-4625-A557-1EE20F606BC0@rockit.dk> Message-ID: <506E900B.9060101@tbee.org> Indeed, that is why I'm refactoring to remove that behavior. But for a 0.1 it's the easiest way to get a layout setup. On 2012-10-05 09:39, Randahl Fink Isaksen wrote: > Others may have more insight here, but I would guess that completely removing every node and building from scratch leads to poor performance in situations like when resizing a window. > > Randahl > > On Oct 5, 2012, at 9:34 , Tom Eugelink wrote: > >> I've solved it. It takes a different approach: instead of extending layoutChildren, you should register to all kinds of properties and then do a relayout. For example: I've registered to the ScrollPane's viewportBounds and react to the changing width and height. >> >> Also I'm now refactoring to not do a getChildren().clear on every relayout, but modify the sized. >> >> Looking good. >> >> From chien.yang at oracle.com Fri Oct 5 09:42:05 2012 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 05 Oct 2012 09:42:05 -0700 Subject: 3D Features Planned for Version 8 Message-ID: <506F0DDD.9060708@oracle.com> Hi all, We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. https://wikis.oracle.com/display/OpenJDK/3D+Features Please let us know if you have any suggestions or concerns. Regards, - Chien Yang JavaFX Graphics Team From hang.vo at oracle.com Fri Oct 5 11:33:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 05 Oct 2012 18:33:31 +0000 Subject: hg: openjfx/8/controls/rt: RT-25370: upper four bits represent an index. When getting the index value, need to shift unsigned Message-ID: <20121005183333.C7E30471D3@hg.openjdk.java.net> Changeset: 80b5d7e96fdb Author: David Grieve Date: 2012-10-05 14:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/80b5d7e96fdb RT-25370: upper four bits represent an index. When getting the index value, need to shift unsigned ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java From zonski at gmail.com Fri Oct 5 14:16:55 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 6 Oct 2012 07:16:55 +1000 Subject: 3D Features Planned for Version 8 In-Reply-To: <506F0DDD.9060708@oracle.com> References: <506F0DDD.9060708@oracle.com> Message-ID: <665BC9D2-68C4-4033-9D37-0D55D6B7E7CE@gmail.com> Looks cool. I think for people to review this it would be good to have an understanding of its intended usage, in particular how hard it should be pushed. What level of performance is the JFX 3D library aimed at? Obviously this will depend somewhat on the hardware but if I was running on a decent, new PC what spectrum of 3D use cases should I expect to cater for with jfx 3D. Eg for gaming: are we looking at Call of Duty, Grand Theft Auto, Minecraft, Club Penguin, Angry Birds? For modeling: could it do photo realistic CAD (eg http://www.livecad.net/EN/Products/3d-home-design-software.php), or complex scientific modeling (http://www.3dscience.com/3D_Models/index.php) with or without live editing and animations? For 3D UI: how '3D' can my ui be and still be performant. Can I build animated, shaded carousels with reflections and shadows with each entry containing complex 3d scenes (http://www.arm.com/community/partners/product_images/2755.jpg)? Can I embed video on an animated 3d node? Can I build full 3D desktop paradigms with tabbable windows (containing scenes) and transition animations, skewing, warping (like Mac's "to trash" animation) and general coolness (http://www.artefactgroup.com/content/wp-content/uploads/2009/09/Screen-shot-2009-09-21-at-10.24.50-PM-590x444.png or http://www.rlsbb.com/arcsoft-totalmedia-theatre-v5-0-1-87-lz0/ )? On 06/10/2012, at 2:42 AM, Chien Yang wrote: > Hi all, > > We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. > > https://wikis.oracle.com/display/OpenJDK/3D+Features > > Please let us know if you have any suggestions or concerns. > > Regards, > > - Chien Yang > JavaFX Graphics Team From mcdonnell.john at gmail.com Sat Oct 6 05:10:12 2012 From: mcdonnell.john at gmail.com (John McDonnell) Date: Sat, 6 Oct 2012 13:10:12 +0100 Subject: Is VBox serializable? Message-ID: Hey all. I am working adding some drag and drop functionality to a project I have, where I have a list of nodes, and I would like a user to be able to drag a item from a list and drop it elsewhere within the scene. When displaying the items in the list cells, I have a Region, TrafficListingItem, which contains a VBox. When I add the TrafficListingItem to the Dragboard, I get an the following error: Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: Could not serialize the data at com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:500) at javafx.scene.input.Clipboard.setContent(Clipboard.java:226) at ie.john.client.core.platform.TrafficListingItem.drag(TrafficListingItem.java:105) at ie.john.client.main.controller.MainPaneController$TrafficCell$1.handle(MainPaneController.java:101) at ie.john.client.main.controller.MainPaneController$TrafficCell$1.handle(MainPaneController.java:96) at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:69) at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:217) at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:170) at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:38) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:37) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:35) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92) at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:53) at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:33) at javafx.event.Event.fireEvent(Event.java:171) at javafx.scene.Scene$DnDGesture.fireEvent(Scene.java:2627) at javafx.scene.Scene$DnDGesture.process(Scene.java:2706) at javafx.scene.Scene$DnDGesture.access$8700(Scene.java:2603) at javafx.scene.Scene$MouseHandler.process(Scene.java:3340) at javafx.scene.Scene$MouseHandler.process(Scene.java:3164) at javafx.scene.Scene$MouseHandler.access$1900(Scene.java:3119) at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1559) at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2261) at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:228) at com.sun.glass.ui.View.handleMouseEvent(View.java:528) at com.sun.glass.ui.View.notifyMouse(View.java:922) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication$3$1.run(GtkApplication.java:82) at java.lang.Thread.run(Thread.java:722) Caused by: java.io.NotSerializableException: javafx.scene.layout.VBox at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346) at com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:496) ... 81 more It appears as though VBox is not serialisable? Is this correct? If it is how would one go about dragging a node that contains a VBox within the Drag/Drop Events system of JavaFX? -- John From goddard at seznam.cz Sat Oct 6 05:15:06 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sat, 06 Oct 2012 14:15:06 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=203D=20Features=20Planned=20for=20Version=208?= In-Reply-To: <665BC9D2-68C4-4033-9D37-0D55D6B7E7CE@gmail.com> Message-ID: <135689.15946.48444-3057-1298069580-1349525704@seznam.cz> Looks very nice. I can imagine to do a game with it :) Can't wait to get my hands on it ;) Jiri ------------ P?vodn? zpr?va ------------ Od: Daniel Zwolenski P?edm?t: Re: 3D Features Planned for Version 8 Datum: 05.10.2012 23:19:11 ---------------------------------------- Looks cool. I think for people to review this it would be good to have an understanding of its intended usage, in particular how hard it should be pushed. What level of performance is the JFX 3D library aimed at? Obviously this will depend somewhat on the hardware but if I was running on a decent, new PC what spectrum of 3D use cases should I expect to cater for with jfx 3D. Eg for gaming: are we looking at Call of Duty, Grand Theft Auto, Minecraft, Club Penguin, Angry Birds? For modeling: could it do photo realistic CAD (eg http://www.livecad.net/EN/Products/3d-home-design-software.php), or complex scientific modeling (http://www.3dscience.com/3D_Models/index.php) with or without live editing and animations? For 3D UI: how '3D' can my ui be and still be performant. Can I build animated, shaded carousels with reflections and shadows with each entry containing complex 3d scenes (http://www.arm.com/community/partners/product_images/2755.jpg)? Can I embed video on an animated 3d node? Can I build full 3D desktop paradigms with tabbable windows (containing scenes) and transition animations, skewing, warping (like Mac's "to trash" animation) and general coolness (http://www.artefactgroup.com/content/wp-content/uploads/2009/09/Screen-shot-2009-09-21-at-10.24.50-PM-590x444.png or http://www.rlsbb.com/arcsoft-totalmedia-theatre-v5-0-1-87-lz0/ )? On 06/10/2012, at 2:42 AM, Chien Yang wrote: > Hi all, > > We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. > > https://wikis.oracle.com/display/OpenJDK/3D+Features > > Please let us know if you have any suggestions or concerns. > > Regards, > > - Chien Yang > JavaFX Graphics Team From mp at jugs.org Sat Oct 6 05:58:30 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 06 Oct 2012 14:58:30 +0200 Subject: 3D Features Planned for Version 8 In-Reply-To: <506F0DDD.9060708@oracle.com> References: <506F0DDD.9060708@oracle.com> Message-ID: <50702AF6.2010800@jugs.org> Looks good to me but as Daniel already has pointed out it would be important to clearly state how far you are planning to go. I don't think it would be reasonable to try to make JavaFX 3D a full featured game engine. Technically I am missing a level-of-detail node. Cheers Michael Am 05.10.2012 18:42, schrieb Chien Yang: > Hi all, > > We have been thinking about the possible 3D features for JavaFX 8 for > a while. We are now ready to present the plan to the community for > review. This information has also been presented at this year's > JavaOne "3D Made Easy with JavaFX" technical session. > > https://wikis.oracle.com/display/OpenJDK/3D+Features > > Please let us know if you have any suggestions or concerns. > > Regards, > > - Chien Yang > JavaFX Graphics Team -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From goddard at seznam.cz Sat Oct 6 06:26:39 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sat, 06 Oct 2012 15:26:39 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=203D=20Features=20Planned=20for=20Version=208?= In-Reply-To: <50702AF6.2010800@jugs.org> Message-ID: <135696.15940.48448-29615-266500048-1349529999@seznam.cz> I overlooked that LOD node is missing, but I think JFX is a general purpose graphics API so one should be able to write a game in it, for example. Not an AAA title though. Jiri ------------ P?vodn? zpr?va ------------ Od: Dr. Michael Paus P?edm?t: Re: 3D Features Planned for Version 8 Datum: 06.10.2012 15:00:32 ---------------------------------------- Looks good to me but as Daniel already has pointed out it would be important to clearly state how far you are planning to go. I don't think it would be reasonable to try to make JavaFX 3D a full featured game engine. Technically I am missing a level-of-detail node. Cheers Michael Am 05.10.2012 18:42, schrieb Chien Yang: > Hi all, > > We have been thinking about the possible 3D features for JavaFX 8 for > a while. We are now ready to present the plan to the community for > review. This information has also been presented at this year's > JavaOne "3D Made Easy with JavaFX" technical session. > > https://wikis.oracle.com/display/OpenJDK/3D+Features > > Please let us know if you have any suggestions or concerns. > > Regards, > > - Chien Yang > JavaFX Graphics Team -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From jonathan.giles at oracle.com Sat Oct 6 07:33:56 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 06 Oct 2012 07:33:56 -0700 Subject: Is VBox serializable? In-Reply-To: References: Message-ID: <50704154.6070707@oracle.com> When you start the drag, rather than insert the visual nodes into the drag board, you should be inserting the relevant serializable domain data instead. Then, when the domain data is dropped elsewhere, you should create the relevant visual nodes at that point. -- Jonathan On 6/10/2012 5:10 a.m., John McDonnell wrote: > Hey all. > > I am working adding some drag and drop functionality to a project I have, > where I have a list of nodes, and I would like a user to be able to drag a > item from a list and drop it elsewhere within the scene. > > When displaying the items in the list cells, I have a Region, > TrafficListingItem, which contains a VBox. When I add the > TrafficListingItem to the Dragboard, I get an the following error: > > Exception in thread "JavaFX Application Thread" > java.lang.IllegalArgumentException: Could not serialize the data > at > com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:500) > at javafx.scene.input.Clipboard.setContent(Clipboard.java:226) > at > ie.john.client.core.platform.TrafficListingItem.drag(TrafficListingItem.java:105) > at > ie.john.client.main.controller.MainPaneController$TrafficCell$1.handle(MainPaneController.java:101) > at > ie.john.client.main.controller.MainPaneController$TrafficCell$1.handle(MainPaneController.java:96) > at > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:69) > at > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:217) > at > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:170) > at > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:38) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:37) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:35) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92) > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:53) > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:33) > at javafx.event.Event.fireEvent(Event.java:171) > at javafx.scene.Scene$DnDGesture.fireEvent(Scene.java:2627) > at javafx.scene.Scene$DnDGesture.process(Scene.java:2706) > at javafx.scene.Scene$DnDGesture.access$8700(Scene.java:2603) > at javafx.scene.Scene$MouseHandler.process(Scene.java:3340) > at javafx.scene.Scene$MouseHandler.process(Scene.java:3164) > at javafx.scene.Scene$MouseHandler.access$1900(Scene.java:3119) > at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1559) > at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2261) > at > com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:228) > at com.sun.glass.ui.View.handleMouseEvent(View.java:528) > at com.sun.glass.ui.View.notifyMouse(View.java:922) > at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) > at com.sun.glass.ui.gtk.GtkApplication$3$1.run(GtkApplication.java:82) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.io.NotSerializableException: javafx.scene.layout.VBox > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346) > at > com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:496) > ... 81 more > > > It appears as though VBox is not serialisable? Is this correct? If it is > how would one go about dragging a node that contains a VBox within the > Drag/Drop Events system of JavaFX? > > From swpalmer at gmail.com Sat Oct 6 08:37:08 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 6 Oct 2012 11:37:08 -0400 Subject: 3D Features Planned for Version 8 In-Reply-To: <135696.15940.48448-29615-266500048-1349529999@seznam.cz> References: <135696.15940.48448-29615-266500048-1349529999@seznam.cz> Message-ID: LOD node would be useful even for 2D when scaling. Scott On 2012-10-06, at 9:26 AM, goddard at seznam.cz wrote: > I overlooked that LOD node is missing, but I think JFX is a general purpose graphics API so one should be able to write a game in it, for example. Not an AAA title though. > > Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Dr. Michael Paus > P?edm?t: Re: 3D Features Planned for Version 8 > Datum: 06.10.2012 15:00:32 > ---------------------------------------- > Looks good to me but as Daniel already has pointed out it would be important > to clearly state how far you are planning to go. I don't think it would be > reasonable to try to make JavaFX 3D a full featured game engine. > > Technically I am missing a level-of-detail node. > > Cheers > Michael > > > Am 05.10.2012 18:42, schrieb Chien Yang: >> Hi all, >> >> We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. >> >> https://wikis.oracle.com/display/OpenJDK/3D+Features >> >> Please let us know if you have any suggestions or concerns. >> >> Regards, >> >> - Chien Yang >> JavaFX Graphics Team > > > -- > -------------------------------------------------------------------------------------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > > > From mcdonnell.john at gmail.com Sat Oct 6 09:18:32 2012 From: mcdonnell.john at gmail.com (John McDonnell) Date: Sat, 6 Oct 2012 17:18:32 +0100 Subject: Is VBox serializable? In-Reply-To: <50704154.6070707@oracle.com> References: <50704154.6070707@oracle.com> Message-ID: Cheers Jonathon, didn't actually think that about doing it that way, I just thought I could move the Visible node. Thanks John On 6 October 2012 15:33, Jonathan Giles wrote: > When you start the drag, rather than insert the visual nodes into the drag > board, you should be inserting the relevant serializable domain data > instead. Then, when the domain data is dropped elsewhere, you should create > the relevant visual nodes at that point. > > -- Jonathan > > > On 6/10/2012 5:10 a.m., John McDonnell wrote: > >> Hey all. >> >> I am working adding some drag and drop functionality to a project I have, >> where I have a list of nodes, and I would like a user to be able to drag a >> item from a list and drop it elsewhere within the scene. >> >> When displaying the items in the list cells, I have a Region, >> TrafficListingItem, which contains a VBox. When I add the >> TrafficListingItem to the Dragboard, I get an the following error: >> >> Exception in thread "JavaFX Application Thread" >> java.lang.IllegalArgumentException: Could not serialize the data >> at >> >> com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:500) >> at javafx.scene.input.Clipboard.setContent(Clipboard.java:226) >> at >> >> ie.john.client.core.platform.TrafficListingItem.drag(TrafficListingItem.java:105) >> at >> >> ie.john.client.main.controller.MainPaneController$TrafficCell$1.handle(MainPaneController.java:101) >> at >> >> ie.john.client.main.controller.MainPaneController$TrafficCell$1.handle(MainPaneController.java:96) >> at >> >> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:69) >> at >> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:217) >> at >> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:170) >> at >> >> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:38) >> at >> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:37) >> at >> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92) >> at >> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:35) >> at >> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92) >> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:53) >> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:33) >> at javafx.event.Event.fireEvent(Event.java:171) >> at javafx.scene.Scene$DnDGesture.fireEvent(Scene.java:2627) >> at javafx.scene.Scene$DnDGesture.process(Scene.java:2706) >> at javafx.scene.Scene$DnDGesture.access$8700(Scene.java:2603) >> at javafx.scene.Scene$MouseHandler.process(Scene.java:3340) >> at javafx.scene.Scene$MouseHandler.process(Scene.java:3164) >> at javafx.scene.Scene$MouseHandler.access$1900(Scene.java:3119) >> at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1559) >> at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2261) >> at >> >> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:228) >> at com.sun.glass.ui.View.handleMouseEvent(View.java:528) >> at com.sun.glass.ui.View.notifyMouse(View.java:922) >> at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) >> at com.sun.glass.ui.gtk.GtkApplication$3$1.run(GtkApplication.java:82) >> at java.lang.Thread.run(Thread.java:722) >> Caused by: java.io.NotSerializableException: javafx.scene.layout.VBox >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180) >> at >> >> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528) >> at >> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) >> at >> >> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416) >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174) >> at >> >> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528) >> at >> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) >> at >> >> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416) >> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174) >> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346) >> at >> >> com.sun.javafx.tk.quantum.QuantumClipboard.putContent(QuantumClipboard.java:496) >> ... 81 more >> >> >> It appears as though VBox is not serialisable? Is this correct? If it is >> how would one go about dragging a node that contains a VBox within the >> Drag/Drop Events system of JavaFX? >> >> >> > -- John From freddy at spinningnoodle.com Sat Oct 6 13:10:54 2012 From: freddy at spinningnoodle.com (Freddy Guime) Date: Sat, 6 Oct 2012 15:10:54 -0500 Subject: Is there any source code for the JavaFX SceneBuilder? In-Reply-To: References: Message-ID: <000801cda3fe$b173cf30$145b6d90$@com> I wanted to see how hard would it be to integrate the FX SceneBuilder with intellij and was curious if there was either the source code available, or documentation to integrate it with other IDE's (How did NetBeans folks did it?) Thanks! Freddy From joseph.andresen at oracle.com Sat Oct 6 19:08:16 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Sat, 6 Oct 2012 19:08:16 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: References: <135696.15940.48448-29615-266500048-1349529999@seznam.cz> Message-ID: Seeing as none of us have tried to push the current prototype it will be tough to say exactly what can be done. A minecraft port would be an interesting benchmark. Not sure I consider LoD to be a wholly separate node though. On Oct 6, 2012, at 8:37 AM, Scott Palmer wrote: > LOD node would be useful even for 2D when scaling. > > Scott > > On 2012-10-06, at 9:26 AM, goddard at seznam.cz wrote: > >> I overlooked that LOD node is missing, but I think JFX is a general purpose graphics API so one should be able to write a game in it, for example. Not an AAA title though. >> >> Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Dr. Michael Paus >> P?edm?t: Re: 3D Features Planned for Version 8 >> Datum: 06.10.2012 15:00:32 >> ---------------------------------------- >> Looks good to me but as Daniel already has pointed out it would be important >> to clearly state how far you are planning to go. I don't think it would be >> reasonable to try to make JavaFX 3D a full featured game engine. >> >> Technically I am missing a level-of-detail node. >> >> Cheers >> Michael >> >> >> Am 05.10.2012 18:42, schrieb Chien Yang: >>> Hi all, >>> >>> We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. >>> >>> https://wikis.oracle.com/display/OpenJDK/3D+Features >>> >>> Please let us know if you have any suggestions or concerns. >>> >>> Regards, >>> >>> - Chien Yang >>> JavaFX Graphics Team >> >> >> -- >> -------------------------------------------------------------------------------------- >> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). >> For more information visit www.jugs.de. >> >> >> From tbee at tbee.org Sun Oct 7 00:10:58 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 07 Oct 2012 09:10:58 +0200 Subject: property improvement suggestion Message-ID: <50712B02.8040306@tbee.org> As far as I understand, the current the approach is that properties should accept any value, and the usage of these properties have to work with that. Personally I'm prefer a different approach, because I feel the responsibility to have sensible values should be constrained to one place. Therefore I often override the set method of my properties to make sure the value is within the range that my remaining code expect it to be; either by throwing an exception or by clamping the value to a range. But this I can only do with my own properties. It would be nice to also do this to existing properties and therefor I would like to suggest to extend the property concept with constraints or conditions. The important point being that these constraints are applied before the value is set, and not (like a change listener approach) afterwards and then correct value; a value should never be outside it allowed range. The constraints or conditions could have an if-then structure: if value < 0 then 0. An example in Java 8 lambda notation: someNode.widthProperty().*constraint*( w -> w < 0, 0); This would also be something relevant to binding, especially when doing calculations: someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); There is a difference between a permanent constraint on the property and a constraint only applicable to a binding. The notation above is is too similar to my taste and too easily a binding constraint can become a property constaint. To make this difference more explicit, the word "if" could be better on binding: someNode.widthProperty().*constraint*( w -> w < 0, 0); someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); Something to think about is how far these constraints should be taken. These are simple if-then constraints. But what if "else", "elsif" constructions or "case" statements are needed to express the range? In order to keep all options open, maybe the best approach would be to provide constraining listeners. A constraining listener would get the to-be-set value as a parameter and return the new value. For example: widthProperty.addConstrainingListener( v -> { if (v < 0.0) return 0.0; return v; } ); or in normal notation: widthProperty.addConstrainingListener( new ConstaintListener() { public Double constaint(Double value) { if (value < 0.0) return 0.0; return value; } }); (NB: I'm not sure how to use Java 8 lambda with the addListener method, differentiating between a change, invalidation and constraint listener.) This constraining listener approach would allow for all scenario's to be handled. So that is the final improvement I would like to suggest: constrainting listeners. someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return 0.0; return v; } ); someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) return 0.0; return v; } ) ); And if possible normal constraints, because that is a easier notation. I'd like to hear if I'm making sense or am missing the ball completely. Tom From tom.schindl at bestsolution.at Sun Oct 7 02:40:52 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 07 Oct 2012 11:40:52 +0200 Subject: Is there any source code for the JavaFX SceneBuilder? In-Reply-To: <000801cda3fe$b173cf30$145b6d90$@com> References: <000801cda3fe$b173cf30$145b6d90$@com> Message-ID: <50714E24.80309@bestsolution.at> IIRC in Netbeans you simply open it as an external application when you double click on an FXML-File and the same I do e(fx)clipse the Eclipse integration. Tom Am 06.10.12 22:10, schrieb Freddy Guime: > I wanted to see how hard would it be to integrate the FX SceneBuilder with > intellij and was curious if there was either the source code available, or > documentation to integrate it with other IDE's (How did NetBeans folks did > it?) > > Thanks! > > Freddy > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pedro.duquevieira at gmail.com Sun Oct 7 10:45:26 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sun, 7 Oct 2012 18:45:26 +0100 Subject: 3D Features Planned for Version 8 Message-ID: Hi, The API looks promising! :) 3 questions: 1. Is it possible to have several cameras in the scene graph? I think it would be interesting for some apps. This would allow an app to show several views, on different locations, of the same scene graph. 2. If I want to simulate a pervasive light coming from the sky, like the Sun, how would I do it with this API? This light would have to be located upward at an infinite distance. Isn't a thing like a "Directional Light" missing on this API? 3. Will there be an audio node? I imagine, for instance, attaching an audio clip of the sound of a motor engine to a car. The sound would than be louder or quieter depending on the distance of the audio node to the camera. Just my 0.02?. Cheers, -- Pedro Duque Vieira From kirill.prazdnikov at oracle.com Sun Oct 7 14:28:27 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Mon, 08 Oct 2012 01:28:27 +0400 Subject: 3D Features Planned for Version 8 In-Reply-To: References: Message-ID: <5071F3FB.8020307@oracle.com> Hi, Yes, we will introduce a new group with "camera" property. It is SubScene: > SubScene is a special Node for scene separation > It can be used to render part of the Scene with different camera As of 3D audio, it is not planned. -Kirill On 07.10.2012 21:45, Pedro Duque Vieira wrote: > Hi, > > The API looks promising! :) > > 3 questions: > > 1. Is it possible to have several cameras in the scene graph? I think it > would be interesting for some apps. This would allow an app to show several > views, on different locations, of the same scene graph. > 2. If I want to simulate a pervasive light coming from the sky, like the > Sun, how would I do it with this API? This light would have to be located > upward at an infinite distance. Isn't a thing like a "Directional Light" > missing on this API? > 3. Will there be an audio node? I imagine, for instance, attaching an > audio clip of the sound of a motor engine to a car. The sound would than be > louder or quieter depending on the distance of the audio node to the camera. > > Just my 0.02?. Cheers, From goddard at seznam.cz Sun Oct 7 14:57:21 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sun, 07 Oct 2012 23:57:21 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=203D=20Features=20Planned=20for=20Version=208?= In-Reply-To: <5071F3FB.8020307@oracle.com> Message-ID: <135793.15823.48658-5098-1628474910-1349647041@seznam.cz> Everybody is ignoring audio until the last moment. I think am getting used to it, but it's still pity. Jiri ------------ P?vodn? zpr?va ------------ Od: Kirill.Prazdnikov P?edm?t: Re: 3D Features Planned for Version 8 Datum: 07.10.2012 23:30:31 ---------------------------------------- Hi, Yes, we will introduce a new group with "camera" property. It is SubScene: > SubScene is a special Node for scene separation > It can be used to render part of the Scene with different camera As of 3D audio, it is not planned. -Kirill On 07.10.2012 21:45, Pedro Duque Vieira wrote: > Hi, > > The API looks promising! :) > > 3 questions: > > 1. Is it possible to have several cameras in the scene graph? I think it > would be interesting for some apps. This would allow an app to show several > views, on different locations, of the same scene graph. > 2. If I want to simulate a pervasive light coming from the sky, like the > Sun, how would I do it with this API? This light would have to be located > upward at an infinite distance. Isn't a thing like a "Directional Light" > missing on this API? > 3. Will there be an audio node? I imagine, for instance, attaching an > audio clip of the sound of a motor engine to a car. The sound would than be > louder or quieter depending on the distance of the audio node to the camera. > > Just my 0.02?. Cheers, From chien.yang at oracle.com Sun Oct 7 20:00:16 2012 From: chien.yang at oracle.com (Chien Yang) Date: Sun, 07 Oct 2012 20:00:16 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <135689.15946.48444-3057-1298069580-1349525704@seznam.cz> References: <135689.15946.48444-3057-1298069580-1349525704@seznam.cz> Message-ID: <507241C0.9050309@oracle.com> Though LOD isn't part of the 3D feature list, it is very likely that we may provide API support to make LOD implementation easier at the utility or application level. Any feedback on this will be greatly appreciated. JIRA: RT-25524 - Need to provide an easy means for application or utility developer to implement LOD http://javafx-jira.kenai.com/browse/RT-25524 - Chien >LOD node would be useful even for 2D when scaling. > >Scott > >On 2012-10-06, at 9:26 AM,goddard at seznam.cz wrote: > > I overlooked that LOD node is missing, but I think JFX is a general purpose graphics API so one should be able to write a game in it, for example. Not an AAA title though. > > Jiri From joseph.andresen at oracle.com Sun Oct 7 20:10:41 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Sun, 7 Oct 2012 20:10:41 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <507241C0.9050309@oracle.com> References: <135689.15946.48444-3057-1298069580-1349525704@seznam.cz> <507241C0.9050309@oracle.com> Message-ID: Hey chien, Unity uses an LoDGroup attribute to their "node".... Seems to me like the app could do something similar with our API using a group node and a callback that measures distance (or something else) and enables the appropriate mesh. -Joe On Oct 7, 2012, at 8:00 PM, Chien Yang wrote: > Though LOD isn't part of the 3D feature list, it is very likely that we may provide API support to make LOD implementation easier at the utility or application level. Any feedback on this will be greatly appreciated. > > JIRA: RT-25524 - Need to provide an easy means for application or utility developer to implement LOD > http://javafx-jira.kenai.com/browse/RT-25524 > > - Chien > > >> LOD node would be useful even for 2D when scaling. >> >> Scott >> >> On 2012-10-06, at 9:26 AM,goddard at seznam.cz wrote: > >> I overlooked that LOD node is missing, but I think JFX is a general purpose graphics API so one should be able to write a game in it, for example. Not an AAA title though. >> >> Jiri From chien.yang at oracle.com Sun Oct 7 20:57:36 2012 From: chien.yang at oracle.com (Chien Yang) Date: Sun, 07 Oct 2012 20:57:36 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <665BC9D2-68C4-4033-9D37-0D55D6B7E7CE@gmail.com> References: <506F0DDD.9060708@oracle.com> <665BC9D2-68C4-4033-9D37-0D55D6B7E7CE@gmail.com> Message-ID: <50724F30.5010804@oracle.com> We understand this is a fairly limited set of 3D features and it will not replace a 3D game engine. However we hope this is sufficient to position us well into market segments such as 3D business charting, virtual shopping, information tracking System and causal gaming. - Chien On 10/5/2012 2:16 PM, Daniel Zwolenski wrote: > Looks cool. I think for people to review this it would be good to have an understanding of its intended usage, in particular how hard it should be pushed. > > What level of performance is the JFX 3D library aimed at? Obviously this will depend somewhat on the hardware but if I was running on a decent, new PC what spectrum of 3D use cases should I expect to cater for with jfx 3D. > > Eg for gaming: are we looking at Call of Duty, Grand Theft Auto, Minecraft, Club Penguin, Angry Birds? > > For modeling: could it do photo realistic CAD (eg http://www.livecad.net/EN/Products/3d-home-design-software.php), or complex scientific modeling (http://www.3dscience.com/3D_Models/index.php) with or without live editing and animations? > > For 3D UI: how '3D' can my ui be and still be performant. Can I build animated, shaded carousels with reflections and shadows with each entry containing complex 3d scenes (http://www.arm.com/community/partners/product_images/2755.jpg)? Can I embed video on an animated 3d node? Can I build full 3D desktop paradigms with tabbable windows (containing scenes) and transition animations, skewing, warping (like Mac's "to trash" animation) and general coolness (http://www.artefactgroup.com/content/wp-content/uploads/2009/09/Screen-shot-2009-09-21-at-10.24.50-PM-590x444.png or http://www.rlsbb.com/arcsoft-totalmedia-theatre-v5-0-1-87-lz0/ )? > > > > On 06/10/2012, at 2:42 AM, Chien Yang wrote: > >> Hi all, >> >> We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. >> >> https://wikis.oracle.com/display/OpenJDK/3D+Features >> >> Please let us know if you have any suggestions or concerns. >> >> Regards, >> >> - Chien Yang >> JavaFX Graphics Team From danno.ferrin at shemnon.com Sun Oct 7 21:36:20 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Sun, 7 Oct 2012 22:36:20 -0600 Subject: Building OpenJFX 8 Message-ID: Is there a chance we can get updated build instructions for OpenJFX 8? The instructions I can find ( http://openjdk.java.net/projects/openjfx/getting-started.html) appear out of date even for OpenJFX 2.2. Do I need to grab some of the Java 8 builds? And if so which one? There appear to be brand new symbols like PulseLogger, VetoableListDecorator, and PlatformUtil.isIOS (!) that don't exist in the Java 7 builds so that seems like a bad base to build on. -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From zonski at gmail.com Sun Oct 7 22:10:46 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 8 Oct 2012 16:10:46 +1100 Subject: 3D Features Planned for Version 8 In-Reply-To: <50724F30.5010804@oracle.com> References: <506F0DDD.9060708@oracle.com> <665BC9D2-68C4-4033-9D37-0D55D6B7E7CE@gmail.com> <50724F30.5010804@oracle.com> Message-ID: Hi Chien, Thanks for the feedback. It's still a little vague for me though what the target is for this (and so very hard to review the spec), so it would be great to have a little more detail. Can you elaborate on 'casual gaming' please (I assume you did mean 'casual' and not 'causal')? I don't think any of us were really expecting something as hard core as a 3D live action shoot-em-up platform (like Call of Duty), but can we hope to use it to build Minecraft for example (Java+LWJGL), or Club Penguin (Flash), or even Angry Birds , or are we just talking about 3D tic tac toe? You talk about 'online shopping' - how do you see 3D being used in this? Are we talking about modelling products in 3D (e.g. cars, clothes , etc using live-renderered 3D models)? Are you talking about a 3D Virtual "Mall"with Avatar that could be walked around? Or maybe you just mean photos of products on a carousel that rotate? If modelling products for sale in 3D, should we expect to achieve any kind of level of photo realism (e.g. realistic lighting, shadows, reflections, glass, water, fire) or are we looking at 'cartoon' like unshaded scenes ? "Information tracking systems" is a pretty broad field (just check out http://www.informationisbeautifulawards.com/2012/09/information-is-beautiful-awards-winners/ for an idea of the range). Are you talking about complicated animated spatial visualisations (e.g. Google Earth), 3D elements as video overlays, or just some good old fashioned 3D pie and bar charts (like http://www.fusioncharts.com/). In the absence of other reference points, it would be nice to think that the JavaFX 3D library is aiming to provide features that are at least on par with its major competitors, which I'd guess are along the lines of: - Flash 3D - Web3D - WebGL - Mobile 3D (i.e. OpenGL ES ) Is this what you guys are thinking, if not, is it possible to reference other existing 3D libraries, platforms or products that give us some indication of the upper reaches we're looking at for this library? Cheers, Dan On Mon, Oct 8, 2012 at 2:57 PM, Chien Yang wrote: > We understand this is a fairly limited set of 3D features and it will not > replace a 3D game engine. However we hope this is sufficient to position us > well into market segments such as 3D business charting, virtual shopping, > information tracking System and causal gaming. > > - Chien > > > On 10/5/2012 2:16 PM, Daniel Zwolenski wrote: > >> Looks cool. I think for people to review this it would be good to have an >> understanding of its intended usage, in particular how hard it should be >> pushed. >> >> What level of performance is the JFX 3D library aimed at? Obviously this >> will depend somewhat on the hardware but if I was running on a decent, new >> PC what spectrum of 3D use cases should I expect to cater for with jfx 3D. >> >> Eg for gaming: are we looking at Call of Duty, Grand Theft Auto, >> Minecraft, Club Penguin, Angry Birds? >> >> For modeling: could it do photo realistic CAD (eg >> http://www.livecad.net/EN/**Products/3d-home-design-**software.php), >> or complex scientific modeling (http://www.3dscience.com/3D_** >> Models/index.php ) with or >> without live editing and animations? >> >> For 3D UI: how '3D' can my ui be and still be performant. Can I build >> animated, shaded carousels with reflections and shadows with each entry >> containing complex 3d scenes (http://www.arm.com/community/** >> partners/product_images/2755.**jpg)? >> Can I embed video on an animated 3d node? Can I build full 3D desktop >> paradigms with tabbable windows (containing scenes) and transition >> animations, skewing, warping (like Mac's "to trash" animation) and general >> coolness (http://www.artefactgroup.com/**content/wp-content/uploads/** >> 2009/09/Screen-shot-2009-09-**21-at-10.24.50-PM-590x444.pngor >> http://www.rlsbb.com/arcsoft-**totalmedia-theatre-v5-0-1-87-**lz0/)? >> >> >> >> On 06/10/2012, at 2:42 AM, Chien Yang wrote: >> >> Hi all, >>> >>> We have been thinking about the possible 3D features for JavaFX 8 for a >>> while. We are now ready to present the plan to the community for review. >>> This information has also been presented at this year's JavaOne "3D Made >>> Easy with JavaFX" technical session. >>> >>> https://wikis.oracle.com/**display/OpenJDK/3D+Features >>> >>> Please let us know if you have any suggestions or concerns. >>> >>> Regards, >>> >>> - Chien Yang >>> JavaFX Graphics Team >>> >> > From jerome.cambon at oracle.com Mon Oct 8 00:23:05 2012 From: jerome.cambon at oracle.com (Jerome Cambon) Date: Mon, 08 Oct 2012 09:23:05 +0200 Subject: Is there any source code for the JavaFX SceneBuilder? In-Reply-To: <000801cda3fe$b173cf30$145b6d90$@com> References: <000801cda3fe$b173cf30$145b6d90$@com> Message-ID: <50727F59.5090105@oracle.com> Hi Freddy, We will provide documentation about Scene Builder integration with various IDE (Netbeans, Eclipse, IntelliJ) soon. For IntelliJ IDEA, it is quite easy to launch Scene Builder (SB) from the IDE, and to build/run the SB samples : 1- Launch SB for IntelliJ - From File->Settings panel, select File Types. Select "Files opened in associated applications", and add "*.fxml" in the pattern list. - Double-click an fxml file to edit it with Scene Builder 2- Run SB examples - Create project from existing sources - In idea/compiler.xml, add the .fxml resource so that the fxml file is copied in the "out" directory next to .class files HTH, Jerome On 10/6/12 10:10 PM, Freddy Guime wrote: > I wanted to see how hard would it be to integrate the FX SceneBuilder with > intellij and was curious if there was either the source code available, or > documentation to integrate it with other IDE's (How did NetBeans folks did > it?) > > Thanks! > > Freddy > > > From pedro.duquevieira at gmail.com Mon Oct 8 06:43:18 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 8 Oct 2012 14:43:18 +0100 Subject: 3D Features Planned for Version 8 Message-ID: What about the lightning thing I talked about (2 point)? I can't really understand why that type of light is missing.. I remembered one more thing: a Billboard node would be useful. Thanks, best regards, Hi, > Yes, we will introduce a new group with "camera" property. It is SubScene: > > SubScene is a special Node for scene separation > > It can be used to render part of the Scene with different camera > As of 3D audio, it is not planned. > -Kirill > On 07.10.2012 21:45, Pedro Duque Vieira wrote: > > Hi, > > > > The API looks promising! :) > > > > 3 questions: > > > > 1. Is it possible to have several cameras in the scene graph? I > think it > > would be interesting for some apps. This would allow an app to show > several > > views, on different locations, of the same scene graph. > > 2. If I want to simulate a pervasive light coming from the sky, like > the > > Sun, how would I do it with this API? This light would have to be > located > > upward at an infinite distance. Isn't a thing like a "Directional > Light" > > missing on this API? > > 3. Will there be an audio node? I imagine, for instance, attaching an > > audio clip of the sound of a motor engine to a car. The sound would > than be > > louder or quieter depending on the distance of the audio node to the > camera. > > > > Just my 0.02?. Cheers, -- Pedro Duque Vieira From Kirill.Prazdnikov at oracle.com Mon Oct 8 06:46:47 2012 From: Kirill.Prazdnikov at oracle.com (Kirill Prazdnikov) Date: Mon, 08 Oct 2012 17:46:47 +0400 Subject: 3D Features Planned for Version 8 In-Reply-To: References: Message-ID: <5072D947.5080505@oracle.com> Hi, Lets wait for more detailed API review. There will be room for more concrete API questions. As for Billboard node: it is the ImageView class. -Kirill On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: > What about the lightning thing I talked about (2 point)? I can't really > understand why that type of light is missing.. > > I remembered one more thing: a Billboard node would be useful. > > Thanks, best regards, > > > Hi, >> Yes, we will introduce a new group with "camera" property. It is SubScene: >>> SubScene is a special Node for scene separation >>> It can be used to render part of the Scene with different camera >> As of 3D audio, it is not planned. >> -Kirill >> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>> Hi, >>> >>> The API looks promising! :) >>> >>> 3 questions: >>> >>> 1. Is it possible to have several cameras in the scene graph? I >> think it >>> would be interesting for some apps. This would allow an app to show >> several >>> views, on different locations, of the same scene graph. >>> 2. If I want to simulate a pervasive light coming from the sky, like >> the >>> Sun, how would I do it with this API? This light would have to be >> located >>> upward at an infinite distance. Isn't a thing like a "Directional >> Light" >>> missing on this API? >>> 3. Will there be an audio node? I imagine, for instance, attaching an >>> audio clip of the sound of a motor engine to a car. The sound would >> than be >>> louder or quieter depending on the distance of the audio node to the >> camera. >>> Just my 0.02?. Cheers, From kevin.rushforth at oracle.com Mon Oct 8 07:53:23 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Oct 2012 07:53:23 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072D947.5080505@oracle.com> References: <5072D947.5080505@oracle.com> Message-ID: <5072E8E3.8080504@oracle.com> > As for Billboard node: it is the ImageView class. That isn't sufficient. A BillBoard node is one that always orients itself towards the viewer regardless of the position and orientation of the camera. This is unplanned for FX 8. -- Kevin Kirill Prazdnikov wrote: > Hi, > > Lets wait for more detailed API review. > There will be room for more concrete API questions. > > As for Billboard node: it is the ImageView class. > > -Kirill > > On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >> What about the lightning thing I talked about (2 point)? I can't really >> understand why that type of light is missing.. >> >> I remembered one more thing: a Billboard node would be useful. >> >> Thanks, best regards, >> >> >> Hi, >>> Yes, we will introduce a new group with "camera" property. It is >>> SubScene: >>>> SubScene is a special Node for scene separation >>>> It can be used to render part of the Scene with different camera >>> As of 3D audio, it is not planned. >>> -Kirill >>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>> Hi, >>>> >>>> The API looks promising! :) >>>> >>>> 3 questions: >>>> >>>> 1. Is it possible to have several cameras in the scene graph? I >>> think it >>>> would be interesting for some apps. This would allow an app to >>>> show >>> several >>>> views, on different locations, of the same scene graph. >>>> 2. If I want to simulate a pervasive light coming from the >>>> sky, like >>> the >>>> Sun, how would I do it with this API? This light would have to be >>> located >>>> upward at an infinite distance. Isn't a thing like a "Directional >>> Light" >>>> missing on this API? >>>> 3. Will there be an audio node? I imagine, for instance, >>>> attaching an >>>> audio clip of the sound of a motor engine to a car. The sound >>>> would >>> than be >>>> louder or quieter depending on the distance of the audio node >>>> to the >>> camera. >>>> Just my 0.02?. Cheers, > From joseph.andresen at oracle.com Mon Oct 8 08:37:57 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Mon, 08 Oct 2012 08:37:57 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072E8E3.8080504@oracle.com> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> Message-ID: <5072F355.60606@oracle.com> On 10/8/2012 7:53 AM, Kevin Rushforth wrote: > > As for Billboard node: it is the ImageView class. > > That isn't sufficient. A BillBoard node is one that always orients > itself towards the viewer regardless of the position and orientation > of the camera. This is unplanned for FX 8. > > -- Kevin > Can't this be done using a group with an invalidated transform every time the camera is moved? > > Kirill Prazdnikov wrote: >> Hi, >> >> Lets wait for more detailed API review. >> There will be room for more concrete API questions. >> >> As for Billboard node: it is the ImageView class. >> >> -Kirill >> >> On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >>> What about the lightning thing I talked about (2 point)? I can't really >>> understand why that type of light is missing.. >>> >>> I remembered one more thing: a Billboard node would be useful. >>> >>> Thanks, best regards, >>> >>> >>> Hi, >>>> Yes, we will introduce a new group with "camera" property. It is >>>> SubScene: >>>>> SubScene is a special Node for scene separation >>>>> It can be used to render part of the Scene with different camera >>>> As of 3D audio, it is not planned. >>>> -Kirill >>>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>>> Hi, >>>>> >>>>> The API looks promising! :) >>>>> >>>>> 3 questions: >>>>> >>>>> 1. Is it possible to have several cameras in the scene graph? I >>>> think it >>>>> would be interesting for some apps. This would allow an app >>>>> to show >>>> several >>>>> views, on different locations, of the same scene graph. >>>>> 2. If I want to simulate a pervasive light coming from the >>>>> sky, like >>>> the >>>>> Sun, how would I do it with this API? This light would have >>>>> to be >>>> located >>>>> upward at an infinite distance. Isn't a thing like a >>>>> "Directional >>>> Light" >>>>> missing on this API? >>>>> 3. Will there be an audio node? I imagine, for instance, >>>>> attaching an >>>>> audio clip of the sound of a motor engine to a car. The sound >>>>> would >>>> than be >>>>> louder or quieter depending on the distance of the audio node >>>>> to the >>>> camera. >>>>> Just my 0.02?. Cheers, >> From joseph.andresen at oracle.com Mon Oct 8 08:41:49 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Mon, 08 Oct 2012 08:41:49 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072E8E3.8080504@oracle.com> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> Message-ID: <5072F43D.8070903@oracle.com> To be exact something like this |// Add camera to scene graph (so it can move)| |Group cameraGroup = ||new| |Group();| |cameraGroup.getChildren().add(camera);| |root.getChildren().add(cameraGroup); ImaveView imageView = new ImageView(...); cameraGroup.getChildren().add(||imageView||); //transform cameraGroup to transform camera and billboards. | On 10/8/2012 7:53 AM, Kevin Rushforth wrote: > > As for Billboard node: it is the ImageView class. > > That isn't sufficient. A BillBoard node is one that always orients > itself towards the viewer regardless of the position and orientation > of the camera. This is unplanned for FX 8. > > -- Kevin > > > Kirill Prazdnikov wrote: >> Hi, >> >> Lets wait for more detailed API review. >> There will be room for more concrete API questions. >> >> As for Billboard node: it is the ImageView class. >> >> -Kirill >> >> On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >>> What about the lightning thing I talked about (2 point)? I can't really >>> understand why that type of light is missing.. >>> >>> I remembered one more thing: a Billboard node would be useful. >>> >>> Thanks, best regards, >>> >>> >>> Hi, >>>> Yes, we will introduce a new group with "camera" property. It is >>>> SubScene: >>>>> SubScene is a special Node for scene separation >>>>> It can be used to render part of the Scene with different camera >>>> As of 3D audio, it is not planned. >>>> -Kirill >>>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>>> Hi, >>>>> >>>>> The API looks promising! :) >>>>> >>>>> 3 questions: >>>>> >>>>> 1. Is it possible to have several cameras in the scene graph? I >>>> think it >>>>> would be interesting for some apps. This would allow an app >>>>> to show >>>> several >>>>> views, on different locations, of the same scene graph. >>>>> 2. If I want to simulate a pervasive light coming from the >>>>> sky, like >>>> the >>>>> Sun, how would I do it with this API? This light would have >>>>> to be >>>> located >>>>> upward at an infinite distance. Isn't a thing like a >>>>> "Directional >>>> Light" >>>>> missing on this API? >>>>> 3. Will there be an audio node? I imagine, for instance, >>>>> attaching an >>>>> audio clip of the sound of a motor engine to a car. The sound >>>>> would >>>> than be >>>>> louder or quieter depending on the distance of the audio node >>>>> to the >>>> camera. >>>>> Just my 0.02?. Cheers, >> From richard.bair at oracle.com Mon Oct 8 07:26:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 8 Oct 2012 07:26:22 -0700 Subject: property improvement suggestion In-Reply-To: <50712B02.8040306@tbee.org> References: <50712B02.8040306@tbee.org> Message-ID: <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> It looks like there are two elements of this proposal. The first is that the author of a bean might want to specify some inherent constraint on the property -- such as, it should never be null, or it should never be negative. The second is that a user of the property might want to constrain the property in some way -- such as, in my app the width should never be negative. I see the value immediately in the first (in fact, this has always been a problem with our properties, going all the way back to JavaFX Script), but I struggle to see much value in the second. Not because you might not want to do this sort of thing, but because the first (inherent constraints) is not presently possible at all, while the second (app constraints) you can already do in your application code, one way or another. I am inclined not to add API for cases that are already solvable, unless it turns out to be so compelling and widely used. From a semantic point of view, binding was a "mathematical" relationship between two properties in JavaFX Script, such that when you read code like: x: bind 10 * someProperty you new that "x" was going to be 10 * someProperty, and not anything else. Of course as an API designer I have never liked that because I have to handle exceptional conditions in my code rather than being able to verify that a property can never go outside its valid range of values. I am pleased to see your proposal doesn't include throwing exceptions -- I think throwing an exception from a property on invalid input is a very bad idea. The problem is in lazy evaluation of properties. Suppose: widthProperty().bind(someProperty) Further suppose width is constrained to never be < 0, and somebody were to try to set it to be < 0 it would throw an exception. In this case, someProperty might be set to -10 at some time, and the width property is invalidated. But until somebody tries to read width, it won't throw the exception. So the problem with bound properties & exceptions is that the exception is not thrown at the time the error is introduced, but rather at the time the error is discovered, which turns out to be an awful behavior. However your proposal instead says "if it is outside the allowable range, I will just adjust the value to keep it within the allowable range". I think this is a really good idea. The property implementations would have to be modified such that on read, instead of: /** * {@inheritDoc} */ @Override public boolean get() { valid = true; return observable == null ? value : observable.get(); } we instead do something like: /** * {@inheritDoc} */ @Override public boolean get() { if (!valid && observable != null) { value = constrain(observable.get()); } valid = true; return observable == null ? value : observable.get(); } And add a protected 'constrain' method. Or perhaps we can just call the "set" method and let the set method deal with constraining. This would require taking some care, however, because it means set methods will now be called even when the property is bound which is different than at present, and calling super.set() would throw an exception in the case that it is bound. But still, as a Java developer I'm used to doing constraining from within the setter, so doing it inside the set seems the most natural, but this would be an area that needs to be figured out. Richard On Oct 7, 2012, at 12:10 AM, Tom Eugelink wrote: > As far as I understand, the current the approach is that properties should accept any value, and the usage of these properties have to work with that. Personally I'm prefer a different approach, because I feel the responsibility to have sensible values should be constrained to one place. Therefore I often override the set method of my properties to make sure the value is within the range that my remaining code expect it to be; either by throwing an exception or by clamping the value to a range. > > But this I can only do with my own properties. It would be nice to also do this to existing properties and therefor I would like to suggest to extend the property concept with constraints or conditions. The important point being that these constraints are applied before the value is set, and not (like a change listener approach) afterwards and then correct value; a value should never be outside it allowed range. > > The constraints or conditions could have an if-then structure: if value < 0 then 0. An example in Java 8 lambda notation: > someNode.widthProperty().*constraint*( w -> w < 0, 0); > > This would also be something relevant to binding, especially when doing calculations: > someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); > > There is a difference between a permanent constraint on the property and a constraint only applicable to a binding. The notation above is is too similar to my taste and too easily a binding constraint can become a property constaint. To make this difference more explicit, the word "if" could be better on binding: > someNode.widthProperty().*constraint*( w -> w < 0, 0); > someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); > > Something to think about is how far these constraints should be taken. These are simple if-then constraints. But what if "else", "elsif" constructions or "case" statements are needed to express the range? In order to keep all options open, maybe the best approach would be to provide constraining listeners. A constraining listener would get the to-be-set value as a parameter and return the new value. For example: > > widthProperty.addConstrainingListener( v -> { if (v < 0.0) return 0.0; return v; } ); > > or in normal notation: > > widthProperty.addConstrainingListener( new ConstaintListener() { > public Double constaint(Double value) { > if (value < 0.0) return 0.0; > return value; > } > }); > > (NB: I'm not sure how to use Java 8 lambda with the addListener method, differentiating between a change, invalidation and constraint listener.) > > This constraining listener approach would allow for all scenario's to be handled. So that is the final improvement I would like to suggest: constrainting listeners. > someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return 0.0; return v; } ); > someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) return 0.0; return v; } ) ); > > And if possible normal constraints, because that is a easier notation. > > I'd like to hear if I'm making sense or am missing the ball completely. > > Tom From Kirill.Prazdnikov at oracle.com Mon Oct 8 08:52:12 2012 From: Kirill.Prazdnikov at oracle.com (Kirill Prazdnikov) Date: Mon, 08 Oct 2012 19:52:12 +0400 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072E8E3.8080504@oracle.com> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> Message-ID: <5072F6AC.9030602@oracle.com> I see. Probably it is possible to "listen to" the camera position and update the orientation accordingly ? -Kirill On 10/8/2012 6:53 PM, Kevin Rushforth wrote: > > As for Billboard node: it is the ImageView class. > > That isn't sufficient. A BillBoard node is one that always orients > itself towards the viewer regardless of the position and orientation > of the camera. This is unplanned for FX 8. > > -- Kevin > > > Kirill Prazdnikov wrote: >> Hi, >> >> Lets wait for more detailed API review. >> There will be room for more concrete API questions. >> >> As for Billboard node: it is the ImageView class. >> >> -Kirill >> >> On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >>> What about the lightning thing I talked about (2 point)? I can't really >>> understand why that type of light is missing.. >>> >>> I remembered one more thing: a Billboard node would be useful. >>> >>> Thanks, best regards, >>> >>> >>> Hi, >>>> Yes, we will introduce a new group with "camera" property. It is >>>> SubScene: >>>>> SubScene is a special Node for scene separation >>>>> It can be used to render part of the Scene with different camera >>>> As of 3D audio, it is not planned. >>>> -Kirill >>>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>>> Hi, >>>>> >>>>> The API looks promising! :) >>>>> >>>>> 3 questions: >>>>> >>>>> 1. Is it possible to have several cameras in the scene graph? I >>>> think it >>>>> would be interesting for some apps. This would allow an app >>>>> to show >>>> several >>>>> views, on different locations, of the same scene graph. >>>>> 2. If I want to simulate a pervasive light coming from the >>>>> sky, like >>>> the >>>>> Sun, how would I do it with this API? This light would have >>>>> to be >>>> located >>>>> upward at an infinite distance. Isn't a thing like a >>>>> "Directional >>>> Light" >>>>> missing on this API? >>>>> 3. Will there be an audio node? I imagine, for instance, >>>>> attaching an >>>>> audio clip of the sound of a motor engine to a car. The sound >>>>> would >>>> than be >>>>> louder or quieter depending on the distance of the audio node >>>>> to the >>>> camera. >>>>> Just my 0.02?. Cheers, >> From richard.bair at oracle.com Mon Oct 8 08:23:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 8 Oct 2012 08:23:49 -0700 Subject: poor performance when part of window sits outside of desktop screen In-Reply-To: <1348852777.86305.YahooMailNeo@web161504.mail.bf1.yahoo.com> References: <1348852777.86305.YahooMailNeo@web161504.mail.bf1.yahoo.com> Message-ID: <0D37A24C-378D-4B53-A6F8-92B26A742487@oracle.com> Hi Jose, Thanks for the bug, I'll take a look and make sure it is assigned / prioritized correctly. This appears to be one of several similar issues (such as resizing windows on Mac being very slow). Richard On Sep 28, 2012, at 10:19 AM, Jose Martinez wrote: > Hello, > > I been troubleshooting this performance issue that has been plaguing me for weeks. It turns out that regardless of the size of my Stage, if part of it sits outside of the desktop screen (so that 100% of it is not visible on the desktop) then performance drops considerably. > > The FPS drop from 60 to low 50's but that might be misleading. Where 50 FPS would be fine (i would imagine), in my case it causes jitterish movement of Node along their PathTransitions. > > http://javafx-jira.kenai.com/browse/RT-25350 > > > thanks > jose From richard.bair at oracle.com Mon Oct 8 08:22:17 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 8 Oct 2012 08:22:17 -0700 Subject: Bindings.bindContent and filtering In-Reply-To: References: Message-ID: Hi Sven, I'm not sure. I know that we've got FilteredList, FilteredSet, etc implementations that we want to make public API, perhaps that is a better way to handle it? Richard On Sep 28, 2012, at 4:34 PM, Sven Reimers wrote: > Hi all, > > just wondered if having a binding that allows me for example to filter > duplicates (allowed in lists like WebHistory.getEntries()) during the > bindContent to another ObservabeList (e.g. the items of ComboBox) > would be a good thing - or is this one of the extensions to expect > when JavaFX can use lambdas? > > -Sven > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From pedro.duquevieira at gmail.com Mon Oct 8 09:46:39 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 8 Oct 2012 17:46:39 +0100 Subject: 3D Features Planned for Version 8 Message-ID: I'm considering that by saying that ImageView is a Billboard node you're saying that in 3D it is always oriented towards the camera? Shouldn't that be a property of ImageView rather than a automatic behavior? Yes I do think it is possible to do this by code but I think it would be a rather nice addition, though I also think that as long as you can do it yourself it is not a mandatory feature but rather a nice to have. Thanks, best regards, To be exact something like this > |// Add camera to scene graph (so it can move)| > |Group cameraGroup = ||new| |Group();| > |cameraGroup.getChildren().add(camera);| > |root.getChildren().add(cameraGroup); > ImaveView imageView = new ImageView(...); > cameraGroup.getChildren().add(||imageView||); > //transform cameraGroup to transform camera and billboards. > > > > | > -- Pedro Duque Vieira From kevin.rushforth at oracle.com Mon Oct 8 09:52:01 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Oct 2012 09:52:01 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072F6AC.9030602@oracle.com> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> <5072F6AC.9030602@oracle.com> Message-ID: <507304B1.20906@oracle.com> Yes. -- Kevin Kirill Prazdnikov wrote: > I see. > Probably it is possible to "listen to" the camera position and update > the orientation accordingly ? > > -Kirill > > On 10/8/2012 6:53 PM, Kevin Rushforth wrote: >> > As for Billboard node: it is the ImageView class. >> >> That isn't sufficient. A BillBoard node is one that always orients >> itself towards the viewer regardless of the position and orientation >> of the camera. This is unplanned for FX 8. >> >> -- Kevin >> >> >> Kirill Prazdnikov wrote: >>> Hi, >>> >>> Lets wait for more detailed API review. >>> There will be room for more concrete API questions. >>> >>> As for Billboard node: it is the ImageView class. >>> >>> -Kirill >>> >>> On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >>>> What about the lightning thing I talked about (2 point)? I can't >>>> really >>>> understand why that type of light is missing.. >>>> >>>> I remembered one more thing: a Billboard node would be useful. >>>> >>>> Thanks, best regards, >>>> >>>> >>>> Hi, >>>>> Yes, we will introduce a new group with "camera" property. It is >>>>> SubScene: >>>>>> SubScene is a special Node for scene separation >>>>>> It can be used to render part of the Scene with different camera >>>>> As of 3D audio, it is not planned. >>>>> -Kirill >>>>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>>>> Hi, >>>>>> >>>>>> The API looks promising! :) >>>>>> >>>>>> 3 questions: >>>>>> >>>>>> 1. Is it possible to have several cameras in the scene graph? I >>>>> think it >>>>>> would be interesting for some apps. This would allow an app >>>>>> to show >>>>> several >>>>>> views, on different locations, of the same scene graph. >>>>>> 2. If I want to simulate a pervasive light coming from the >>>>>> sky, like >>>>> the >>>>>> Sun, how would I do it with this API? This light would have >>>>>> to be >>>>> located >>>>>> upward at an infinite distance. Isn't a thing like a >>>>>> "Directional >>>>> Light" >>>>>> missing on this API? >>>>>> 3. Will there be an audio node? I imagine, for instance, >>>>>> attaching an >>>>>> audio clip of the sound of a motor engine to a car. The >>>>>> sound would >>>>> than be >>>>>> louder or quieter depending on the distance of the audio >>>>>> node to the >>>>> camera. >>>>>> Just my 0.02?. Cheers, >>> > From kevin.rushforth at oracle.com Mon Oct 8 09:52:07 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Oct 2012 09:52:07 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072F355.60606@oracle.com> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> <5072F355.60606@oracle.com> Message-ID: <507304B7.2010203@oracle.com> > Can't this be done using a group with an invalidated transform every time the camera is moved? Yes. And providing a sample of how to do this seems a good idea. What is unplanned for FX 8 is having an actual node that does this automatically. -- Kevin joe andresen wrote: > On 10/8/2012 7:53 AM, Kevin Rushforth wrote: >> > As for Billboard node: it is the ImageView class. >> >> That isn't sufficient. A BillBoard node is one that always orients >> itself towards the viewer regardless of the position and orientation >> of the camera. This is unplanned for FX 8. >> >> -- Kevin >> > Can't this be done using a group with an invalidated transform every > time the camera is moved? > > >> >> Kirill Prazdnikov wrote: >>> Hi, >>> >>> Lets wait for more detailed API review. >>> There will be room for more concrete API questions. >>> >>> As for Billboard node: it is the ImageView class. >>> >>> -Kirill >>> >>> On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >>>> What about the lightning thing I talked about (2 point)? I can't >>>> really >>>> understand why that type of light is missing.. >>>> >>>> I remembered one more thing: a Billboard node would be useful. >>>> >>>> Thanks, best regards, >>>> >>>> >>>> Hi, >>>>> Yes, we will introduce a new group with "camera" property. It is >>>>> SubScene: >>>>>> SubScene is a special Node for scene separation >>>>>> It can be used to render part of the Scene with different camera >>>>> As of 3D audio, it is not planned. >>>>> -Kirill >>>>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>>>> Hi, >>>>>> >>>>>> The API looks promising! :) >>>>>> >>>>>> 3 questions: >>>>>> >>>>>> 1. Is it possible to have several cameras in the scene graph? I >>>>> think it >>>>>> would be interesting for some apps. This would allow an app >>>>>> to show >>>>> several >>>>>> views, on different locations, of the same scene graph. >>>>>> 2. If I want to simulate a pervasive light coming from the >>>>>> sky, like >>>>> the >>>>>> Sun, how would I do it with this API? This light would have >>>>>> to be >>>>> located >>>>>> upward at an infinite distance. Isn't a thing like a >>>>>> "Directional >>>>> Light" >>>>>> missing on this API? >>>>>> 3. Will there be an audio node? I imagine, for instance, >>>>>> attaching an >>>>>> audio clip of the sound of a motor engine to a car. The >>>>>> sound would >>>>> than be >>>>>> louder or quieter depending on the distance of the audio >>>>>> node to the >>>>> camera. >>>>>> Just my 0.02?. Cheers, >>> > From mp at jugs.org Mon Oct 8 09:59:03 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Mon, 08 Oct 2012 18:59:03 +0200 Subject: 3D Features Planned for Version 8 In-Reply-To: <5072F43D.8070903@oracle.com> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> <5072F43D.8070903@oracle.com> Message-ID: <50730657.1020409@jugs.org> Am 08.10.2012 17:41, schrieb joe andresen: > To be exact something like this > > |// Add camera to scene graph (so it can move)| > |Group cameraGroup = ||new| |Group();| > |cameraGroup.getChildren().add(camera);| > |root.getChildren().add(cameraGroup); > > ImaveView imageView = new ImageView(...); > cameraGroup.getChildren().add(||imageView||); > > //transform cameraGroup to transform camera and billboards. No, this is not the behaviour of a billboard. Bilboard and camera can move independently of each other. Only the orientation of the bilboard is always in the direction towards the camera. > > > > > | > > > On 10/8/2012 7:53 AM, Kevin Rushforth wrote: >> > As for Billboard node: it is the ImageView class. >> >> That isn't sufficient. A BillBoard node is one that always orients >> itself towards the viewer regardless of the position and orientation >> of the camera. This is unplanned for FX 8. >> >> -- Kevin >> >> >> Kirill Prazdnikov wrote: >>> Hi, >>> >>> Lets wait for more detailed API review. >>> There will be room for more concrete API questions. >>> >>> As for Billboard node: it is the ImageView class. >>> >>> -Kirill >>> >>> On 10/8/2012 5:43 PM, Pedro Duque Vieira wrote: >>>> What about the lightning thing I talked about (2 point)? I can't >>>> really >>>> understand why that type of light is missing.. >>>> >>>> I remembered one more thing: a Billboard node would be useful. >>>> >>>> Thanks, best regards, >>>> >>>> >>>> Hi, >>>>> Yes, we will introduce a new group with "camera" property. It is >>>>> SubScene: >>>>>> SubScene is a special Node for scene separation >>>>>> It can be used to render part of the Scene with different camera >>>>> As of 3D audio, it is not planned. >>>>> -Kirill >>>>> On 07.10.2012 21:45, Pedro Duque Vieira wrote: >>>>>> Hi, >>>>>> >>>>>> The API looks promising! :) >>>>>> >>>>>> 3 questions: >>>>>> >>>>>> 1. Is it possible to have several cameras in the scene graph? I >>>>> think it >>>>>> would be interesting for some apps. This would allow an app >>>>>> to show >>>>> several >>>>>> views, on different locations, of the same scene graph. >>>>>> 2. If I want to simulate a pervasive light coming from the >>>>>> sky, like >>>>> the >>>>>> Sun, how would I do it with this API? This light would have >>>>>> to be >>>>> located >>>>>> upward at an infinite distance. Isn't a thing like a >>>>>> "Directional >>>>> Light" >>>>>> missing on this API? >>>>>> 3. Will there be an audio node? I imagine, for instance, >>>>>> attaching an >>>>>> audio clip of the sound of a motor engine to a car. The >>>>>> sound would >>>>> than be >>>>>> louder or quieter depending on the distance of the audio >>>>>> node to the >>>>> camera. >>>>>> Just my 0.02?. Cheers, >>> > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From joseph.andresen at oracle.com Mon Oct 8 10:01:08 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Mon, 08 Oct 2012 10:01:08 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: References: Message-ID: <507306D4.8090101@oracle.com> On 10/8/2012 9:46 AM, Pedro Duque Vieira wrote: > ImageView is a Billboard node you're > saying that in 3D it is always oriented towards the camera? Shouldn't that > be a property of ImageView rather than a automatic behavior? I did not say that a imageview IS a billboard, and i also did not say that "in 3d" it is always oriented towards the camera. Remember, JavaFX Nodes can take 3D transforms right now. I do not think there is a notion of "3D or 2D" for an ImageView. The previous example code shows how an image view could behave (possibly if the transforms work like i think they do) LIKE a billboard. You could test this in 2.2 kind of, but you wouldn't be able to see the actual results i think. (since cameras don't move yet) From tbee at tbee.org Mon Oct 8 10:08:16 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 08 Oct 2012 19:08:16 +0200 Subject: property improvement suggestion In-Reply-To: <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> References: <50712B02.8040306@tbee.org> <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> Message-ID: <50730880.6080307@tbee.org> Hmmmm, not sure we are on the same line here. The essence of the proposal is that the user of a property can specify a constraint. Let's see how I can make a good argument for this. There are two angles. The first being the binding; I recently recoded my Agenda (Google Calendar) control to use binding and really liked that, but I ran into some omissions IMHO. Suppose I bind an appointment height to the duration of the appointment. So, basically you get something like: appointment.duration().bind(area.height().multiply(pixelToSecondsFactor)); A UI feature is that the user can resize an area by dragging the end time (bottom of the rectangle) with the mouse. Theoretically he can drag the mouse above the start time, resulting in a negative height. The binding will then result in a negative duration, and that is something I do not want. The problem is that I am not the owner of the appointment (it comes from the business model), nor the owner of the area (it's a rectangle; and even if I extend Rectangle, I cannot extend the height property). So I need a way to prevent that situation to occur, because the BM code handling the appointment will never expect a negative duration, or an end time that falls before the start time (the constraints of the BM entity :-). Because the binding allows calculation, it almost requires constraints, or a decent hook system. Or I must find a way to get a man-in-the-middle setup (I did that with JGoodies binding), but native constraints are better. The second angle is that the properties concept is a powerful one, and I expect them to become popular in none JavaFX contexts as well. Formal properties is something the community have been begging for for a long time. These other context, say a mortgage business model, may be less lenient towards the possible values a property can have and require a strict handling of the values, and maybe (yes) throw exceptions. Further more these constraints may be fairly complex, so a simple "if a then b" might not cut it. So if we're contemplating constraints, then let's look at the bigger picture. Now, I'm not knowledgable enough on the implementation that I can discuss the implementation details, but I understand the problem of the lazy binding your describing. Maybe, in light of the bigger picture, eager bindings are important. I only know that being able to hook into binding to make sure a value never goes out of range, both directly on a property (as a permanent constraint) or inside a binding chain (as a local constraint), seems like a very natural thing. Tom On 2012-10-08 16:26, Richard Bair wrote: > It looks like there are two elements of this proposal. The first is that the author of a bean might want to specify some inherent constraint > on the property -- such as, it should never be null, or it should never be negative. The second is that a user of the property might want to constrain the property in some way -- such as, in my app the width should never be negative. > > I see the value immediately in the first (in fact, this has always been a problem with our properties, going all the way back to JavaFX Script), but I struggle to see much value in the second. Not because you might not want to do this sort of thing, but because the first (inherent constraints) is not presently possible at all, while the second (app constraints) you can already do in your application code, one way or another. I am inclined not to add API for cases that are already solvable, unless it turns out to be so compelling and widely used. > > From a semantic point of view, binding was a "mathematical" relationship between two properties in JavaFX Script, such that when you read code like: > > x: bind 10 * someProperty > > you new that "x" was going to be 10 * someProperty, and not anything else. Of course as an API designer I have never liked that because I have to handle exceptional conditions in my code rather than being able to verify that a property can never go outside its valid range of values. > > I am pleased to see your proposal doesn't include throwing exceptions -- I think throwing an exception from a property on invalid input is a very bad idea. The problem is in lazy evaluation of properties. Suppose: > > widthProperty().bind(someProperty) > > Further suppose width is constrained to never be < 0, and somebody were to try to set it to be < 0 it would throw an exception. In this case, someProperty might be set to -10 at some time, and the width property is invalidated. But until somebody tries to read width, it won't throw the exception. So the problem with bound properties & exceptions is that the exception is not thrown at the time the error is introduced, but rather at the time the error is discovered, which turns out to be an awful behavior. > > However your proposal instead says "if it is outside the allowable range, I will just adjust the value to keep it within the allowable range". I think this is a really good idea. The property implementations would have to be modified such that on read, instead of: > > /** > * {@inheritDoc} > */ > @Override > public boolean get() { > valid = true; > return observable == null ? value : observable.get(); > } > > we instead do something like: > > /** > * {@inheritDoc} > */ > @Override > public boolean get() { > if (!valid && observable != null) { > value = constrain(observable.get()); > } > valid = true; > return observable == null ? value : observable.get(); > } > > > And add a protected 'constrain' method. Or perhaps we can just call the "set" method and let the set method deal with constraining. This would require taking some care, however, because it means set methods will now be called even when the property is bound which is different than at present, and calling super.set() would throw an exception in the case that it is bound. But still, as a Java developer I'm used to doing constraining from within the setter, so doing it inside the set seems the most natural, but this would be an area that needs to be figured out. > > Richard > > On Oct 7, 2012, at 12:10 AM, Tom Eugelink wrote: > >> As far as I understand, the current the approach is that properties should accept any value, and the usage of these properties have to work with that. Personally I'm prefer a different approach, because I feel the responsibility to have sensible values should be constrained to one place. Therefore I often override the set method of my properties to make sure the value is within the range that my remaining code expect it to be; either by throwing an exception or by clamping the value to a range. >> >> But this I can only do with my own properties. It would be nice to also do this to existing properties and therefor I would like to suggest to extend the property concept with constraints or conditions. The important point being that these constraints are applied before the value is set, and not (like a change listener approach) afterwards and then correct value; a value should never be outside it allowed range. >> >> The constraints or conditions could have an if-then structure: if value < 0 then 0. An example in Java 8 lambda notation: >> someNode.widthProperty().*constraint*( w -> w < 0, 0); >> >> This would also be something relevant to binding, especially when doing calculations: >> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); >> >> There is a difference between a permanent constraint on the property and a constraint only applicable to a binding. The notation above is is too similar to my taste and too easily a binding constraint can become a property constaint. To make this difference more explicit, the word "if" could be better on binding: >> someNode.widthProperty().*constraint*( w -> w < 0, 0); >> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); >> >> Something to think about is how far these constraints should be taken. These are simple if-then constraints. But what if "else", "elsif" constructions or "case" statements are needed to express the range? In order to keep all options open, maybe the best approach would be to provide constraining listeners. A constraining listener would get the to-be-set value as a parameter and return the new value. For example: >> >> widthProperty.addConstrainingListener( v -> { if (v < 0.0) return 0.0; return v; } ); >> >> or in normal notation: >> >> widthProperty.addConstrainingListener( new ConstaintListener() { >> public Double constaint(Double value) { >> if (value < 0.0) return 0.0; >> return value; >> } >> }); >> >> (NB: I'm not sure how to use Java 8 lambda with the addListener method, differentiating between a change, invalidation and constraint listener.) >> >> This constraining listener approach would allow for all scenario's to be handled. So that is the final improvement I would like to suggest: constrainting listeners. >> someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return 0.0; return v; } ); >> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) return 0.0; return v; } ) ); >> >> And if possible normal constraints, because that is a easier notation. >> >> I'd like to hear if I'm making sense or am missing the ball completely. >> >> Tom From richard.bair at oracle.com Mon Oct 8 10:19:36 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 8 Oct 2012 10:19:36 -0700 Subject: Quarterly Project Report Message-ID: <051CABA6-8F6F-4BFC-9D20-4A2AAFEAC948@oracle.com> This is the first quarterly project report for OpenJFX, which according to the bylaws I'm supposed to produce every 3 months. Better late than never ;-). The OpenJFX project is moving along. We have been steadily building what I think is good interaction with the community. We've had invaluable feedback from many of you on a range of API designs and topics over the past year, for which we are truly grateful and, I think bodes well for the value of the project and the community in the future. We have open sourced all of the UI Controls and much of the Scene Graph, CSS, and related APIs. As per the recent announcement at JavaOne, we're going to be opening sourcing the rest over the course of the next few months. Our project has an open JIRA issue database and, except for security issues, nearly everything is available to the public. I think on the Issue Tracking part of the project things are going quite well. One thing that we have not done well and need to improve on is taking Issue Votes into serious consideration when planning the next release. You should feel confident that your votes, and voices, are heard. As such, I'm personally committed to making sure the TreeTableView control makes it into JavaFX 8, as this is the second-highest voted for JIRA issue. Our website, build instructions, build infrastructure, IDE support, and so forth are really bad right now. Jasper is working on a design for our website and we are making sure the wiki (https://wikis.oracle.com/display/OpenJDK/OpenJFX) is redesigned and organized and chock full of useful information. I'm working on our build infrastructure so that somebody can within minutes be up and running within their favorite IDE, whereas right now it is quite complicated to get a build setup. This is especially true when the rest of the platform is open sourced. It is usually a several day task for somebody new to the project to get a build fully setup and working, and even longer before they figure out how to be efficient at building / testing. This is clearly unacceptable because it doesn't scale and would be prohibitive for members of the community to be able to contribute. Getting contributions from the community remains a very important milestone for the project. I do not expect to see many patches until we've succeeded in setting up a build / contribution system which is easy and provides nearly immediate satisfaction. I will be working hard over the next several months to make this a reality. Richard Bair From pedro.duquevieira at gmail.com Mon Oct 8 10:30:54 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 8 Oct 2012 18:30:54 +0100 Subject: 3D Features Planned for Version 8 Message-ID: Hi Joe, Was not talking to you, I was talking to Kirill who said ImageView was a Billboard. Thanks, On 10/8/2012 9:46 AM, Pedro Duque Vieira wrote: > > ImageView is a Billboard node you're > > saying that in 3D it is always oriented towards the camera? Shouldn't > that > > be a property of ImageView rather than a automatic behavior? > I did not say that a imageview IS a billboard, and i also did not say > that "in 3d" it is always oriented towards the camera. > Remember, JavaFX Nodes can take 3D transforms right now. I do not think > there is a notion of "3D or 2D" for an ImageView. > The previous example code shows how an image view could behave (possibly > if the transforms work like i think they do) LIKE a billboard. > You could test this in 2.2 kind of, but you wouldn't be able to see the > actual results i think. (since cameras don't move yet) -- Pedro Duque Vieira From joseph.andresen at oracle.com Mon Oct 8 10:52:42 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Mon, 08 Oct 2012 10:52:42 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <50730657.1020409@jugs.org> References: <5072D947.5080505@oracle.com> <5072E8E3.8080504@oracle.com> <5072F43D.8070903@oracle.com> <50730657.1020409@jugs.org> Message-ID: <507312EA.3060409@oracle.com> On 10/8/2012 9:59 AM, Dr. Michael Paus wrote: > Am 08.10.2012 17:41, schrieb joe andresen: >> To be exact something like this >> >> |// Add camera to scene graph (so it can move)| >> |Group cameraGroup = ||new| |Group();| >> |cameraGroup.getChildren().add(camera);| >> |root.getChildren().add(cameraGroup); >> >> ImaveView imageView = new ImageView(...); >> cameraGroup.getChildren().add(||imageView||); >> >> //transform cameraGroup to transform camera and billboards. > No, this is not the behaviour of a billboard. Bilboard and camera > can move independently of each other. Only the orientation of > the bilboard is always in the direction towards the camera. That ImageView can still be transformed independently..... From joseph.andresen at oracle.com Mon Oct 8 10:53:23 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Mon, 08 Oct 2012 10:53:23 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: References: Message-ID: <50731313.5000202@oracle.com> Ah I see, no worries! -J On 10/8/2012 10:30 AM, Pedro Duque Vieira wrote: > Hi Joe, > > Was not talking to you, I was talking to Kirill who said ImageView was a > Billboard. > > Thanks, > > > On 10/8/2012 9:46 AM, Pedro Duque Vieira wrote: >>> ImageView is a Billboard node you're >>> saying that in 3D it is always oriented towards the camera? Shouldn't >> that >>> be a property of ImageView rather than a automatic behavior? >> I did not say that a imageview IS a billboard, and i also did not say >> that "in 3d" it is always oriented towards the camera. >> Remember, JavaFX Nodes can take 3D transforms right now. I do not think >> there is a notion of "3D or 2D" for an ImageView. >> The previous example code shows how an image view could behave (possibly >> if the transforms work like i think they do) LIKE a billboard. >> You could test this in 2.2 kind of, but you wouldn't be able to see the >> actual results i think. (since cameras don't move yet) > From hang.vo at oracle.com Mon Oct 8 12:48:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 08 Oct 2012 19:48:06 +0000 Subject: hg: openjfx/8/controls/rt: Removed tests that are not doing anything. Message-ID: <20121008194812.D1A074721F@hg.openjdk.java.net> Changeset: fe99329cd02e Author: rbair Date: 2012-10-08 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fe99329cd02e Removed tests that are not doing anything. - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlicesTest.java - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlices_builder_Test.java From pedro.duquevieira at gmail.com Mon Oct 8 13:23:30 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 8 Oct 2012 21:23:30 +0100 Subject: Quarterly Project Report Message-ID: Hi Richard, I think you're absolutely right! Having a Zip of the source code of JavaFX would also be a nice, I think. It would be the easiest way to get a glimpse of the code. It wouldn't require anyone to set up or learn the specific source control used by the javafx team. Thanks, best regards, > This is the first quarterly project report for OpenJFX, which according to > the bylaws I'm supposed to produce every 3 months. Better late than never > ;-). > The OpenJFX project is moving along. We have been steadily building what I > think is good interaction with the community. We've had invaluable feedback > from many of you on a range of API designs and topics over the past year, > for which we are truly grateful and, I think bodes well for the value of > the project and the community in the future. We have open sourced all of > the UI Controls and much of the Scene Graph, CSS, and related APIs. As per > the recent announcement at JavaOne, we're going to be opening sourcing the > rest over the course of the next few months. > Our project has an open JIRA issue database and, except for security > issues, nearly everything is available to the public. I think on the Issue > Tracking part of the project things are going quite well. One thing that we > have not done well and need to improve on is taking Issue Votes into > serious consideration when planning the next release. You should feel > confident that your votes, and voices, are heard. As such, I'm personally > committed to making sure the TreeTableView control makes it into JavaFX 8, > as this is the second-highest voted for JIRA issue. > Our website, build instructions, build infrastructure, IDE support, and so > forth are really bad right now. Jasper is working on a design for our > website and we are making sure the wiki ( > https://wikis.oracle.com/display/OpenJDK/OpenJFX) is redesigned and > organized and chock full of useful information. I'm working on our build > infrastructure so that somebody can within minutes be up and running within > their favorite IDE, whereas right now it is quite complicated to get a > build setup. This is especially true when the rest of the platform is open > sourced. It is usually a several day task for somebody new to the project > to get a build fully setup and working, and even longer before they figure > out how to be efficient at building / testing. This is clearly unacceptable > because it doesn't scale and would be prohibitive for members of the > community to be able to contribute. > Getting contributions from the community remains a very important > milestone for the project. I do not expect to see many patches until we've > succeeded in setting up a build / contribution system which is easy and > provides nearly immediate satisfaction. I will be working hard over the > next several months to make this a reality. > Richard Bair -- Pedro Duque Vieira From richard.bair at oracle.com Mon Oct 8 13:25:37 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 8 Oct 2012 13:25:37 -0700 Subject: Quarterly Project Report In-Reply-To: References: Message-ID: <81FA26FA-B1E2-44C3-8FDB-06C6E72E7B32@oracle.com> That's what I was thinking as well. Have a zip, download, open in your IDE, hit run. Any more complicated than that is a #fail On Oct 8, 2012, at 1:23 PM, Pedro Duque Vieira wrote: > Hi Richard, > > I think you're absolutely right! > > Having a Zip of the source code of JavaFX would also be a nice, I think. It > would be the easiest way to get a glimpse of the code. It wouldn't require > anyone to set up or learn the specific source control used by the javafx > team. > > Thanks, best regards, > > >> This is the first quarterly project report for OpenJFX, which according to >> the bylaws I'm supposed to produce every 3 months. Better late than never >> ;-). >> The OpenJFX project is moving along. We have been steadily building what I >> think is good interaction with the community. We've had invaluable feedback >> from many of you on a range of API designs and topics over the past year, >> for which we are truly grateful and, I think bodes well for the value of >> the project and the community in the future. We have open sourced all of >> the UI Controls and much of the Scene Graph, CSS, and related APIs. As per >> the recent announcement at JavaOne, we're going to be opening sourcing the >> rest over the course of the next few months. >> Our project has an open JIRA issue database and, except for security >> issues, nearly everything is available to the public. I think on the Issue >> Tracking part of the project things are going quite well. One thing that we >> have not done well and need to improve on is taking Issue Votes into >> serious consideration when planning the next release. You should feel >> confident that your votes, and voices, are heard. As such, I'm personally >> committed to making sure the TreeTableView control makes it into JavaFX 8, >> as this is the second-highest voted for JIRA issue. >> Our website, build instructions, build infrastructure, IDE support, and so >> forth are really bad right now. Jasper is working on a design for our >> website and we are making sure the wiki ( >> https://wikis.oracle.com/display/OpenJDK/OpenJFX) is redesigned and >> organized and chock full of useful information. I'm working on our build >> infrastructure so that somebody can within minutes be up and running within >> their favorite IDE, whereas right now it is quite complicated to get a >> build setup. This is especially true when the rest of the platform is open >> sourced. It is usually a several day task for somebody new to the project >> to get a build fully setup and working, and even longer before they figure >> out how to be efficient at building / testing. This is clearly unacceptable >> because it doesn't scale and would be prohibitive for members of the >> community to be able to contribute. >> Getting contributions from the community remains a very important >> milestone for the project. I do not expect to see many patches until we've >> succeeded in setting up a build / contribution system which is easy and >> provides nearly immediate satisfaction. I will be working hard over the >> next several months to make this a reality. >> Richard Bair > > > -- > Pedro Duque Vieira From kevin.rushforth at oracle.com Mon Oct 8 14:35:17 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Oct 2012 14:35:17 -0700 Subject: Quarterly Project Report In-Reply-To: <81FA26FA-B1E2-44C3-8FDB-06C6E72E7B32@oracle.com> References: <81FA26FA-B1E2-44C3-8FDB-06C6E72E7B32@oracle.com> Message-ID: <50734715.2020708@oracle.com> Note that this is planned for FX 8: http://javafx-jira.kenai.com/browse/RT-21415 -- Kevin but requires some work before Richard Bair wrote: > That's what I was thinking as well. Have a zip, download, open in your IDE, hit run. Any more complicated than that is a #fail > > On Oct 8, 2012, at 1:23 PM, Pedro Duque Vieira wrote: > > >> Hi Richard, >> >> I think you're absolutely right! >> >> Having a Zip of the source code of JavaFX would also be a nice, I think. It >> would be the easiest way to get a glimpse of the code. It wouldn't require >> anyone to set up or learn the specific source control used by the javafx >> team. >> >> Thanks, best regards, >> >> >> >>> This is the first quarterly project report for OpenJFX, which according to >>> the bylaws I'm supposed to produce every 3 months. Better late than never >>> ;-). >>> The OpenJFX project is moving along. We have been steadily building what I >>> think is good interaction with the community. We've had invaluable feedback >>> from many of you on a range of API designs and topics over the past year, >>> for which we are truly grateful and, I think bodes well for the value of >>> the project and the community in the future. We have open sourced all of >>> the UI Controls and much of the Scene Graph, CSS, and related APIs. As per >>> the recent announcement at JavaOne, we're going to be opening sourcing the >>> rest over the course of the next few months. >>> Our project has an open JIRA issue database and, except for security >>> issues, nearly everything is available to the public. I think on the Issue >>> Tracking part of the project things are going quite well. One thing that we >>> have not done well and need to improve on is taking Issue Votes into >>> serious consideration when planning the next release. You should feel >>> confident that your votes, and voices, are heard. As such, I'm personally >>> committed to making sure the TreeTableView control makes it into JavaFX 8, >>> as this is the second-highest voted for JIRA issue. >>> Our website, build instructions, build infrastructure, IDE support, and so >>> forth are really bad right now. Jasper is working on a design for our >>> website and we are making sure the wiki ( >>> https://wikis.oracle.com/display/OpenJDK/OpenJFX) is redesigned and >>> organized and chock full of useful information. I'm working on our build >>> infrastructure so that somebody can within minutes be up and running within >>> their favorite IDE, whereas right now it is quite complicated to get a >>> build setup. This is especially true when the rest of the platform is open >>> sourced. It is usually a several day task for somebody new to the project >>> to get a build fully setup and working, and even longer before they figure >>> out how to be efficient at building / testing. This is clearly unacceptable >>> because it doesn't scale and would be prohibitive for members of the >>> community to be able to contribute. >>> Getting contributions from the community remains a very important >>> milestone for the project. I do not expect to see many patches until we've >>> succeeded in setting up a build / contribution system which is easy and >>> provides nearly immediate satisfaction. I will be working hard over the >>> next several months to make this a reality. >>> Richard Bair >>> >> -- >> Pedro Duque Vieira >> > > From John_Smith at symantec.com Mon Oct 8 15:30:06 2012 From: John_Smith at symantec.com (John Smith) Date: Mon, 8 Oct 2012 15:30:06 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <506F0DDD.9060708@oracle.com> References: <506F0DDD.9060708@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221601A2294A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Thanks for making the info public Chien. 1. Will I be able to subclass Material to create my own material types? 2. If so, what could I reasonably expect these custom Materials to be capable of? 3. Will I be able to create custom shaders which make use of the shading hardware on the GPU? And if so, how would this be done? I think you would be able to implement a wide variety of 3D related use cases in JavaFX 3D if it provided a clean API with a similar feature set (and ease of use) to the three.js library: http://en.wikipedia.org/wiki/Three.js#Features http://aerotwist.com/tutorials/ In providing such a feature set, a JavaFX 3D API would at appear to be feature comparable to WebGL, which I think is one of the comparison points that somebody evaluating the API would have. The planned features on the wiki go a fair way towards implementing a lot of the base functionality required to make this happen. Obviously, a complete implementation of such a feature set is not in scope for JDK8, but it would be interesting to know what is planned for the future with regards to JavaFX and 3D. Regards, John -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang Sent: Friday, October 05, 2012 9:42 AM To: OpenJFX Subject: 3D Features Planned for Version 8 Hi all, We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. https://wikis.oracle.com/display/OpenJDK/3D+Features Please let us know if you have any suggestions or concerns. Regards, - Chien Yang JavaFX Graphics Team From joseph.andresen at oracle.com Mon Oct 8 20:45:12 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Mon, 8 Oct 2012 20:45:12 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221601A2294A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <506F0DDD.9060708@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601A2294A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Shaders are post fx8 On Oct 8, 2012, at 3:30 PM, John Smith wrote: > Thanks for making the info public Chien. > > 1. Will I be able to subclass Material to create my own material types? > 2. If so, what could I reasonably expect these custom Materials to be capable of? > 3. Will I be able to create custom shaders which make use of the shading hardware on the GPU? And if so, how would this be done? > > I think you would be able to implement a wide variety of 3D related use cases in JavaFX 3D if it provided a clean API with a similar feature set (and ease of use) to the three.js library: > http://en.wikipedia.org/wiki/Three.js#Features > http://aerotwist.com/tutorials/ > In providing such a feature set, a JavaFX 3D API would at appear to be feature comparable to WebGL, which I think is one of the comparison points that somebody evaluating the API would have. The planned features on the wiki go a fair way towards implementing a lot of the base functionality required to make this happen. Obviously, a complete implementation of such a feature set is not in scope for JDK8, but it would be interesting to know what is planned for the future with regards to JavaFX and 3D. > > Regards, > John > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang > Sent: Friday, October 05, 2012 9:42 AM > To: OpenJFX > Subject: 3D Features Planned for Version 8 > > Hi all, > > We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. > This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. > > https://wikis.oracle.com/display/OpenJDK/3D+Features > > Please let us know if you have any suggestions or concerns. > > Regards, > > - Chien Yang > JavaFX Graphics Team From ozemale at ozemail.com.au Mon Oct 8 23:24:45 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Tue, 9 Oct 2012 17:24:45 +1100 Subject: No JavaFX for iOS, Android or WP - why not? Message-ID: <005101cda5e6$c6d7b960$54872c20$@com.au> I didn't have the pleasure of being at JavaOne but in a blog by Lucas Jellema (and retweeted by Nicolas Lorain) the following is stated: "JavaFX is no longer intended for use on SmartPhones. The iPhone, Android and Windows Mobile phones are provided by the respective platforms, there is no room there for JavaFX. JavaFX is targeted at the desktop to replace Swing and at smaller devices that run embedded Java." This is extremely disappointing especially after having seen demos of JavaFX running on iOS and Android devices. Can someone explain why this decision has been made? Thanks, -jct From zonski at gmail.com Mon Oct 8 23:39:43 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 9 Oct 2012 17:39:43 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <005101cda5e6$c6d7b960$54872c20$@com.au> References: <005101cda5e6$c6d7b960$54872c20$@com.au> Message-ID: Bad, bad news. Is it true? On Tue, Oct 9, 2012 at 5:24 PM, John C. Turnbull wrote: > I didn't have the pleasure of being at JavaOne but in a blog by Lucas > Jellema (and retweeted by Nicolas Lorain) the following is stated: > > > > "JavaFX is no longer intended for use on SmartPhones. The iPhone, Android > and Windows Mobile phones are provided by the respective platforms, there > is > no room there for JavaFX. JavaFX is targeted at the desktop to replace > Swing > and at smaller devices that run embedded Java." > > > > This is extremely disappointing especially after having seen demos of > JavaFX > running on iOS and Android devices. > > > > Can someone explain why this decision has been made? > > > > Thanks, > > > > -jct > > From tbee at tbee.org Mon Oct 8 23:46:25 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 09 Oct 2012 08:46:25 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> Message-ID: <5073C841.3040007@tbee.org> Wow. That indeed would be very bad news! Tom On 2012-10-09 08:39, Daniel Zwolenski wrote: > Bad, bad news. Is it true? > > > On Tue, Oct 9, 2012 at 5:24 PM, John C. Turnbull wrote: > >> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >> Jellema (and retweeted by Nicolas Lorain) the following is stated: >> >> >> >> "JavaFX is no longer intended for use on SmartPhones. The iPhone, Android >> and Windows Mobile phones are provided by the respective platforms, there >> is >> no room there for JavaFX. JavaFX is targeted at the desktop to replace >> Swing >> and at smaller devices that run embedded Java." >> >> >> >> This is extremely disappointing especially after having seen demos of >> JavaFX >> running on iOS and Android devices. >> >> >> >> Can someone explain why this decision has been made? >> >> >> >> Thanks, >> >> >> >> -jct >> >> From zonski at gmail.com Tue Oct 9 00:06:05 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 9 Oct 2012 18:06:05 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> Message-ID: Here's the full article: http://technology.amis.nl/2012/10/08/javaone-2012-the-big-stories/ The section on JavaFX contains the quote that John provided. Reading through this article is very sad in a lot of ways. It would be good to know the opinion of the JFX team on this article and how much of this is a reflection of the official Oracle/JFX stance. "Oracle sees HTML 5 as the way forward for browser based applications" i.e. 90% of the applications out there? Leaving JFX only worth the hassle for pure desktop apps? Why bother, especially when HTML5 can do most of the things JFX can (in some cases it can do more), plus it deploys cross-platform easily and it works well enough on popular SmartDevices? "One of the big things happening right now obviously is HTML 5. Bringing rich graphics, animation and interactivity to the browser renders the Java Applet (as well as Flash and Silverlight plugins) rather obsolete. HTML 5 runs on all kinds of devices, from Desktop browser, tablet all the way to mobile devices. Rich and interactive applications using a cross platform/cross device technology: HTML 5 (along with CSS 3 and JavaScript and typically introducing Web Sockets as well) is a winner." If HTML5 is the "big thing" that is "bringing rich graphics, animation and interactivity", what's JFX then? On Tue, Oct 9, 2012 at 5:39 PM, Daniel Zwolenski wrote: > Bad, bad news. Is it true? > > > On Tue, Oct 9, 2012 at 5:24 PM, John C. Turnbull wrote: > >> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >> Jellema (and retweeted by Nicolas Lorain) the following is stated: >> >> >> >> "JavaFX is no longer intended for use on SmartPhones. The iPhone, Android >> and Windows Mobile phones are provided by the respective platforms, there >> is >> no room there for JavaFX. JavaFX is targeted at the desktop to replace >> Swing >> and at smaller devices that run embedded Java." >> >> >> >> This is extremely disappointing especially after having seen demos of >> JavaFX >> running on iOS and Android devices. >> >> >> >> Can someone explain why this decision has been made? >> >> >> >> Thanks, >> >> >> >> -jct >> >> > From tobi at ultramixer.com Tue Oct 9 00:10:04 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 9 Oct 2012 09:10:04 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <005101cda5e6$c6d7b960$54872c20$@com.au> References: <005101cda5e6$c6d7b960$54872c20$@com.au> Message-ID: <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> Hi guys, first of all: that's not an official press release of Oracle... second: please take part of the current discussion on JavaFX forum about "JavaFX on iOS, Android and Windows 8": https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 Richard Bair there asked for developers and companies who have a real (commercial) interested in using JavaFX on iOS.... So please please write Richard an email to show him your real interested. Best regards, Tobi blog.software4java.com Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : > I didn't have the pleasure of being at JavaOne but in a blog by Lucas > Jellema (and retweeted by Nicolas Lorain) the following is stated: > > > > "JavaFX is no longer intended for use on SmartPhones. The iPhone, Android > and Windows Mobile phones are provided by the respective platforms, there is > no room there for JavaFX. JavaFX is targeted at the desktop to replace Swing > and at smaller devices that run embedded Java." > > > > This is extremely disappointing especially after having seen demos of JavaFX > running on iOS and Android devices. > > > > Can someone explain why this decision has been made? > > > > Thanks, > > > > -jct > From chien.yang at oracle.com Tue Oct 9 00:52:28 2012 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 09 Oct 2012 00:52:28 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221601A2294A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <506F0DDD.9060708@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601A2294A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <5073D7BC.9030802@oracle.com> Hi John, Good questions. We have evaluated both user subclassing of Material and custom shader during our 3D features meeting. They do not belong to the "must have" list in our use case study, and they require certain design tradeoff and investment work that we aren't ready to commit for JavaFX 8. - Chien On 10/8/2012 3:30 PM, John Smith wrote: > Thanks for making the info public Chien. > > 1. Will I be able to subclass Material to create my own material types? > 2. If so, what could I reasonably expect these custom Materials to be capable of? > 3. Will I be able to create custom shaders which make use of the shading hardware on the GPU? And if so, how would this be done? > > I think you would be able to implement a wide variety of 3D related use cases in JavaFX 3D if it provided a clean API with a similar feature set (and ease of use) to the three.js library: > http://en.wikipedia.org/wiki/Three.js#Features > http://aerotwist.com/tutorials/ > In providing such a feature set, a JavaFX 3D API would at appear to be feature comparable to WebGL, which I think is one of the comparison points that somebody evaluating the API would have. The planned features on the wiki go a fair way towards implementing a lot of the base functionality required to make this happen. Obviously, a complete implementation of such a feature set is not in scope for JDK8, but it would be interesting to know what is planned for the future with regards to JavaFX and 3D. > > Regards, > John > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang > Sent: Friday, October 05, 2012 9:42 AM > To: OpenJFX > Subject: 3D Features Planned for Version 8 > > Hi all, > > We have been thinking about the possible 3D features for JavaFX 8 for a while. We are now ready to present the plan to the community for review. > This information has also been presented at this year's JavaOne "3D Made Easy with JavaFX" technical session. > > https://wikis.oracle.com/display/OpenJDK/3D+Features > > Please let us know if you have any suggestions or concerns. > > Regards, > > - Chien Yang > JavaFX Graphics Team From ozemale at ozemail.com.au Tue Oct 9 01:18:07 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Tue, 9 Oct 2012 19:18:07 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> Message-ID: <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Hi Tobi, I realise it's not an official Oracle statement but that's part of the problem; Oracle didn't make an official statement on this at JavaOne when I suspect many people were hoping for one. In fact, I seem to remember a session titled something like "JavaFX on iOS" was being tossed around for possible inclusion in this year's JavaOne some time ago. It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet Oracle are waiting for clear commercial interest to justify such support? As has been pointed out several times, JavaFX cannot be considered a success if it is limited to the scope of the desktop and perhaps some embedded devices. Many predict that the PC in its current form will largely disappear in the next 5 years so where would that leave JavaFX? Java developers are largely passionate about their language and do not want to learn Objective C or C# or whatever language is required on each device. In my opinion, being able to code in Java and deploy to Windows, Linux, MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as the best platform for client side software development on the planet. Please Oracle, don't miss this enormous opportunity! What do we have to do to convince you that this REALLY IS A GOOD IDEA? -jct -----Original Message----- From: Tobias Bley [mailto:tobi at ultramixer.com] Sent: Tuesday, 9 October 2012 18:10 To: John C. Turnbull Cc: openjfx-dev at openjdk.java.net Subject: Re: No JavaFX for iOS, Android or WP - why not? Hi guys, first of all: that's not an official press release of Oracle... second: please take part of the current discussion on JavaFX forum about "JavaFX on iOS, Android and Windows 8": https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 Richard Bair there asked for developers and companies who have a real (commercial) interested in using JavaFX on iOS.... So please please write Richard an email to show him your real interested. Best regards, Tobi blog.software4java.com Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : > I didn't have the pleasure of being at JavaOne but in a blog by Lucas > Jellema (and retweeted by Nicolas Lorain) the following is stated: > > > > "JavaFX is no longer intended for use on SmartPhones. The iPhone, > Android and Windows Mobile phones are provided by the respective > platforms, there is no room there for JavaFX. JavaFX is targeted at > the desktop to replace Swing and at smaller devices that run embedded Java." > > > > This is extremely disappointing especially after having seen demos of > JavaFX running on iOS and Android devices. > > > > Can someone explain why this decision has been made? > > > > Thanks, > > > > -jct > From tobi at ultramixer.com Tue Oct 9 01:23:02 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 9 Oct 2012 10:23:02 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! John, please write to Richard Bair, he wants to know our opinion about this topic! Best, Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : > Hi Tobi, > > I realise it's not an official Oracle statement but that's part of the > problem; Oracle didn't make an official statement on this at JavaOne when I > suspect many people were hoping for one. In fact, I seem to remember a > session titled something like "JavaFX on iOS" was being tossed around for > possible inclusion in this year's JavaOne some time ago. > > It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet > Oracle are waiting for clear commercial interest to justify such support? > As has been pointed out several times, JavaFX cannot be considered a success > if it is limited to the scope of the desktop and perhaps some embedded > devices. Many predict that the PC in its current form will largely > disappear in the next 5 years so where would that leave JavaFX? > > Java developers are largely passionate about their language and do not want > to learn Objective C or C# or whatever language is required on each device. > > In my opinion, being able to code in Java and deploy to Windows, Linux, > MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as > the best platform for client side software development on the planet. > Please Oracle, don't miss this enormous opportunity! What do we have to do > to convince you that this REALLY IS A GOOD IDEA? > > -jct > > -----Original Message----- > From: Tobias Bley [mailto:tobi at ultramixer.com] > Sent: Tuesday, 9 October 2012 18:10 > To: John C. Turnbull > Cc: openjfx-dev at openjdk.java.net > Subject: Re: No JavaFX for iOS, Android or WP - why not? > > Hi guys, > > first of all: that's not an official press release of Oracle... > > second: please take part of the current discussion on JavaFX forum about > "JavaFX on iOS, Android and Windows 8": > https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 > > Richard Bair there asked for developers and companies who have a real > (commercial) interested in using JavaFX on iOS.... So please please write > Richard an email to show him your real interested. > > Best regards, > Tobi > > blog.software4java.com > > > > Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : > >> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >> Jellema (and retweeted by Nicolas Lorain) the following is stated: >> >> >> >> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >> Android and Windows Mobile phones are provided by the respective >> platforms, there is no room there for JavaFX. JavaFX is targeted at >> the desktop to replace Swing and at smaller devices that run embedded > Java." >> >> >> >> This is extremely disappointing especially after having seen demos of >> JavaFX running on iOS and Android devices. >> >> >> >> Can someone explain why this decision has been made? >> >> >> >> Thanks, >> >> >> >> -jct >> > From randahl at rockit.dk Tue Oct 9 01:44:24 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 9 Oct 2012 10:44:24 +0200 Subject: Support for grouped rendered opacity? Message-ID: <81B3F8A1-F0B0-43C2-8052-69C35FBBB2B2@rockit.dk> Is it possible to change the opacity of a rendered node tree rather than affecting the opacity of each individual node? When I am changing the opacity of a panel with multiple node children, what I am seeing is the individual opacities of each child node changing, which is not what I am aiming for. In one pane I am rendering a 3D house using multiple 2D shapes, and I wish to make the pane fade away by gradually decreasing its opacity; but when I alter the opacity of the pane, what I am seeing is the individual walls of the house becoming semitransparent revealing the geometry of the house. What I was hoping to achieve was to change the opacity of the *rendered* pane. Is that possible? Randahl From lehmann at media-interactive.de Tue Oct 9 03:14:33 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 9 Oct 2012 12:14:33 +0200 Subject: Is there any source code for the JavaFX SceneBuilder? In-Reply-To: <50727F59.5090105@oracle.com> References: <000801cda3fe$b173cf30$145b6d90$@com> <50727F59.5090105@oracle.com> Message-ID: <5073F909.8040508@media-interactive.de> This is also simple to do in Eclipse. The main problem I am having is, how to pass the location of the resource bundle and especially the classpath of my custom controls to SceneBuilder. Without this I am seeing only black boxes (not necessarily black) instead of my custom controls, and resource bundle keys like "%task-dialog-title" instead of "Edit employee task". In my case this classpath would be assembled from the output directories of several dependent projects plus libraries. Tom, is this something you managed to do in e(fx)clipse? Rgds Werner On 08.10.2012 09:23, Jerome Cambon wrote: > Hi Freddy, > > We will provide documentation about Scene Builder integration with > various IDE (Netbeans, Eclipse, IntelliJ) soon. > For IntelliJ IDEA, it is quite easy to launch Scene Builder (SB) from > the IDE, and to build/run the SB samples : > > 1- Launch SB for IntelliJ > - From File->Settings panel, select File Types. Select "Files opened in > associated applications", and add "*.fxml" in the pattern list. > - Double-click an fxml file to edit it with Scene Builder > > 2- Run SB examples > - Create project from existing sources > - In idea/compiler.xml, add the .fxml resource so that the fxml file is > copied in the "out" directory next to .class files > > HTH, > Jerome From hang.vo at oracle.com Tue Oct 9 03:18:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 09 Oct 2012 10:18:56 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-24681: added javadocs Message-ID: <20121009101902.6504C4723B@hg.openjdk.java.net> Changeset: c8deba0d0fb6 Author: Lubomir Nerad Date: 2012-10-09 12:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8deba0d0fb6 Fix for RT-24681: added javadocs ! javafx-ui-common/src/javafx/stage/DirectoryChooser.java ! javafx-ui-common/src/javafx/stage/FileChooser.java From tom.schindl at bestsolution.at Tue Oct 9 03:23:16 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 09 Oct 2012 12:23:16 +0200 Subject: Is there any source code for the JavaFX SceneBuilder? In-Reply-To: <5073F909.8040508@media-interactive.de> References: <000801cda3fe$b173cf30$145b6d90$@com> <50727F59.5090105@oracle.com> <5073F909.8040508@media-interactive.de> Message-ID: <5073FB14.5060005@bestsolution.at> Am 09.10.12 12:14, schrieb Werner Lehmann: > This is also simple to do in Eclipse. The main problem I am having is, > how to pass the location of the resource bundle and especially the > classpath of my custom controls to SceneBuilder. Without this I am > seeing only black boxes (not necessarily black) instead of my custom > controls, and resource bundle keys like "%task-dialog-title" instead of > "Edit employee task". > > In my case this classpath would be assembled from the output directories > of several dependent projects plus libraries. > > Tom, is this something you managed to do in e(fx)clipse? > No. My e(fx)clipse internal preview naturally has all those informations because it knows the classpath of the project. We'd need from the SceneBuilder people an API (once we directly embed the editor) and/or an interchange format to tell them where to search for classes. So if we (Eclipse,Netbeans,SceneBuilder) could work on an interchange format like scenebuilder.classpath ---------------------- this could help you. It is very easy for IDEs to provide something like this. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tobi at ultramixer.com Tue Oct 9 04:25:18 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 9 Oct 2012 13:25:18 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: There are two steps to go: 1. Porting Prism/glass to iOS 2. use AOT compiler Both steps were finished in 2011 yet (http://java.dzone.com/articles/javaone-2011-javafx-20) Am 09.10.2012 um 13:11 schrieb Peter Pilgrim : > Hi > > On the other hand, the whole of JavaFX is going to be open sourced by 2013. > So what it stopping someone porting the lower architecture to iOS? > Therefore one strategy is to wait until the open source is there and > then port it and write the bridging layer between Java and native > Apple libraries, which I guess would be Objective C. I don't know > really. Of course, that would require expertise in Apple native > libraries. Nevertheless it can be done by somebody. The hard part is > bundling a JRE into a form that can run in iOS app store, and also the > pass by the gatekeeper. > > On 9 October 2012 01:23, Tobias Bley wrote: >> John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! >> >> John, please write to Richard Bair, he wants to know our opinion about this topic! >> >> Best, >> Tobi >> >> >> -- >> Tobias Bley >> Chief Executive Officer >> >> -------------------------------------------------------- >> >> UltraMixer Digital Audio Solutions >> Schillerstra?e 29 >> D-01326 Dresden >> Germany >> >> -------------------------------------------------------- >> bley at ultramixer.com http://www.ultramixer.com >> >> >> >> Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : >> >>> Hi Tobi, >>> >>> I realise it's not an official Oracle statement but that's part of the >>> problem; Oracle didn't make an official statement on this at JavaOne when I >>> suspect many people were hoping for one. In fact, I seem to remember a >>> session titled something like "JavaFX on iOS" was being tossed around for >>> possible inclusion in this year's JavaOne some time ago. >>> >>> It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet >>> Oracle are waiting for clear commercial interest to justify such support? >>> As has been pointed out several times, JavaFX cannot be considered a success >>> if it is limited to the scope of the desktop and perhaps some embedded >>> devices. Many predict that the PC in its current form will largely >>> disappear in the next 5 years so where would that leave JavaFX? >>> >>> Java developers are largely passionate about their language and do not want >>> to learn Objective C or C# or whatever language is required on each device. >>> >>> In my opinion, being able to code in Java and deploy to Windows, Linux, >>> MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as >>> the best platform for client side software development on the planet. >>> Please Oracle, don't miss this enormous opportunity! What do we have to do >>> to convince you that this REALLY IS A GOOD IDEA? >>> >>> -jct >>> >>> -----Original Message----- >>> From: Tobias Bley [mailto:tobi at ultramixer.com] >>> Sent: Tuesday, 9 October 2012 18:10 >>> To: John C. Turnbull >>> Cc: openjfx-dev at openjdk.java.net >>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>> >>> Hi guys, >>> >>> first of all: that's not an official press release of Oracle... >>> >>> second: please take part of the current discussion on JavaFX forum about >>> "JavaFX on iOS, Android and Windows 8": >>> https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 >>> >>> Richard Bair there asked for developers and companies who have a real >>> (commercial) interested in using JavaFX on iOS.... So please please write >>> Richard an email to show him your real interested. >>> >>> Best regards, >>> Tobi >>> >>> blog.software4java.com >>> >>> >>> >>> Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : >>> >>>> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >>>> Jellema (and retweeted by Nicolas Lorain) the following is stated: >>>> >>>> >>>> >>>> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >>>> Android and Windows Mobile phones are provided by the respective >>>> platforms, there is no room there for JavaFX. JavaFX is targeted at >>>> the desktop to replace Swing and at smaller devices that run embedded >>> Java." >>>> >>>> >>>> >>>> This is extremely disappointing especially after having seen demos of >>>> JavaFX running on iOS and Android devices. >>>> >>>> >>>> >>>> Can someone explain why this decision has been made? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> -jct >>>> >>> >> > > > > -- > Peter Pilgrim, > **Java Champion**, > Java EE Software Development / Design / Architect for financial > services, London, UK > > JavaFX ++ Scala ++ Groovy ++ Android ++ Java > > :: http://www.xenonique.co.uk/blog/ :: > :: http://twitter.com/peter_pilgrim :: > :: http://audio.fm/profile/peter_pilgrim :: > :: Skype Call peter_pilgrim :: > :: http://java-champions.java.net/ :: From michael.heinrichs at oracle.com Tue Oct 9 05:19:59 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Tue, 9 Oct 2012 14:19:59 +0200 Subject: property improvement suggestion In-Reply-To: <50730880.6080307@tbee.org> References: <50712B02.8040306@tbee.org> <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> <50730880.6080307@tbee.org> Message-ID: <28B1593F-CE88-4387-9193-C34502E29FDE@oracle.com> Hi Tom, in my opinion your first case is already covered by the Binding API itself. The Binding API allows you to define all kind of expressions. For the most common ones there are methods in the JavaFX library and you can always add your own implementation. E.g. you could rewrite your example like this: appointment.duration().bind( when(area.height().greaterThan(0)) .then(area.height().multiply(pixelToSecondsFactor)) .otherwise(0)); If possible, we should avoid a new concept to express something that could be expressed straightforward using an existing concepts. Adding a new concept increases the complexity tremendously, because you have to understand how the new concept works with all possible combinations of existing concepts. What I would suggest instead is to think about additions to the Binding API that make your code easier. Maybe we should add clampTo(min, max) to NumberExpression, so that you could write area.height().multiply(pixelToSecondsFactor).clampTo(0, Integer.MAX) Looking at your other examples for further ideas, maybe we need to add a otherwiseWhen() method to write something like when().then().otherwiseWhen().then().otherwise(). Maybe we need switch-case within bindings. Do you have any examples of constraints that can not be covered by the binding API or some small addition to it? - Michael On 08.10.2012, at 19:08, Tom Eugelink wrote: > Hmmmm, not sure we are on the same line here. The essence of the proposal is that the user of a property can specify a constraint. Let's see how I can make a good argument for this. > > There are two angles. The first being the binding; I recently recoded my Agenda (Google Calendar) control to use binding and really liked that, but I ran into some omissions IMHO. Suppose I bind an appointment height to the duration of the appointment. So, basically you get something like: > > appointment.duration().bind(area.height().multiply(pixelToSecondsFactor)); > > A UI feature is that the user can resize an area by dragging the end time (bottom of the rectangle) with the mouse. Theoretically he can drag the mouse above the start time, resulting in a negative height. The binding will then result in a negative duration, and that is something I do not want. The problem is that I am not the owner of the appointment (it comes from the business model), nor the owner of the area (it's a rectangle; and even if I extend Rectangle, I cannot extend the height property). So I need a way to prevent that situation to occur, because the BM code handling the appointment will never expect a negative duration, or an end time that falls before the start time (the constraints of the BM entity :-). > > Because the binding allows calculation, it almost requires constraints, or a decent hook system. Or I must find a way to get a man-in-the-middle setup (I did that with JGoodies binding), but native constraints are better. > > The second angle is that the properties concept is a powerful one, and I expect them to become popular in none JavaFX contexts as well. Formal properties is something the community have been begging for for a long time. These other context, say a mortgage business model, may be less lenient towards the possible values a property can have and require a strict handling of the values, and maybe (yes) throw exceptions. Further more these constraints may be fairly complex, so a simple "if a then b" might not cut it. So if we're contemplating constraints, then let's look at the bigger picture. > > Now, I'm not knowledgable enough on the implementation that I can discuss the implementation details, but I understand the problem of the lazy binding your describing. Maybe, in light of the bigger picture, eager bindings are important. I only know that being able to hook into binding to make sure a value never goes out of range, both directly on a property (as a permanent constraint) or inside a binding chain (as a local constraint), seems like a very natural thing. > > Tom > > > > On 2012-10-08 16:26, Richard Bair wrote: >> It looks like there are two elements of this proposal. The first is that the author of a bean might want to specify some inherent constraint >> on the property -- such as, it should never be null, or it should never be negative. The second is that a user of the property might want to constrain the property in some way -- such as, in my app the width should never be negative. >> >> I see the value immediately in the first (in fact, this has always been a problem with our properties, going all the way back to JavaFX Script), but I struggle to see much value in the second. Not because you might not want to do this sort of thing, but because the first (inherent constraints) is not presently possible at all, while the second (app constraints) you can already do in your application code, one way or another. I am inclined not to add API for cases that are already solvable, unless it turns out to be so compelling and widely used. >> >> From a semantic point of view, binding was a "mathematical" relationship between two properties in JavaFX Script, such that when you read code like: >> >> x: bind 10 * someProperty >> >> you new that "x" was going to be 10 * someProperty, and not anything else. Of course as an API designer I have never liked that because I have to handle exceptional conditions in my code rather than being able to verify that a property can never go outside its valid range of values. >> >> I am pleased to see your proposal doesn't include throwing exceptions -- I think throwing an exception from a property on invalid input is a very bad idea. The problem is in lazy evaluation of properties. Suppose: >> >> widthProperty().bind(someProperty) >> >> Further suppose width is constrained to never be < 0, and somebody were to try to set it to be < 0 it would throw an exception. In this case, someProperty might be set to -10 at some time, and the width property is invalidated. But until somebody tries to read width, it won't throw the exception. So the problem with bound properties & exceptions is that the exception is not thrown at the time the error is introduced, but rather at the time the error is discovered, which turns out to be an awful behavior. >> >> However your proposal instead says "if it is outside the allowable range, I will just adjust the value to keep it within the allowable range". I think this is a really good idea. The property implementations would have to be modified such that on read, instead of: >> >> /** >> * {@inheritDoc} >> */ >> @Override >> public boolean get() { >> valid = true; >> return observable == null ? value : observable.get(); >> } >> >> we instead do something like: >> >> /** >> * {@inheritDoc} >> */ >> @Override >> public boolean get() { >> if (!valid && observable != null) { >> value = constrain(observable.get()); >> } >> valid = true; >> return observable == null ? value : observable.get(); >> } >> >> >> And add a protected 'constrain' method. Or perhaps we can just call the "set" method and let the set method deal with constraining. This would require taking some care, however, because it means set methods will now be called even when the property is bound which is different than at present, and calling super.set() would throw an exception in the case that it is bound. But still, as a Java developer I'm used to doing constraining from within the setter, so doing it inside the set seems the most natural, but this would be an area that needs to be figured out. >> >> Richard >> >> On Oct 7, 2012, at 12:10 AM, Tom Eugelink wrote: >> >>> As far as I understand, the current the approach is that properties should accept any value, and the usage of these properties have to work with that. Personally I'm prefer a different approach, because I feel the responsibility to have sensible values should be constrained to one place. Therefore I often override the set method of my properties to make sure the value is within the range that my remaining code expect it to be; either by throwing an exception or by clamping the value to a range. >>> >>> But this I can only do with my own properties. It would be nice to also do this to existing properties and therefor I would like to suggest to extend the property concept with constraints or conditions. The important point being that these constraints are applied before the value is set, and not (like a change listener approach) afterwards and then correct value; a value should never be outside it allowed range. >>> >>> The constraints or conditions could have an if-then structure: if value < 0 then 0. An example in Java 8 lambda notation: >>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>> >>> This would also be something relevant to binding, especially when doing calculations: >>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); >>> >>> There is a difference between a permanent constraint on the property and a constraint only applicable to a binding. The notation above is is too similar to my taste and too easily a binding constraint can become a property constaint. To make this difference more explicit, the word "if" could be better on binding: >>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); >>> >>> Something to think about is how far these constraints should be taken. These are simple if-then constraints. But what if "else", "elsif" constructions or "case" statements are needed to express the range? In order to keep all options open, maybe the best approach would be to provide constraining listeners. A constraining listener would get the to-be-set value as a parameter and return the new value. For example: >>> >>> widthProperty.addConstrainingListener( v -> { if (v < 0.0) return 0.0; return v; } ); >>> >>> or in normal notation: >>> >>> widthProperty.addConstrainingListener( new ConstaintListener() { >>> public Double constaint(Double value) { >>> if (value < 0.0) return 0.0; >>> return value; >>> } >>> }); >>> >>> (NB: I'm not sure how to use Java 8 lambda with the addListener method, differentiating between a change, invalidation and constraint listener.) >>> >>> This constraining listener approach would allow for all scenario's to be handled. So that is the final improvement I would like to suggest: constrainting listeners. >>> someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return 0.0; return v; } ); >>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) return 0.0; return v; } ) ); >>> >>> And if possible normal constraints, because that is a easier notation. >>> >>> I'd like to hear if I'm making sense or am missing the ball completely. >>> >>> Tom > From tbee at tbee.org Tue Oct 9 05:58:07 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 09 Oct 2012 14:58:07 +0200 Subject: property improvement suggestion In-Reply-To: <28B1593F-CE88-4387-9193-C34502E29FDE@oracle.com> References: <50712B02.8040306@tbee.org> <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> <50730880.6080307@tbee.org> <28B1593F-CE88-4387-9193-C34502E29FDE@oracle.com> Message-ID: <50741F5F.3050006@tbee.org> Aha. I did not know that "when" existed. I'm sorry, an oversight. That indeed covers the whole constraint part of binding, a clamp and otherwiseWhen would indeed be nice additions. Leaves the situation where it is preferable to set constraints on the property instead of having to repeat it in every binding. I'll see if I run into any other situations. Tom On 2012-10-09 14:19, Michael Heinrichs wrote: > Hi Tom, > > in my opinion your first case is already covered by the Binding API itself. The Binding API allows you to define all kind of expressions. For the most common ones there are methods in the JavaFX library and you can always add your own implementation. E.g. you could rewrite your example like this: > > appointment.duration().bind( > when(area.height().greaterThan(0)) > .then(area.height().multiply(pixelToSecondsFactor)) > .otherwise(0)); > > If possible, we should avoid a new concept to express something that could be expressed straightforward using an existing concepts. Adding a new concept increases the complexity tremendously, because you have to understand how the new concept works with all possible combinations of existing concepts. > > What I would suggest instead is to think about additions to the Binding API that make your code easier. Maybe we should add clampTo(min, max) to NumberExpression, so that you could write > > area.height().multiply(pixelToSecondsFactor).clampTo(0, Integer.MAX) > > Looking at your other examples for further ideas, maybe we need to add a otherwiseWhen() method to write something like when().then().otherwiseWhen().then().otherwise(). Maybe we need switch-case within bindings. > > Do you have any examples of constraints that can not be covered by the binding API or some small addition to it? > > - Michael > > > > > On 08.10.2012, at 19:08, Tom Eugelink wrote: > >> Hmmmm, not sure we are on the same line here. The essence of the proposal is that the user of a property can specify a constraint. Let's see how I can make a good argument for this. >> >> There are two angles. The first being the binding; I recently recoded my Agenda (Google Calendar) control to use binding and really liked that, but I ran into some omissions IMHO. Suppose I bind an appointment height to the duration of the appointment. So, basically you get something like: >> >> appointment.duration().bind(area.height().multiply(pixelToSecondsFactor)); >> >> A UI feature is that the user can resize an area by dragging the end time (bottom of the rectangle) with the mouse. Theoretically he can drag the mouse above the start time, resulting in a negative height. The binding will then result in a negative duration, and that is something I do not want. The problem is that I am not the owner of the appointment (it comes from the business model), nor the owner of the area (it's a rectangle; and even if I extend Rectangle, I cannot extend the height property). So I need a way to prevent that situation to occur, because the BM code handling the appointment will never expect a negative duration, or an end time that falls before the start time (the constraints of the BM entity :-). >> >> Because the binding allows calculation, it almost requires constraints, or a decent hook system. Or I must find a way to get a man-in-the-middle setup (I did that with JGoodies binding), but native constraints are better. >> >> The second angle is that the properties concept is a powerful one, and I expect them to become popular in none JavaFX contexts as well. Formal properties is something the community have been begging for for a long time. These other context, say a mortgage business model, may be less lenient towards the possible values a property can have and require a strict handling of the values, and maybe (yes) throw exceptions. Further more these constraints may be fairly complex, so a simple "if a then b" might not cut it. So if we're contemplating constraints, then let's look at the bigger picture. >> >> Now, I'm not knowledgable enough on the implementation that I can discuss the implementation details, but I understand the problem of the lazy binding your describing. Maybe, in light of the bigger picture, eager bindings are important. I only know that being able to hook into binding to make sure a value never goes out of range, both directly on a property (as a permanent constraint) or inside a binding chain (as a local constraint), seems like a very natural thing. >> >> Tom >> >> >> >> On 2012-10-08 16:26, Richard Bair wrote: >>> It looks like there are two elements of this proposal. The first is that the author of a bean might want to specify some inherent constraint >>> on the property -- such as, it should never be null, or it should never be negative. The second is that a user of the property might want to constrain the property in some way -- such as, in my app the width should never be negative. >>> >>> I see the value immediately in the first (in fact, this has always been a problem with our properties, going all the way back to JavaFX Script), but I struggle to see much value in the second. Not because you might not want to do this sort of thing, but because the first (inherent constraints) is not presently possible at all, while the second (app constraints) you can already do in your application code, one way or another. I am inclined not to add API for cases that are already solvable, unless it turns out to be so compelling and widely used. >>> >>> From a semantic point of view, binding was a "mathematical" relationship between two properties in JavaFX Script, such that when you read code like: >>> >>> x: bind 10 * someProperty >>> >>> you new that "x" was going to be 10 * someProperty, and not anything else. Of course as an API designer I have never liked that because I have to handle exceptional conditions in my code rather than being able to verify that a property can never go outside its valid range of values. >>> >>> I am pleased to see your proposal doesn't include throwing exceptions -- I think throwing an exception from a property on invalid input is a very bad idea. The problem is in lazy evaluation of properties. Suppose: >>> >>> widthProperty().bind(someProperty) >>> >>> Further suppose width is constrained to never be < 0, and somebody were to try to set it to be < 0 it would throw an exception. In this case, someProperty might be set to -10 at some time, and the width property is invalidated. But until somebody tries to read width, it won't throw the exception. So the problem with bound properties & exceptions is that the exception is not thrown at the time the error is introduced, but rather at the time the error is discovered, which turns out to be an awful behavior. >>> >>> However your proposal instead says "if it is outside the allowable range, I will just adjust the value to keep it within the allowable range". I think this is a really good idea. The property implementations would have to be modified such that on read, instead of: >>> >>> /** >>> * {@inheritDoc} >>> */ >>> @Override >>> public boolean get() { >>> valid = true; >>> return observable == null ? value : observable.get(); >>> } >>> >>> we instead do something like: >>> >>> /** >>> * {@inheritDoc} >>> */ >>> @Override >>> public boolean get() { >>> if (!valid && observable != null) { >>> value = constrain(observable.get()); >>> } >>> valid = true; >>> return observable == null ? value : observable.get(); >>> } >>> >>> >>> And add a protected 'constrain' method. Or perhaps we can just call the "set" method and let the set method deal with constraining. This would require taking some care, however, because it means set methods will now be called even when the property is bound which is different than at present, and calling super.set() would throw an exception in the case that it is bound. But still, as a Java developer I'm used to doing constraining from within the setter, so doing it inside the set seems the most natural, but this would be an area that needs to be figured out. >>> >>> Richard >>> >>> On Oct 7, 2012, at 12:10 AM, Tom Eugelink wrote: >>> >>>> As far as I understand, the current the approach is that properties should accept any value, and the usage of these properties have to work with that. Personally I'm prefer a different approach, because I feel the responsibility to have sensible values should be constrained to one place. Therefore I often override the set method of my properties to make sure the value is within the range that my remaining code expect it to be; either by throwing an exception or by clamping the value to a range. >>>> >>>> But this I can only do with my own properties. It would be nice to also do this to existing properties and therefor I would like to suggest to extend the property concept with constraints or conditions. The important point being that these constraints are applied before the value is set, and not (like a change listener approach) afterwards and then correct value; a value should never be outside it allowed range. >>>> >>>> The constraints or conditions could have an if-then structure: if value < 0 then 0. An example in Java 8 lambda notation: >>>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>>> >>>> This would also be something relevant to binding, especially when doing calculations: >>>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); >>>> >>>> There is a difference between a permanent constraint on the property and a constraint only applicable to a binding. The notation above is is too similar to my taste and too easily a binding constraint can become a property constaint. To make this difference more explicit, the word "if" could be better on binding: >>>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); >>>> >>>> Something to think about is how far these constraints should be taken. These are simple if-then constraints. But what if "else", "elsif" constructions or "case" statements are needed to express the range? In order to keep all options open, maybe the best approach would be to provide constraining listeners. A constraining listener would get the to-be-set value as a parameter and return the new value. For example: >>>> >>>> widthProperty.addConstrainingListener( v -> { if (v < 0.0) return 0.0; return v; } ); >>>> >>>> or in normal notation: >>>> >>>> widthProperty.addConstrainingListener( new ConstaintListener() { >>>> public Double constaint(Double value) { >>>> if (value < 0.0) return 0.0; >>>> return value; >>>> } >>>> }); >>>> >>>> (NB: I'm not sure how to use Java 8 lambda with the addListener method, differentiating between a change, invalidation and constraint listener.) >>>> >>>> This constraining listener approach would allow for all scenario's to be handled. So that is the final improvement I would like to suggest: constrainting listeners. >>>> someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return 0.0; return v; } ); >>>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) return 0.0; return v; } ) ); >>>> >>>> And if possible normal constraints, because that is a easier notation. >>>> >>>> I'd like to hear if I'm making sense or am missing the ball completely. >>>> >>>> Tom From kirill.prazdnikov at oracle.com Tue Oct 9 06:42:35 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Tue, 09 Oct 2012 17:42:35 +0400 Subject: 3D Features Planned for Version 8 In-Reply-To: <5073D7BC.9030802@oracle.com> References: <506F0DDD.9060708@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601A2294A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5073D7BC.9030802@oracle.com> Message-ID: <507429CB.3090105@oracle.com> Hi John, all, This questions are very interesting. FX8 will be very soon. Due to very limited time-frame, only fixed material will be implemented in FX8. Custom material is a nice subject to discussion. Which graphics shader language you think would be best ? -Kirill On 09.10.2012 11:52, Chien Yang wrote: > Hi John, > > Good questions. We have evaluated both user subclassing of Material > and custom shader during our 3D features meeting. They do not belong > to the "must have" list in our use case study, and they require > certain design tradeoff and investment work that we aren't ready to > commit for JavaFX 8. > > - Chien > > On 10/8/2012 3:30 PM, John Smith wrote: >> Thanks for making the info public Chien. >> >> 1. Will I be able to subclass Material to create my own material >> types? >> 2. If so, what could I reasonably expect these custom Materials to >> be capable of? >> 3. Will I be able to create custom shaders which make use of the >> shading hardware on the GPU? And if so, how would this be done? >> >> I think you would be able to implement a wide variety of 3D related >> use cases in JavaFX 3D if it provided a clean API with a similar >> feature set (and ease of use) to the three.js library: >> http://en.wikipedia.org/wiki/Three.js#Features >> http://aerotwist.com/tutorials/ >> In providing such a feature set, a JavaFX 3D API would at appear to >> be feature comparable to WebGL, which I think is one of the >> comparison points that somebody evaluating the API would have. The >> planned features on the wiki go a fair way towards implementing a lot >> of the base functionality required to make this happen. Obviously, a >> complete implementation of such a feature set is not in scope for >> JDK8, but it would be interesting to know what is planned for the >> future with regards to JavaFX and 3D. >> >> Regards, >> John >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang >> Sent: Friday, October 05, 2012 9:42 AM >> To: OpenJFX >> Subject: 3D Features Planned for Version 8 >> >> Hi all, >> >> We have been thinking about the possible 3D features for JavaFX 8 for >> a while. We are now ready to present the plan to the community for >> review. >> This information has also been presented at this year's JavaOne "3D >> Made Easy with JavaFX" technical session. >> >> https://wikis.oracle.com/display/OpenJDK/3D+Features >> >> Please let us know if you have any suggestions or concerns. >> >> Regards, >> >> - Chien Yang >> JavaFX Graphics Team > From goddard at seznam.cz Tue Oct 9 06:46:25 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Tue, 09 Oct 2012 15:46:25 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=203D=20Features=20Planned=20for=20Version=208?= In-Reply-To: <507429CB.3090105@oracle.com> Message-ID: <135920.15640.48859-4620-2090426637-1349790385@seznam.cz> JSL, if it's still in place, usable and documented. If not, it's GLSL then. Jiri ------------ P?vodn? zpr?va ------------ Od: Kirill.Prazdnikov P?edm?t: Re: 3D Features Planned for Version 8 Datum: 09.10.2012 15:44:52 ---------------------------------------- Hi John, all, This questions are very interesting. FX8 will be very soon. Due to very limited time-frame, only fixed material will be implemented in FX8. Custom material is a nice subject to discussion. Which graphics shader language you think would be best ? -Kirill On 09.10.2012 11:52, Chien Yang wrote: > Hi John, > > Good questions. We have evaluated both user subclassing of Material > and custom shader during our 3D features meeting. They do not belong > to the "must have" list in our use case study, and they require > certain design tradeoff and investment work that we aren't ready to > commit for JavaFX 8. > > - Chien > > On 10/8/2012 3:30 PM, John Smith wrote: >> Thanks for making the info public Chien. >> >> 1. Will I be able to subclass Material to create my own material >> types? >> 2. If so, what could I reasonably expect these custom Materials to >> be capable of? >> 3. Will I be able to create custom shaders which make use of the >> shading hardware on the GPU? And if so, how would this be done? >> >> I think you would be able to implement a wide variety of 3D related >> use cases in JavaFX 3D if it provided a clean API with a similar >> feature set (and ease of use) to the three.js library: >> http://en.wikipedia.org/wiki/Three.js#Features >> http://aerotwist.com/tutorials/ >> In providing such a feature set, a JavaFX 3D API would at appear to >> be feature comparable to WebGL, which I think is one of the >> comparison points that somebody evaluating the API would have. The >> planned features on the wiki go a fair way towards implementing a lot >> of the base functionality required to make this happen. Obviously, a >> complete implementation of such a feature set is not in scope for >> JDK8, but it would be interesting to know what is planned for the >> future with regards to JavaFX and 3D. >> >> Regards, >> John >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang >> Sent: Friday, October 05, 2012 9:42 AM >> To: OpenJFX >> Subject: 3D Features Planned for Version 8 >> >> Hi all, >> >> We have been thinking about the possible 3D features for JavaFX 8 for >> a while. We are now ready to present the plan to the community for >> review. >> This information has also been presented at this year's JavaOne "3D >> Made Easy with JavaFX" technical session. >> >> https://wikis.oracle.com/display/OpenJDK/3D+Features >> >> Please let us know if you have any suggestions or concerns. >> >> Regards, >> >> - Chien Yang >> JavaFX Graphics Team > From zonski at gmail.com Tue Oct 9 07:01:35 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 10 Oct 2012 01:01:35 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> https://forums.oracle.com/forums/message.jspa?messageID=10623319#10623319 Community minus 1 from me if this issue goes the way it's going. The make or break issue has always been and will always be deployment and that includes desktop and mobile. After a year or two making noise about this we're going backwards. Anyone remember why Java became so popular? Remember write-once-run-anywhere? Now it's write once, go through as much build hassles as an old fashioned c++ app for each platform (and variant) and run on even less platforms than c++ will work on. Can't decide if I'm more frustrated, angry or sad. On 09/10/2012, at 10:25 PM, Tobias Bley wrote: > There are two steps to go: > > 1. Porting Prism/glass to iOS > 2. use AOT compiler > > Both steps were finished in 2011 yet (http://java.dzone.com/articles/javaone-2011-javafx-20) > > > > > > > Am 09.10.2012 um 13:11 schrieb Peter Pilgrim : > >> Hi >> >> On the other hand, the whole of JavaFX is going to be open sourced by 2013. >> So what it stopping someone porting the lower architecture to iOS? >> Therefore one strategy is to wait until the open source is there and >> then port it and write the bridging layer between Java and native >> Apple libraries, which I guess would be Objective C. I don't know >> really. Of course, that would require expertise in Apple native >> libraries. Nevertheless it can be done by somebody. The hard part is >> bundling a JRE into a form that can run in iOS app store, and also the >> pass by the gatekeeper. >> >> On 9 October 2012 01:23, Tobias Bley wrote: >>> John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! >>> >>> John, please write to Richard Bair, he wants to know our opinion about this topic! >>> >>> Best, >>> Tobi >>> >>> >>> -- >>> Tobias Bley >>> Chief Executive Officer >>> >>> -------------------------------------------------------- >>> >>> UltraMixer Digital Audio Solutions >>> Schillerstra?e 29 >>> D-01326 Dresden >>> Germany >>> >>> -------------------------------------------------------- >>> bley at ultramixer.com http://www.ultramixer.com >>> >>> >>> >>> Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : >>> >>>> Hi Tobi, >>>> >>>> I realise it's not an official Oracle statement but that's part of the >>>> problem; Oracle didn't make an official statement on this at JavaOne when I >>>> suspect many people were hoping for one. In fact, I seem to remember a >>>> session titled something like "JavaFX on iOS" was being tossed around for >>>> possible inclusion in this year's JavaOne some time ago. >>>> >>>> It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet >>>> Oracle are waiting for clear commercial interest to justify such support? >>>> As has been pointed out several times, JavaFX cannot be considered a success >>>> if it is limited to the scope of the desktop and perhaps some embedded >>>> devices. Many predict that the PC in its current form will largely >>>> disappear in the next 5 years so where would that leave JavaFX? >>>> >>>> Java developers are largely passionate about their language and do not want >>>> to learn Objective C or C# or whatever language is required on each device. >>>> >>>> In my opinion, being able to code in Java and deploy to Windows, Linux, >>>> MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as >>>> the best platform for client side software development on the planet. >>>> Please Oracle, don't miss this enormous opportunity! What do we have to do >>>> to convince you that this REALLY IS A GOOD IDEA? >>>> >>>> -jct >>>> >>>> -----Original Message----- >>>> From: Tobias Bley [mailto:tobi at ultramixer.com] >>>> Sent: Tuesday, 9 October 2012 18:10 >>>> To: John C. Turnbull >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>>> >>>> Hi guys, >>>> >>>> first of all: that's not an official press release of Oracle... >>>> >>>> second: please take part of the current discussion on JavaFX forum about >>>> "JavaFX on iOS, Android and Windows 8": >>>> https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 >>>> >>>> Richard Bair there asked for developers and companies who have a real >>>> (commercial) interested in using JavaFX on iOS.... So please please write >>>> Richard an email to show him your real interested. >>>> >>>> Best regards, >>>> Tobi >>>> >>>> blog.software4java.com >>>> >>>> >>>> >>>> Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : >>>> >>>>> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >>>>> Jellema (and retweeted by Nicolas Lorain) the following is stated: >>>>> >>>>> >>>>> >>>>> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >>>>> Android and Windows Mobile phones are provided by the respective >>>>> platforms, there is no room there for JavaFX. JavaFX is targeted at >>>>> the desktop to replace Swing and at smaller devices that run embedded >>>> Java." >>>>> >>>>> >>>>> >>>>> This is extremely disappointing especially after having seen demos of >>>>> JavaFX running on iOS and Android devices. >>>>> >>>>> >>>>> >>>>> Can someone explain why this decision has been made? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> -jct >>>>> >>>> >>> >> >> >> >> -- >> Peter Pilgrim, >> **Java Champion**, >> Java EE Software Development / Design / Architect for financial >> services, London, UK >> >> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >> >> :: http://www.xenonique.co.uk/blog/ :: >> :: http://twitter.com/peter_pilgrim :: >> :: http://audio.fm/profile/peter_pilgrim :: >> :: Skype Call peter_pilgrim :: >> :: http://java-champions.java.net/ :: > From tobi at ultramixer.com Tue Oct 9 07:06:14 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 9 Oct 2012 16:06:14 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> Message-ID: We all don't know the official Oracle plan! But IMO the kind of communication of Oracle (we say nothing) is the real pain...sorry. Am 09.10.2012 um 16:01 schrieb Daniel Zwolenski : > https://forums.oracle.com/forums/message.jspa?messageID=10623319#10623319 > > Community minus 1 from me if this issue goes the way it's going. The make or break issue has always been and will always be deployment and that includes desktop and mobile. After a year or two making noise about this we're going backwards. > > Anyone remember why Java became so popular? Remember write-once-run-anywhere? Now it's write once, go through as much build hassles as an old fashioned c++ app for each platform (and variant) and run on even less platforms than c++ will work on. > > Can't decide if I'm more frustrated, angry or sad. > > > > On 09/10/2012, at 10:25 PM, Tobias Bley wrote: > >> There are two steps to go: >> >> 1. Porting Prism/glass to iOS >> 2. use AOT compiler >> >> Both steps were finished in 2011 yet (http://java.dzone.com/articles/javaone-2011-javafx-20) >> >> >> >> >> >> >> Am 09.10.2012 um 13:11 schrieb Peter Pilgrim : >> >>> Hi >>> >>> On the other hand, the whole of JavaFX is going to be open sourced by 2013. >>> So what it stopping someone porting the lower architecture to iOS? >>> Therefore one strategy is to wait until the open source is there and >>> then port it and write the bridging layer between Java and native >>> Apple libraries, which I guess would be Objective C. I don't know >>> really. Of course, that would require expertise in Apple native >>> libraries. Nevertheless it can be done by somebody. The hard part is >>> bundling a JRE into a form that can run in iOS app store, and also the >>> pass by the gatekeeper. >>> >>> On 9 October 2012 01:23, Tobias Bley wrote: >>>> John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! >>>> >>>> John, please write to Richard Bair, he wants to know our opinion about this topic! >>>> >>>> Best, >>>> Tobi >>>> >>>> >>>> -- >>>> Tobias Bley >>>> Chief Executive Officer >>>> >>>> -------------------------------------------------------- >>>> >>>> UltraMixer Digital Audio Solutions >>>> Schillerstra?e 29 >>>> D-01326 Dresden >>>> Germany >>>> >>>> -------------------------------------------------------- >>>> bley at ultramixer.com http://www.ultramixer.com >>>> >>>> >>>> >>>> Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : >>>> >>>>> Hi Tobi, >>>>> >>>>> I realise it's not an official Oracle statement but that's part of the >>>>> problem; Oracle didn't make an official statement on this at JavaOne when I >>>>> suspect many people were hoping for one. In fact, I seem to remember a >>>>> session titled something like "JavaFX on iOS" was being tossed around for >>>>> possible inclusion in this year's JavaOne some time ago. >>>>> >>>>> It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet >>>>> Oracle are waiting for clear commercial interest to justify such support? >>>>> As has been pointed out several times, JavaFX cannot be considered a success >>>>> if it is limited to the scope of the desktop and perhaps some embedded >>>>> devices. Many predict that the PC in its current form will largely >>>>> disappear in the next 5 years so where would that leave JavaFX? >>>>> >>>>> Java developers are largely passionate about their language and do not want >>>>> to learn Objective C or C# or whatever language is required on each device. >>>>> >>>>> In my opinion, being able to code in Java and deploy to Windows, Linux, >>>>> MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as >>>>> the best platform for client side software development on the planet. >>>>> Please Oracle, don't miss this enormous opportunity! What do we have to do >>>>> to convince you that this REALLY IS A GOOD IDEA? >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From: Tobias Bley [mailto:tobi at ultramixer.com] >>>>> Sent: Tuesday, 9 October 2012 18:10 >>>>> To: John C. Turnbull >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>>>> >>>>> Hi guys, >>>>> >>>>> first of all: that's not an official press release of Oracle... >>>>> >>>>> second: please take part of the current discussion on JavaFX forum about >>>>> "JavaFX on iOS, Android and Windows 8": >>>>> https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 >>>>> >>>>> Richard Bair there asked for developers and companies who have a real >>>>> (commercial) interested in using JavaFX on iOS.... So please please write >>>>> Richard an email to show him your real interested. >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> blog.software4java.com >>>>> >>>>> >>>>> >>>>> Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : >>>>> >>>>>> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >>>>>> Jellema (and retweeted by Nicolas Lorain) the following is stated: >>>>>> >>>>>> >>>>>> >>>>>> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >>>>>> Android and Windows Mobile phones are provided by the respective >>>>>> platforms, there is no room there for JavaFX. JavaFX is targeted at >>>>>> the desktop to replace Swing and at smaller devices that run embedded >>>>> Java." >>>>>> >>>>>> >>>>>> >>>>>> This is extremely disappointing especially after having seen demos of >>>>>> JavaFX running on iOS and Android devices. >>>>>> >>>>>> >>>>>> >>>>>> Can someone explain why this decision has been made? >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> -jct >>>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Peter Pilgrim, >>> **Java Champion**, >>> Java EE Software Development / Design / Architect for financial >>> services, London, UK >>> >>> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >>> >>> :: http://www.xenonique.co.uk/blog/ :: >>> :: http://twitter.com/peter_pilgrim :: >>> :: http://audio.fm/profile/peter_pilgrim :: >>> :: Skype Call peter_pilgrim :: >>> :: http://java-champions.java.net/ :: >> From kevin.rushforth at oracle.com Tue Oct 9 07:10:25 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Oct 2012 07:10:25 -0700 Subject: 3D Features Planned for Version 8 In-Reply-To: <135920.15640.48859-4620-2090426637-1349790385@seznam.cz> References: <135920.15640.48859-4620-2090426637-1349790385@seznam.cz> Message-ID: <50743051.1040407@oracle.com> GLSL is not an option unless we provide a translator to HLSL. Additionally, there are some challenges in providing full access to shaders given that Prism internally uses shaders during the rendering. One possibility is to allow users to provide a portion of the shader with well-defined inputs and outputs which can be linked in with our shaders, but this is definitely out of scope for FX 8. As interesting as the topic is, it will be more productive to discuss it when we are ready to start thinking about the next release beyond FX 8. -- Kevin goddard at seznam.cz wrote: > JSL, if it's still in place, usable and documented. If not, it's GLSL > then. > > Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Kirill.Prazdnikov > P?edm?t: Re: 3D Features Planned for Version 8 > Datum: 09.10.2012 15:44:52 > ---------------------------------------- > Hi John, all, > > This questions are very interesting. FX8 will be very soon. > Due to very limited time-frame, only fixed material will be > implemented in FX8. > Custom material is a nice subject to discussion. > Which graphics shader language you think would be best ? > > -Kirill > > On 09.10.2012 11:52, Chien Yang wrote: >> Hi John, >> >> Good questions. We have evaluated both user subclassing of >> Material and custom shader during our 3D features meeting. They do >> not belong to the "must have" list in our use case study, and they >> require certain design tradeoff and investment work that we aren't >> ready to commit for JavaFX 8. >> >> - Chien >> >> On 10/8/2012 3:30 PM, John Smith wrote: >>> Thanks for making the info public Chien. >>> >>> 1. Will I be able to subclass Material to create my own material >>> types? >>> 2. If so, what could I reasonably expect these custom Materials >>> to be capable of? >>> 3. Will I be able to create custom shaders which make use of the >>> shading hardware on the GPU? And if so, how would this be done? >>> >>> I think you would be able to implement a wide variety of 3D related >>> use cases in JavaFX 3D if it provided a clean API with a similar >>> feature set (and ease of use) to the three.js library: >>> http://en.wikipedia.org/wiki/Three.js#Features >>> http://aerotwist.com/tutorials/ >>> In providing such a feature set, a JavaFX 3D API would at appear to >>> be feature comparable to WebGL, which I think is one of the >>> comparison points that somebody evaluating the API would have. The >>> planned features on the wiki go a fair way towards implementing a >>> lot of the base functionality required to make this happen. >>> Obviously, a complete implementation of such a feature set is not in >>> scope for JDK8, but it would be interesting to know what is planned >>> for the future with regards to JavaFX and 3D. >>> >>> Regards, >>> John >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chien Yang >>> Sent: Friday, October 05, 2012 9:42 AM >>> To: OpenJFX >>> Subject: 3D Features Planned for Version 8 >>> >>> Hi all, >>> >>> We have been thinking about the possible 3D features for JavaFX 8 >>> for a while. We are now ready to present the plan to the community >>> for review. >>> This information has also been presented at this year's JavaOne "3D >>> Made Easy with JavaFX" technical session. >>> >>> https://wikis.oracle.com/display/OpenJDK/3D+Features >>> >>> Please let us know if you have any suggestions or concerns. >>> >>> Regards, >>> >>> - Chien Yang >>> JavaFX Graphics Team >> > > > From daniel.fuchs at oracle.com Tue Oct 9 07:23:40 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 09 Oct 2012 16:23:40 +0200 Subject: Is there any source code for the JavaFX SceneBuilder In-Reply-To: References: Message-ID: <5074336C.8010006@oracle.com> Hi, SceneBuilder uses processing instructions in the FXML file to store/read the classpath and location of the resource properties. You can set those from within SceneBuilder itself: [MenuBar] > Preview > Internationalization > Set Resource... lets you choose a properties file from which to resolve i18n keys [MenuBar] > Preview > Resolve Unknown Types... lets you specify a class path against which to resolve unknown types. Note that for working with custom types I'd recommend using the Java FX SceneBuilder 1.1 developer preview - rather than the 1.0 GA - as many fixes have been made regarding custom types in 1.1 (in particular the bug that prevented the classpath popup to show up when you started SB by double clicking on an FXML file). The processing instructions that Scene Builder uses should be considered proprietary API for now - they might change or be replaced by something else in the future. If you look at the HelloI18N sample - you will see that it the FXML contains a PI: this tells SceneBuilder to use a file named Bundle.properties located in the same directory than the FXML file in order to resolve i18n keys. if your layout had been: src/My Resources/Bundle.properties src/fxml/MyFxml.fxml you would have seen: For the classpath it's basically the same: there is one PI line per entry in the classpath, and the locations must be relative to the FXML file - e.g - for a layout such as: dist/myfirst.jar dist/lib/mysecond.jar src/fxml/MyFxml.fxml and a classpath=dist/myfirst.jar:dist/lib/mysecond.jar you will find: If your FXML file contains custom type, scene builder will prompt you to enter a classpath - which will be pre-populated with the list of classpath element found in the FXML file. Check the 'Set up classpath' checkbox and click on "Apply" to apply the classpath. Hope this helps, -- daniel > Message: 3 > Date: Tue, 09 Oct 2012 12:23:16 +0200 > From: Tom Schindl > Subject: Re: Is there any source code for the JavaFX SceneBuilder? > To: openjfx-dev at openjdk.java.net > Message-ID: <5073FB14.5060005 at bestsolution.at> > Content-Type: text/plain; charset=ISO-8859-1 > > Am 09.10.12 12:14, schrieb Werner Lehmann: >> This is also simple to do in Eclipse. The main problem I am having is, >> how to pass the location of the resource bundle and especially the >> classpath of my custom controls to SceneBuilder. Without this I am >> seeing only black boxes (not necessarily black) instead of my custom >> controls, and resource bundle keys like "%task-dialog-title" instead of >> "Edit employee task". >> >> In my case this classpath would be assembled from the output directories >> of several dependent projects plus libraries. >> >> Tom, is this something you managed to do in e(fx)clipse? >> > > No. My e(fx)clipse internal preview naturally has all those informations > because it knows the classpath of the project. > > We'd need from the SceneBuilder people an API (once we directly embed > the editor) and/or an interchange format to tell them where to search > for classes. > > So if we (Eclipse,Netbeans,SceneBuilder) could work on an interchange > format like > > scenebuilder.classpath > ---------------------- > > > > > > > this could help you. > > It is very easy for IDEs to provide something like this. > > Tom From debasish.raychawdhuri at gmail.com Tue Oct 9 07:43:42 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Tue, 9 Oct 2012 20:13:42 +0530 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> Message-ID: Everyone knows from the begining Oracle does not give a shit about the community. They have already shown that attitude in multiple occasions. Actually the fact that java has a community based development model (which they are legally obliged to follow, otherwise they would lose patent rights owned by multiple corporates and individuals) is something they consider a pain point. However they do not hesitate to try to unofficially sabotage the community process of java. In modern times, anything that is not community driven is doomed to die off slowly, same seems to be the fate of java eventually. On Tue, Oct 9, 2012 at 7:36 PM, Tobias Bley wrote: > We all don't know the official Oracle plan! But IMO the kind of communication of Oracle (we say nothing) is the real pain...sorry. > > > > Am 09.10.2012 um 16:01 schrieb Daniel Zwolenski : > >> https://forums.oracle.com/forums/message.jspa?messageID=10623319#10623319 >> >> Community minus 1 from me if this issue goes the way it's going. The make or break issue has always been and will always be deployment and that includes desktop and mobile. After a year or two making noise about this we're going backwards. >> >> Anyone remember why Java became so popular? Remember write-once-run-anywhere? Now it's write once, go through as much build hassles as an old fashioned c++ app for each platform (and variant) and run on even less platforms than c++ will work on. >> >> Can't decide if I'm more frustrated, angry or sad. >> >> >> >> On 09/10/2012, at 10:25 PM, Tobias Bley wrote: >> >>> There are two steps to go: >>> >>> 1. Porting Prism/glass to iOS >>> 2. use AOT compiler >>> >>> Both steps were finished in 2011 yet (http://java.dzone.com/articles/javaone-2011-javafx-20) >>> >>> >>> >>> >>> >>> >>> Am 09.10.2012 um 13:11 schrieb Peter Pilgrim : >>> >>>> Hi >>>> >>>> On the other hand, the whole of JavaFX is going to be open sourced by 2013. >>>> So what it stopping someone porting the lower architecture to iOS? >>>> Therefore one strategy is to wait until the open source is there and >>>> then port it and write the bridging layer between Java and native >>>> Apple libraries, which I guess would be Objective C. I don't know >>>> really. Of course, that would require expertise in Apple native >>>> libraries. Nevertheless it can be done by somebody. The hard part is >>>> bundling a JRE into a form that can run in iOS app store, and also the >>>> pass by the gatekeeper. >>>> >>>> On 9 October 2012 01:23, Tobias Bley wrote: >>>>> John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! >>>>> >>>>> John, please write to Richard Bair, he wants to know our opinion about this topic! >>>>> >>>>> Best, >>>>> Tobi >>>>> >>>>> >>>>> -- >>>>> Tobias Bley >>>>> Chief Executive Officer >>>>> >>>>> -------------------------------------------------------- >>>>> >>>>> UltraMixer Digital Audio Solutions >>>>> Schillerstra?e 29 >>>>> D-01326 Dresden >>>>> Germany >>>>> >>>>> -------------------------------------------------------- >>>>> bley at ultramixer.com http://www.ultramixer.com >>>>> >>>>> >>>>> >>>>> Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : >>>>> >>>>>> Hi Tobi, >>>>>> >>>>>> I realise it's not an official Oracle statement but that's part of the >>>>>> problem; Oracle didn't make an official statement on this at JavaOne when I >>>>>> suspect many people were hoping for one. In fact, I seem to remember a >>>>>> session titled something like "JavaFX on iOS" was being tossed around for >>>>>> possible inclusion in this year's JavaOne some time ago. >>>>>> >>>>>> It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet >>>>>> Oracle are waiting for clear commercial interest to justify such support? >>>>>> As has been pointed out several times, JavaFX cannot be considered a success >>>>>> if it is limited to the scope of the desktop and perhaps some embedded >>>>>> devices. Many predict that the PC in its current form will largely >>>>>> disappear in the next 5 years so where would that leave JavaFX? >>>>>> >>>>>> Java developers are largely passionate about their language and do not want >>>>>> to learn Objective C or C# or whatever language is required on each device. >>>>>> >>>>>> In my opinion, being able to code in Java and deploy to Windows, Linux, >>>>>> MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as >>>>>> the best platform for client side software development on the planet. >>>>>> Please Oracle, don't miss this enormous opportunity! What do we have to do >>>>>> to convince you that this REALLY IS A GOOD IDEA? >>>>>> >>>>>> -jct >>>>>> >>>>>> -----Original Message----- >>>>>> From: Tobias Bley [mailto:tobi at ultramixer.com] >>>>>> Sent: Tuesday, 9 October 2012 18:10 >>>>>> To: John C. Turnbull >>>>>> Cc: openjfx-dev at openjdk.java.net >>>>>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> first of all: that's not an official press release of Oracle... >>>>>> >>>>>> second: please take part of the current discussion on JavaFX forum about >>>>>> "JavaFX on iOS, Android and Windows 8": >>>>>> https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 >>>>>> >>>>>> Richard Bair there asked for developers and companies who have a real >>>>>> (commercial) interested in using JavaFX on iOS.... So please please write >>>>>> Richard an email to show him your real interested. >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>>> >>>>>> blog.software4java.com >>>>>> >>>>>> >>>>>> >>>>>> Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : >>>>>> >>>>>>> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >>>>>>> Jellema (and retweeted by Nicolas Lorain) the following is stated: >>>>>>> >>>>>>> >>>>>>> >>>>>>> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >>>>>>> Android and Windows Mobile phones are provided by the respective >>>>>>> platforms, there is no room there for JavaFX. JavaFX is targeted at >>>>>>> the desktop to replace Swing and at smaller devices that run embedded >>>>>> Java." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is extremely disappointing especially after having seen demos of >>>>>>> JavaFX running on iOS and Android devices. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can someone explain why this decision has been made? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> -jct >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Peter Pilgrim, >>>> **Java Champion**, >>>> Java EE Software Development / Design / Architect for financial >>>> services, London, UK >>>> >>>> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >>>> >>>> :: http://www.xenonique.co.uk/blog/ :: >>>> :: http://twitter.com/peter_pilgrim :: >>>> :: http://audio.fm/profile/peter_pilgrim :: >>>> :: Skype Call peter_pilgrim :: >>>> :: http://java-champions.java.net/ :: >>> > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From lehmann at media-interactive.de Tue Oct 9 07:46:36 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 9 Oct 2012 16:46:36 +0200 Subject: Is there any source code for the JavaFX SceneBuilder In-Reply-To: <5074336C.8010006@oracle.com> References: <5074336C.8010006@oracle.com> Message-ID: <507438CC.3010607@media-interactive.de> Daniel, thanks for the explanation. I wasn't aware that the classpath could be set with PI's in FXML. In my opinion this could be used as a workaround for now but does not really replace full IDE integration - at least not in a way how I would envision it. The relative paths are a problem when it comes to refactoring, and especially when you want to reuse the same lines in different FXMLs: copy & paste of those PI's requires me to think about how many ../../ I'd need, depending on the package of the FXML at hand. And I don't even want to use the DRY pattern... Usually the IDE manages the classpath for me, it would be redundant to add that to the FXML. I think this is similar to imports in a plain Java file: you say what you want but not where to find it. This information is provided separately. Perhaps via command line "-cp" parameter, etc. Furthermore, I believe it would be more practical to specify the resource bundle relative to the classpath as with any other control import. Maybe this is something intended for FX8? The roadmap mentions "enhanced Java IDE integration" but does not provide many details. This would be a pity for me because I'll be tied to JRE 6/7 for a quite a while longer and could not use this (if necessary we might be able to use JRE8 on development machines only but that would be less desirable). Rgds Werner On 09.10.2012 16:23, Daniel Fuchs wrote: > Hope this helps, From knut.arne.vedaa at broadpark.no Tue Oct 9 08:00:34 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Tue, 09 Oct 2012 17:00:34 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> Message-ID: <50743C12.3050707@broadpark.no> I agree 100% with the general sentiment. Not supporting JavaFX on these devices, if it is technically possible, would be an incredibly stupid decision. But I guess we're preaching to the choir here. Knut Arne Vedaa On 09.10.2012 16:01, Daniel Zwolenski wrote: > https://forums.oracle.com/forums/message.jspa?messageID=10623319#10623319 > > Community minus 1 from me if this issue goes the way it's going. The make or break issue has always been and will always be deployment and that includes desktop and mobile. After a year or two making noise about this we're going backwards. > > Anyone remember why Java became so popular? Remember write-once-run-anywhere? Now it's write once, go through as much build hassles as an old fashioned c++ app for each platform (and variant) and run on even less platforms than c++ will work on. > > Can't decide if I'm more frustrated, angry or sad. > > > > On 09/10/2012, at 10:25 PM, Tobias Bley wrote: > >> There are two steps to go: >> >> 1. Porting Prism/glass to iOS >> 2. use AOT compiler >> >> Both steps were finished in 2011 yet (http://java.dzone.com/articles/javaone-2011-javafx-20) >> >> >> >> >> >> >> Am 09.10.2012 um 13:11 schrieb Peter Pilgrim : >> >>> Hi >>> >>> On the other hand, the whole of JavaFX is going to be open sourced by 2013. >>> So what it stopping someone porting the lower architecture to iOS? >>> Therefore one strategy is to wait until the open source is there and >>> then port it and write the bridging layer between Java and native >>> Apple libraries, which I guess would be Objective C. I don't know >>> really. Of course, that would require expertise in Apple native >>> libraries. Nevertheless it can be done by somebody. The hard part is >>> bundling a JRE into a form that can run in iOS app store, and also the >>> pass by the gatekeeper. >>> >>> On 9 October 2012 01:23, Tobias Bley wrote: >>>> John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! >>>> >>>> John, please write to Richard Bair, he wants to know our opinion about this topic! >>>> >>>> Best, >>>> Tobi >>>> >>>> >>>> -- >>>> Tobias Bley >>>> Chief Executive Officer >>>> >>>> -------------------------------------------------------- >>>> >>>> UltraMixer Digital Audio Solutions >>>> Schillerstra?e 29 >>>> D-01326 Dresden >>>> Germany >>>> >>>> -------------------------------------------------------- >>>> bley at ultramixer.com http://www.ultramixer.com >>>> >>>> >>>> >>>> Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : >>>> >>>>> Hi Tobi, >>>>> >>>>> I realise it's not an official Oracle statement but that's part of the >>>>> problem; Oracle didn't make an official statement on this at JavaOne when I >>>>> suspect many people were hoping for one. In fact, I seem to remember a >>>>> session titled something like "JavaFX on iOS" was being tossed around for >>>>> possible inclusion in this year's JavaOne some time ago. >>>>> >>>>> It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet >>>>> Oracle are waiting for clear commercial interest to justify such support? >>>>> As has been pointed out several times, JavaFX cannot be considered a success >>>>> if it is limited to the scope of the desktop and perhaps some embedded >>>>> devices. Many predict that the PC in its current form will largely >>>>> disappear in the next 5 years so where would that leave JavaFX? >>>>> >>>>> Java developers are largely passionate about their language and do not want >>>>> to learn Objective C or C# or whatever language is required on each device. >>>>> >>>>> In my opinion, being able to code in Java and deploy to Windows, Linux, >>>>> MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as >>>>> the best platform for client side software development on the planet. >>>>> Please Oracle, don't miss this enormous opportunity! What do we have to do >>>>> to convince you that this REALLY IS A GOOD IDEA? >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From: Tobias Bley [mailto:tobi at ultramixer.com] >>>>> Sent: Tuesday, 9 October 2012 18:10 >>>>> To: John C. Turnbull >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>>>> >>>>> Hi guys, >>>>> >>>>> first of all: that's not an official press release of Oracle... >>>>> >>>>> second: please take part of the current discussion on JavaFX forum about >>>>> "JavaFX on iOS, Android and Windows 8": >>>>> https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 >>>>> >>>>> Richard Bair there asked for developers and companies who have a real >>>>> (commercial) interested in using JavaFX on iOS.... So please please write >>>>> Richard an email to show him your real interested. >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> blog.software4java.com >>>>> >>>>> >>>>> >>>>> Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : >>>>> >>>>>> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >>>>>> Jellema (and retweeted by Nicolas Lorain) the following is stated: >>>>>> >>>>>> >>>>>> >>>>>> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >>>>>> Android and Windows Mobile phones are provided by the respective >>>>>> platforms, there is no room there for JavaFX. JavaFX is targeted at >>>>>> the desktop to replace Swing and at smaller devices that run embedded >>>>> Java." >>>>>> >>>>>> >>>>>> >>>>>> This is extremely disappointing especially after having seen demos of >>>>>> JavaFX running on iOS and Android devices. >>>>>> >>>>>> >>>>>> >>>>>> Can someone explain why this decision has been made? >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> -jct >>>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Peter Pilgrim, >>> **Java Champion**, >>> Java EE Software Development / Design / Architect for financial >>> services, London, UK >>> >>> JavaFX ++ Scala ++ Groovy ++ Android ++ Java >>> >>> :: http://www.xenonique.co.uk/blog/ :: >>> :: http://twitter.com/peter_pilgrim :: >>> :: http://audio.fm/profile/peter_pilgrim :: >>> :: Skype Call peter_pilgrim :: >>> :: http://java-champions.java.net/ :: >> > From michael.heinrichs at oracle.com Tue Oct 9 08:10:06 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Tue, 9 Oct 2012 17:10:06 +0200 Subject: property improvement suggestion In-Reply-To: <50741F5F.3050006@tbee.org> References: <50712B02.8040306@tbee.org> <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> <50730880.6080307@tbee.org> <28B1593F-CE88-4387-9193-C34502E29FDE@oracle.com> <50741F5F.3050006@tbee.org> Message-ID: <03A199C9-D2C7-4521-89E6-2CB208BB9E39@oracle.com> The Binding API is full of hidden treasures. ;-) Please file JIRA issues for all features you are missing. Allowing constraints on properties is a much more challenging task. But first we need to decide what we actually want. Here are my thoughts on the topics mentioned so far: 1) Class vs. Instance I think being able to define constraints on class level, i.e. the constraints apply to all instances of a bean, is a must. Being able to define constraints for specific instances is a nice-to-have. It would remove the need for a lot of boiler plate code on one hand, but there is also a danger to make things really complex. Some experimentation is required IMO before a decision can be made. 2) Exceptions vs. Auto-Correction There are valid use cases that require Exceptions, but Exceptions do not play nicely with lazy evaluation. IMO both are required. Exceptions would enforce eager evaluation, i.e. the Exception is thrown on setting the value. We have this differentiation already with InvalidationListeners vs. ChangeListeners, it seems natural to have two types of constraints. 3) Specification of Constraints Overriding the setter would only be possible if constraints are defined on class level only. The behavior of properties is usually defined by overriding its methods, so this would be a good choice then. If we want to allow defining constraints per instance, we need to pass it in. We probably want to accept some SAM type and provide predefined helpers for common case, e.g. for setting a range on a NumberProperty, specifying a list of legal values for an ObjectProperty etc. - Michael On 09.10.2012, at 14:58, Tom Eugelink wrote: > Aha. I did not know that "when" existed. I'm sorry, an oversight. That indeed covers the whole constraint part of binding, a clamp and otherwiseWhen would indeed be nice additions. > > Leaves the situation where it is preferable to set constraints on the property instead of having to repeat it in every binding. > > I'll see if I run into any other situations. > > Tom > > > > On 2012-10-09 14:19, Michael Heinrichs wrote: >> Hi Tom, >> >> in my opinion your first case is already covered by the Binding API itself. The Binding API allows you to define all kind of expressions. For the most common ones there are methods in the JavaFX library and you can always add your own implementation. E.g. you could rewrite your example like this: >> >> appointment.duration().bind( >> when(area.height().greaterThan(0)) >> .then(area.height().multiply(pixelToSecondsFactor)) >> .otherwise(0)); >> >> If possible, we should avoid a new concept to express something that could be expressed straightforward using an existing concepts. Adding a new concept increases the complexity tremendously, because you have to understand how the new concept works with all possible combinations of existing concepts. >> >> What I would suggest instead is to think about additions to the Binding API that make your code easier. Maybe we should add clampTo(min, max) to NumberExpression, so that you could write >> >> area.height().multiply(pixelToSecondsFactor).clampTo(0, Integer.MAX) >> >> Looking at your other examples for further ideas, maybe we need to add a otherwiseWhen() method to write something like when().then().otherwiseWhen().then().otherwise(). Maybe we need switch-case within bindings. >> >> Do you have any examples of constraints that can not be covered by the binding API or some small addition to it? >> >> - Michael >> >> >> >> >> On 08.10.2012, at 19:08, Tom Eugelink wrote: >> >>> Hmmmm, not sure we are on the same line here. The essence of the proposal is that the user of a property can specify a constraint. Let's see how I can make a good argument for this. >>> >>> There are two angles. The first being the binding; I recently recoded my Agenda (Google Calendar) control to use binding and really liked that, but I ran into some omissions IMHO. Suppose I bind an appointment height to the duration of the appointment. So, basically you get something like: >>> >>> appointment.duration().bind(area.height().multiply(pixelToSecondsFactor)); >>> >>> A UI feature is that the user can resize an area by dragging the end time (bottom of the rectangle) with the mouse. Theoretically he can drag the mouse above the start time, resulting in a negative height. The binding will then result in a negative duration, and that is something I do not want. The problem is that I am not the owner of the appointment (it comes from the business model), nor the owner of the area (it's a rectangle; and even if I extend Rectangle, I cannot extend the height property). So I need a way to prevent that situation to occur, because the BM code handling the appointment will never expect a negative duration, or an end time that falls before the start time (the constraints of the BM entity :-). >>> >>> Because the binding allows calculation, it almost requires constraints, or a decent hook system. Or I must find a way to get a man-in-the-middle setup (I did that with JGoodies binding), but native constraints are better. >>> >>> The second angle is that the properties concept is a powerful one, and I expect them to become popular in none JavaFX contexts as well. Formal properties is something the community have been begging for for a long time. These other context, say a mortgage business model, may be less lenient towards the possible values a property can have and require a strict handling of the values, and maybe (yes) throw exceptions. Further more these constraints may be fairly complex, so a simple "if a then b" might not cut it. So if we're contemplating constraints, then let's look at the bigger picture. >>> >>> Now, I'm not knowledgable enough on the implementation that I can discuss the implementation details, but I understand the problem of the lazy binding your describing. Maybe, in light of the bigger picture, eager bindings are important. I only know that being able to hook into binding to make sure a value never goes out of range, both directly on a property (as a permanent constraint) or inside a binding chain (as a local constraint), seems like a very natural thing. >>> >>> Tom >>> >>> >>> >>> On 2012-10-08 16:26, Richard Bair wrote: >>>> It looks like there are two elements of this proposal. The first is that the author of a bean might want to specify some inherent constraint >>>> on the property -- such as, it should never be null, or it should never be negative. The second is that a user of the property might want to constrain the property in some way -- such as, in my app the width should never be negative. >>>> >>>> I see the value immediately in the first (in fact, this has always been a problem with our properties, going all the way back to JavaFX Script), but I struggle to see much value in the second. Not because you might not want to do this sort of thing, but because the first (inherent constraints) is not presently possible at all, while the second (app constraints) you can already do in your application code, one way or another. I am inclined not to add API for cases that are already solvable, unless it turns out to be so compelling and widely used. >>>> >>>> From a semantic point of view, binding was a "mathematical" relationship between two properties in JavaFX Script, such that when you read code like: >>>> >>>> x: bind 10 * someProperty >>>> >>>> you new that "x" was going to be 10 * someProperty, and not anything else. Of course as an API designer I have never liked that because I have to handle exceptional conditions in my code rather than being able to verify that a property can never go outside its valid range of values. >>>> >>>> I am pleased to see your proposal doesn't include throwing exceptions -- I think throwing an exception from a property on invalid input is a very bad idea. The problem is in lazy evaluation of properties. Suppose: >>>> >>>> widthProperty().bind(someProperty) >>>> >>>> Further suppose width is constrained to never be < 0, and somebody were to try to set it to be < 0 it would throw an exception. In this case, someProperty might be set to -10 at some time, and the width property is invalidated. But until somebody tries to read width, it won't throw the exception. So the problem with bound properties & exceptions is that the exception is not thrown at the time the error is introduced, but rather at the time the error is discovered, which turns out to be an awful behavior. >>>> >>>> However your proposal instead says "if it is outside the allowable range, I will just adjust the value to keep it within the allowable range". I think this is a really good idea. The property implementations would have to be modified such that on read, instead of: >>>> >>>> /** >>>> * {@inheritDoc} >>>> */ >>>> @Override >>>> public boolean get() { >>>> valid = true; >>>> return observable == null ? value : observable.get(); >>>> } >>>> >>>> we instead do something like: >>>> >>>> /** >>>> * {@inheritDoc} >>>> */ >>>> @Override >>>> public boolean get() { >>>> if (!valid && observable != null) { >>>> value = constrain(observable.get()); >>>> } >>>> valid = true; >>>> return observable == null ? value : observable.get(); >>>> } >>>> >>>> >>>> And add a protected 'constrain' method. Or perhaps we can just call the "set" method and let the set method deal with constraining. This would require taking some care, however, because it means set methods will now be called even when the property is bound which is different than at present, and calling super.set() would throw an exception in the case that it is bound. But still, as a Java developer I'm used to doing constraining from within the setter, so doing it inside the set seems the most natural, but this would be an area that needs to be figured out. >>>> >>>> Richard >>>> >>>> On Oct 7, 2012, at 12:10 AM, Tom Eugelink wrote: >>>> >>>>> As far as I understand, the current the approach is that properties should accept any value, and the usage of these properties have to work with that. Personally I'm prefer a different approach, because I feel the responsibility to have sensible values should be constrained to one place. Therefore I often override the set method of my properties to make sure the value is within the range that my remaining code expect it to be; either by throwing an exception or by clamping the value to a range. >>>>> >>>>> But this I can only do with my own properties. It would be nice to also do this to existing properties and therefor I would like to suggest to extend the property concept with constraints or conditions. The important point being that these constraints are applied before the value is set, and not (like a change listener approach) afterwards and then correct value; a value should never be outside it allowed range. >>>>> >>>>> The constraints or conditions could have an if-then structure: if value < 0 then 0. An example in Java 8 lambda notation: >>>>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>>>> >>>>> This would also be something relevant to binding, especially when doing calculations: >>>>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); >>>>> >>>>> There is a difference between a permanent constraint on the property and a constraint only applicable to a binding. The notation above is is too similar to my taste and too easily a binding constraint can become a property constaint. To make this difference more explicit, the word "if" could be better on binding: >>>>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>>>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); >>>>> >>>>> Something to think about is how far these constraints should be taken. These are simple if-then constraints. But what if "else", "elsif" constructions or "case" statements are needed to express the range? In order to keep all options open, maybe the best approach would be to provide constraining listeners. A constraining listener would get the to-be-set value as a parameter and return the new value. For example: >>>>> >>>>> widthProperty.addConstrainingListener( v -> { if (v < 0.0) return 0.0; return v; } ); >>>>> >>>>> or in normal notation: >>>>> >>>>> widthProperty.addConstrainingListener( new ConstaintListener() { >>>>> public Double constaint(Double value) { >>>>> if (value < 0.0) return 0.0; >>>>> return value; >>>>> } >>>>> }); >>>>> >>>>> (NB: I'm not sure how to use Java 8 lambda with the addListener method, differentiating between a change, invalidation and constraint listener.) >>>>> >>>>> This constraining listener approach would allow for all scenario's to be handled. So that is the final improvement I would like to suggest: constrainting listeners. >>>>> someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return 0.0; return v; } ); >>>>> someNode.widthProperty().bind( otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) return 0.0; return v; } ) ); >>>>> >>>>> And if possible normal constraints, because that is a easier notation. >>>>> >>>>> I'd like to hear if I'm making sense or am missing the ball completely. >>>>> >>>>> Tom > From jmartine_1026 at yahoo.com Tue Oct 9 08:26:12 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 9 Oct 2012 08:26:12 -0700 (PDT) Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <50743C12.3050707@broadpark.no> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> <50743C12.3050707@broadpark.no> Message-ID: <1349796372.61144.YahooMailNeo@web161504.mail.bf1.yahoo.com> My main concern is desktop and not mobile. ?There are limited resources working on JFX so I need to speak up to nudge those resources towards the things that matter to me and that's desktop and browser games. ?Sounds like I might be in the minority here. If I am forced to find a pro for mobile support then I would say that having mobile support makes the community bigger and happier and keeps JFX vibrant in that sense. ?And also JFX on mobile will increase the?likelihood?of utilizing my JFX experience to work for a company doing mobile apps. As far as direction, I would ask that JFX really make a push for desktop/browser gaming.... I'm being bias here. thanks? jose ________________________________ From: Knut Arne Vedaa To: openjfx-dev at openjdk.java.net Sent: Tuesday, October 9, 2012 11:00 AM Subject: Re: No JavaFX for iOS, Android or WP - why not? I agree 100% with the general sentiment. Not supporting JavaFX on these devices, if it is technically possible, would be an incredibly stupid decision. But I guess we're preaching to the choir here. Knut Arne Vedaa On 09.10.2012 16:01, Daniel Zwolenski wrote: > https://forums.oracle.com/forums/message.jspa?messageID=10623319#10623319 > > Community minus 1 from me if this issue goes the way it's going. The make or break issue has always been and will always be deployment and that includes desktop and mobile. After a year or two making noise about this we're going backwards. > > Anyone remember why Java became so popular? Remember write-once-run-anywhere? Now it's write once, go through as much build hassles as an old fashioned c++ app for each platform (and variant) and run on even less platforms than c++ will work on. > > Can't decide if I'm more frustrated, angry or sad. > > > > On 09/10/2012, at 10:25 PM, Tobias Bley wrote: > >> There are two steps to go: >> >> 1. Porting Prism/glass to iOS >> 2. use AOT compiler >> >> Both steps were finished in 2011 yet (http://java.dzone.com/articles/javaone-2011-javafx-20) >> >> >> >> >> >> >> Am 09.10.2012 um 13:11 schrieb Peter Pilgrim : >> >>> Hi >>> >>> On the other hand, the whole of JavaFX is going to be open sourced by 2013. >>> So what it stopping someone porting the lower architecture to iOS? >>> Therefore one strategy is to wait until the open source is there and >>> then port it and write the bridging layer between Java and native >>> Apple libraries, which I guess would be Objective C. I don't know >>> really. Of course, that would require expertise in Apple native >>> libraries. Nevertheless it can be done by somebody. The hard part is >>> bundling a JRE into a form that can run in iOS app store, and also the >>> pass by the gatekeeper. >>> >>> On 9 October 2012 01:23, Tobias Bley wrote: >>>> John, many thanks for your post! I absolutely agree with you. JavaFX without real(!) crossplatform support on the major platforms is an absolutely MUST HAVE. I can't understand Oracles point of view ("we don't know if developers and companies have a real interested in JavaFX2 on mobile) too - that's unbelievable! >>>> >>>> John, please write to Richard Bair, he wants to know our opinion about this topic! >>>> >>>> Best, >>>> Tobi >>>> >>>> >>>> -- >>>> Tobias Bley >>>> Chief Executive Officer >>>> >>>> -------------------------------------------------------- >>>> >>>> UltraMixer Digital Audio Solutions >>>> Schillerstra?e? 29 >>>> D-01326 Dresden >>>> Germany >>>> >>>> -------------------------------------------------------- >>>> bley at ultramixer.com? http://www.ultramixer.com >>>> >>>> >>>> >>>> Am 09.10.2012 um 10:18 schrieb "John C. Turnbull" : >>>> >>>>> Hi Tobi, >>>>> >>>>> I realise it's not an official Oracle statement but that's part of the >>>>> problem; Oracle didn't make an official statement on this at JavaOne when I >>>>> suspect many people were hoping for one.? In fact, I seem to remember a >>>>> session titled something like "JavaFX on iOS" was being tossed around for >>>>> possible inclusion in this year's JavaOne some time ago. >>>>> >>>>> It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet >>>>> Oracle are waiting for clear commercial interest to justify such support? >>>>> As has been pointed out several times, JavaFX cannot be considered a success >>>>> if it is limited to the scope of the desktop and perhaps some embedded >>>>> devices.? Many predict that the PC in its current form will largely >>>>> disappear in the next 5 years so where would that leave JavaFX? >>>>> >>>>> Java developers are largely passionate about their language and do not want >>>>> to learn Objective C or C# or whatever language is required on each device. >>>>> >>>>> In my opinion, being able to code in Java and deploy to Windows, Linux, >>>>> MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as >>>>> the best platform for client side software development on the planet. >>>>> Please Oracle, don't miss this enormous opportunity!? What do we have to do >>>>> to convince you that this REALLY IS A GOOD IDEA? >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From: Tobias Bley [mailto:tobi at ultramixer.com] >>>>> Sent: Tuesday, 9 October 2012 18:10 >>>>> To: John C. Turnbull >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>>>> >>>>> Hi guys, >>>>> >>>>> first of all: that's not an official press release of Oracle... >>>>> >>>>> second: please take part of the current discussion on JavaFX forum about >>>>> "JavaFX on iOS, Android and Windows 8": >>>>> https://forums.oracle.com/forums/thread.jspa?threadID=2448461&tstart=0 >>>>> >>>>> Richard Bair there asked for developers and companies who have a real >>>>> (commercial) interested in using JavaFX on iOS.... So please please write >>>>> Richard an email to show him your real interested. >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> blog.software4java.com >>>>> >>>>> >>>>> >>>>> Am 09.10.2012 um 08:24 schrieb "John C. Turnbull" : >>>>> >>>>>> I didn't have the pleasure of being at JavaOne but in a blog by Lucas >>>>>> Jellema (and retweeted by Nicolas Lorain) the following is stated: >>>>>> >>>>>> >>>>>> >>>>>> "JavaFX is no longer intended for use on SmartPhones. The iPhone, >>>>>> Android and Windows Mobile phones are provided by the respective >>>>>> platforms, there is no room there for JavaFX. JavaFX is targeted at >>>>>> the desktop to replace Swing and at smaller devices that run embedded >>>>> Java." >>>>>> >>>>>> >>>>>> >>>>>> This is extremely disappointing especially after having seen demos of >>>>>> JavaFX running on iOS and Android devices. >>>>>> >>>>>> >>>>>> >>>>>> Can someone explain why this decision has been made? >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> -jct >>>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Peter Pilgrim, >>> **Java Champion**, >>> Java EE Software Development / Design / Architect for financial >>> services, London, UK >>> >>> JavaFX ++ Scala ++ Groovy ++? Android ++ Java >>> >>> :: http://www.xenonique.co.uk/blog/? :: >>> :: http://twitter.com/peter_pilgrim :: >>> :: http://audio.fm/profile/peter_pilgrim? :: >>> :: Skype Call peter_pilgrim :: >>> :: http://java-champions.java.net/ :: >> > From steve.x.northover at oracle.com Tue Oct 9 08:29:11 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 09 Oct 2012 11:29:11 -0400 Subject: property improvement suggestion In-Reply-To: <50730880.6080307@tbee.org> References: <50712B02.8040306@tbee.org> <8307B987-CFEB-4BC3-AE6B-057F4DED07C0@oracle.com> <50730880.6080307@tbee.org> Message-ID: <507442C7.5040406@oracle.com> Is Bindings.when() your friend here? Here is some example code that sets the fill color of a scene based on height: scene.fillProperty().bind( Bindings.when(scene.heightProperty().lessThan(100)) .then(Color.RED) .otherwise(Color.BLUE)); Steve On 08/10/2012 1:08 PM, Tom Eugelink wrote: > Hmmmm, not sure we are on the same line here. The essence of the > proposal is that the user of a property can specify a constraint. > Let's see how I can make a good argument for this. > > There are two angles. The first being the binding; I recently recoded > my Agenda (Google Calendar) control to use binding and really liked > that, but I ran into some omissions IMHO. Suppose I bind an > appointment height to the duration of the appointment. So, basically > you get something like: > > appointment.duration().bind(area.height().multiply(pixelToSecondsFactor)); > > > A UI feature is that the user can resize an area by dragging the end > time (bottom of the rectangle) with the mouse. Theoretically he can > drag the mouse above the start time, resulting in a negative height. > The binding will then result in a negative duration, and that is > something I do not want. The problem is that I am not the owner of the > appointment (it comes from the business model), nor the owner of the > area (it's a rectangle; and even if I extend Rectangle, I cannot > extend the height property). So I need a way to prevent that situation > to occur, because the BM code handling the appointment will never > expect a negative duration, or an end time that falls before the start > time (the constraints of the BM entity :-). > > Because the binding allows calculation, it almost requires > constraints, or a decent hook system. Or I must find a way to get a > man-in-the-middle setup (I did that with JGoodies binding), but native > constraints are better. > > The second angle is that the properties concept is a powerful one, and > I expect them to become popular in none JavaFX contexts as well. > Formal properties is something the community have been begging for for > a long time. These other context, say a mortgage business model, may > be less lenient towards the possible values a property can have and > require a strict handling of the values, and maybe (yes) throw > exceptions. Further more these constraints may be fairly complex, so a > simple "if a then b" might not cut it. So if we're contemplating > constraints, then let's look at the bigger picture. > > Now, I'm not knowledgable enough on the implementation that I can > discuss the implementation details, but I understand the problem of > the lazy binding your describing. Maybe, in light of the bigger > picture, eager bindings are important. I only know that being able to > hook into binding to make sure a value never goes out of range, both > directly on a property (as a permanent constraint) or inside a binding > chain (as a local constraint), seems like a very natural thing. > > Tom > > > > On 2012-10-08 16:26, Richard Bair wrote: >> It looks like there are two elements of this proposal. The first is >> that the author of a bean might want to specify some inherent constraint >> on the property -- such as, it should never be null, or it should >> never be negative. The second is that a user of the property might >> want to constrain the property in some way -- such as, in my app the >> width should never be negative. >> >> I see the value immediately in the first (in fact, this has always >> been a problem with our properties, going all the way back to JavaFX >> Script), but I struggle to see much value in the second. Not because >> you might not want to do this sort of thing, but because the first >> (inherent constraints) is not presently possible at all, while the >> second (app constraints) you can already do in your application code, >> one way or another. I am inclined not to add API for cases that are >> already solvable, unless it turns out to be so compelling and widely >> used. >> >> From a semantic point of view, binding was a "mathematical" >> relationship between two properties in JavaFX Script, such that when >> you read code like: >> >> x: bind 10 * someProperty >> >> you new that "x" was going to be 10 * someProperty, and not anything >> else. Of course as an API designer I have never liked that because I >> have to handle exceptional conditions in my code rather than being >> able to verify that a property can never go outside its valid range >> of values. >> >> I am pleased to see your proposal doesn't include throwing exceptions >> -- I think throwing an exception from a property on invalid input is >> a very bad idea. The problem is in lazy evaluation of properties. >> Suppose: >> >> widthProperty().bind(someProperty) >> >> Further suppose width is constrained to never be < 0, and somebody >> were to try to set it to be < 0 it would throw an exception. In this >> case, someProperty might be set to -10 at some time, and the width >> property is invalidated. But until somebody tries to read width, it >> won't throw the exception. So the problem with bound properties & >> exceptions is that the exception is not thrown at the time the error >> is introduced, but rather at the time the error is discovered, which >> turns out to be an awful behavior. >> >> However your proposal instead says "if it is outside the allowable >> range, I will just adjust the value to keep it within the allowable >> range". I think this is a really good idea. The property >> implementations would have to be modified such that on read, instead of: >> >> /** >> * {@inheritDoc} >> */ >> @Override >> public boolean get() { >> valid = true; >> return observable == null ? value : observable.get(); >> } >> >> we instead do something like: >> >> /** >> * {@inheritDoc} >> */ >> @Override >> public boolean get() { >> if (!valid && observable != null) { >> value = constrain(observable.get()); >> } >> valid = true; >> return observable == null ? value : observable.get(); >> } >> >> >> And add a protected 'constrain' method. Or perhaps we can just call >> the "set" method and let the set method deal with constraining. This >> would require taking some care, however, because it means set methods >> will now be called even when the property is bound which is different >> than at present, and calling super.set() would throw an exception in >> the case that it is bound. But still, as a Java developer I'm used to >> doing constraining from within the setter, so doing it inside the set >> seems the most natural, but this would be an area that needs to be >> figured out. >> >> Richard >> >> On Oct 7, 2012, at 12:10 AM, Tom Eugelink wrote: >> >>> As far as I understand, the current the approach is that properties >>> should accept any value, and the usage of these properties have to >>> work with that. Personally I'm prefer a different approach, because >>> I feel the responsibility to have sensible values should be >>> constrained to one place. Therefore I often override the set method >>> of my properties to make sure the value is within the range that my >>> remaining code expect it to be; either by throwing an exception or >>> by clamping the value to a range. >>> >>> But this I can only do with my own properties. It would be nice to >>> also do this to existing properties and therefor I would like to >>> suggest to extend the property concept with constraints or >>> conditions. The important point being that these constraints are >>> applied before the value is set, and not (like a change listener >>> approach) afterwards and then correct value; a value should never be >>> outside it allowed range. >>> >>> The constraints or conditions could have an if-then structure: if >>> value < 0 then 0. An example in Java 8 lambda notation: >>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>> >>> This would also be something relevant to binding, especially when >>> doing calculations: >>> someNode.widthProperty().bind( >>> otherNode.widthProperty().substract(10).*constraint*( w -> w < 0, 0) ); >>> >>> There is a difference between a permanent constraint on the property >>> and a constraint only applicable to a binding. The notation above is >>> is too similar to my taste and too easily a binding constraint can >>> become a property constaint. To make this difference more explicit, >>> the word "if" could be better on binding: >>> someNode.widthProperty().*constraint*( w -> w < 0, 0); >>> someNode.widthProperty().bind( >>> otherNode.widthProperty().substract(10).*if*( w -> w < 0, 0) ); >>> >>> Something to think about is how far these constraints should be >>> taken. These are simple if-then constraints. But what if "else", >>> "elsif" constructions or "case" statements are needed to express the >>> range? In order to keep all options open, maybe the best approach >>> would be to provide constraining listeners. A constraining listener >>> would get the to-be-set value as a parameter and return the new >>> value. For example: >>> >>> widthProperty.addConstrainingListener( v -> { if (v < 0.0) return >>> 0.0; return v; } ); >>> >>> or in normal notation: >>> >>> widthProperty.addConstrainingListener( new >>> ConstaintListener() { >>> public Double constaint(Double value) { >>> if (value < 0.0) return 0.0; >>> return value; >>> } >>> }); >>> >>> (NB: I'm not sure how to use Java 8 lambda with the addListener >>> method, differentiating between a change, invalidation and >>> constraint listener.) >>> >>> This constraining listener approach would allow for all scenario's >>> to be handled. So that is the final improvement I would like to >>> suggest: constrainting listeners. >>> someNode.widthProperty().*constraint*( v -> { if (v < 0.0) return >>> 0.0; return v; } ); >>> someNode.widthProperty().bind( >>> otherNode.widthProperty().substract(10).*if*( v -> { if (v < 0.0) >>> return 0.0; return v; } ) ); >>> >>> And if possible normal constraints, because that is a easier notation. >>> >>> I'd like to hear if I'm making sense or am missing the ball completely. >>> >>> Tom > From thoughtslinger at gmail.com Tue Oct 9 08:39:09 2012 From: thoughtslinger at gmail.com (Rick Walker) Date: Tue, 9 Oct 2012 11:39:09 -0400 Subject: No JavaFX for iOS, Android or WP - why not? Message-ID: It is not clear to me whether or not co-bundled apps for iOS and Android tablets have also been ruled out. This is obviously technically feasible from earlier demos. Can anyone clarify this? >From http://technology.amis.nl/2012/10/08/javaone-2012-the-big-stories/ "JavaFX is no longer intended for use on SmartPhones" "Note: Java Applets are on their way out" From pedro.duquevieira at gmail.com Tue Oct 9 09:10:16 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Oct 2012 17:10:16 +0100 Subject: No JavaFX for iOS, Android or WP - why not? Message-ID: @jose You won't have any chance with browser gaming either. The current applet situation is non-functional, you can't get an applet working reliably across different browsers. Deployment is the major issue with JavaFX. No web apps and no mobile apps are currently possible, I'm sorry to say that I don't think JavaFX will become the RIA platform of choice in this scenario, not even close really. :( Thanks, best regards, > My main concern is desktop and not mobile. ?There are limited resources > working on JFX so I need to speak up to nudge those resources towards the > things that matter to me and that's desktop and browser games. ?Sounds like > I might be in the minority here. > If I am forced to find a pro for mobile support then I would say that > having mobile support makes the community bigger and happier and keeps JFX > vibrant in that sense. ?And also JFX on mobile will increase > the?likelihood?of utilizing my JFX experience to work for a company doing > mobile apps. > As far as direction, I would ask that JFX really make a push for > desktop/browser gaming.... I'm being bias here. > thanks? > jose -- Pedro Duque Vieira From daniel.fuchs at oracle.com Tue Oct 9 09:16:58 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 09 Oct 2012 18:16:58 +0200 Subject: Is there any source code for the JavaFX SceneBuilder In-Reply-To: References: Message-ID: <50744DFA.2040107@oracle.com> Hi Werner, Yes - being able to specify the classpath as parameter when opening a file is definitely a possibility - although the various IDE would then need a special plugin for making use of that - simply relying on file association would not make it possible to pass that additional parameter - would it? Classpath relative URL for the resource bundle file would be a possibility - but I think in most cases you will want to point to real file - so that SceneBuilder immediately picks up the changes when you add new keys. If Scene Builder points to the file in the classpath, then you will have to rebuild & force scenebuilder to refresh its classloader (using "Resolve Unknown Types... + Apply) before you can see the changes in Scene Builder window. Also you won't be able to use the file chooser to select the .properties file that SB should use to resolve the keys. So I'm not sure that using a Classpath relative URL in that case will buy you much. BTW - I was wondering whether being able to define a 'default' classpath in the preferences (i.e. a classpath that would be used to load any FXML file) would be a good idea? This way - if you have some custom component library that you always use - you could add it once in the default classpath, and you wouldn't have to add it to any specific FXML file any longer... And since it would be in the tool preferences, you would be able to specify it using an absolute path - and you wouldn't need to use any PI for that... best regards, -- daniel On 10/9/12 5:26 PM, openjfx-dev-request at openjdk.java.net wrote: > Message: 1 > Date: Tue, 9 Oct 2012 16:46:36 +0200 > From: Werner Lehmann > Subject: Re: Is there any source code for the JavaFX SceneBuilder > To:openjfx-dev at openjdk.java.net > Message-ID:<507438CC.3010607 at media-interactive.de> > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed > > Daniel, > > thanks for the explanation. I wasn't aware that the classpath could be > set with PI's in FXML. > > In my opinion this could be used as a workaround for now but does not > really replace full IDE integration - at least not in a way how I would > envision it. The relative paths are a problem when it comes to > refactoring, and especially when you want to reuse the same lines in > different FXMLs: copy & paste of those PI's requires me to think about > how many ../../ I'd need, depending on the package of the FXML at hand. > And I don't even want to use the DRY pattern... > > Usually the IDE manages the classpath for me, it would be redundant to > add that to the FXML. I think this is similar to imports in a plain Java > file: you say what you want but not where to find it. This information > is provided separately. Perhaps via command line "-cp" parameter, etc. > Furthermore, I believe it would be more practical to specify the > resource bundle relative to the classpath as with any other control import. > > Maybe this is something intended for FX8? The roadmap mentions "enhanced > Java IDE integration" but does not provide many details. This would be a > pity for me because I'll be tied to JRE 6/7 for a quite a while longer > and could not use this (if necessary we might be able to use JRE8 on > development machines only but that would be less desirable). > > Rgds > Werner From hang.vo at oracle.com Tue Oct 9 09:48:07 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 09 Oct 2012 16:48:07 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121009164812.9182F4724D@hg.openjdk.java.net> Changeset: 3c29ef369f0c Author: hudson Date: 2012-10-04 16:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3c29ef369f0c Added tag 8.0-b59 for changeset da3f3de73066 ! .hgtags Changeset: b06b91a885a0 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-09 09:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b06b91a885a0 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt From richard.bair at oracle.com Tue Oct 9 09:51:30 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 9 Oct 2012 09:51:30 -0700 Subject: Support for grouped rendered opacity? In-Reply-To: <81B3F8A1-F0B0-43C2-8052-69C35FBBB2B2@rockit.dk> References: <81B3F8A1-F0B0-43C2-8052-69C35FBBB2B2@rockit.dk> Message-ID: <8BB951A1-C522-4F60-8636-8BB4A5DCF977@oracle.com> That should absolutely not be happening. In fact, it is explicitly the semantic of 2D opacity that we render the node into an image, and then apply the opacity to the image. So I don't know how the individual child node's opacity could be changing. On Oct 9, 2012, at 1:44 AM, Randahl Fink Isaksen wrote: > Is it possible to change the opacity of a rendered node tree rather than affecting the opacity of each individual node? When I am changing the opacity of a panel with multiple node children, what I am seeing is the individual opacities of each child node changing, which is not what I am aiming for. > > In one pane I am rendering a 3D house using multiple 2D shapes, and I wish to make the pane fade away by gradually decreasing its opacity; but when I alter the opacity of the pane, what I am seeing is the individual walls of the house becoming semitransparent revealing the geometry of the house. What I was hoping to achieve was to change the opacity of the *rendered* pane. Is that possible? > > Randahl > > From richard.bair at oracle.com Tue Oct 9 10:09:04 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 9 Oct 2012 10:09:04 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <005101cda5e6$c6d7b960$54872c20$@com.au> References: <005101cda5e6$c6d7b960$54872c20$@com.au> Message-ID: > "JavaFX is no longer intended for use on SmartPhones. The iPhone, Android > and Windows Mobile phones are provided by the respective platforms, there is > no room there for JavaFX. JavaFX is targeted at the desktop to replace Swing > and at smaller devices that run embedded Java." This is certainly not the position that I've taken or that the Java client organization has taken. We do not at this time have iOS or Android on our official roadmaps, but we have not taken a position to say that JavaFX is not (or will not) be used on smart phones. Richard From richard.bair at oracle.com Tue Oct 9 10:20:17 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 9 Oct 2012 10:20:17 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> Message-ID: <4FD0A50B-2442-4384-9259-6BEFA3487D89@oracle.com> > Everyone knows from the begining Oracle does not give a shit about the > community. That is neither true, nor helpful. What happens in the Solaris line of business is different from the Hudson line of business is different from the Java line of business. In the Java group, we are very concerned about community involvement. Richard From richard.bair at oracle.com Tue Oct 9 10:28:37 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 9 Oct 2012 10:28:37 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: > It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet > Oracle are waiting for clear commercial interest to justify such support? > As has been pointed out several times, JavaFX cannot be considered a success > if it is limited to the scope of the desktop and perhaps some embedded > devices. Many predict that the PC in its current form will largely > disappear in the next 5 years so where would that leave JavaFX? > > Java developers are largely passionate about their language and do not want > to learn Objective C or C# or whatever language is required on each device. > > In my opinion, being able to code in Java and deploy to Windows, Linux, > MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as > the best platform for client side software development on the planet. > Please Oracle, don't miss this enormous opportunity! What do we have to do > to convince you that this REALLY IS A GOOD IDEA? The anger and passion exhibited on this thread is very gratifying and very helpful. Even more helpful would be to funnel as many developers to me as you find that have a demand for FX on smartphones and tablets. You'll not find more passionate partisans for JavaFX than here in the Java group. Being able to demonstrate industry demand and commitment is what we need. Of course, when JavaFX is open sourced (as Hasan announced at JavaOne we will complete shortly), then of course anybody could do a port to iOS / Android. The question isn't about whether or not JavaFX will be on smart phones -- it will be. The question is who is funding it and who is supporting it. Of course many of us feel that supporting iOS and Android is at least as important as Windows and Mac. However, it is hard to fault the guys paying the bills for asking for some evidence of that viewpoint. Customers beating on our doors demanding support for FX on these devices is exactly that evidence. But in any case, this is an open source project, and regardless of whether Oracle foots the bill, I have no doubt that FX will be on iOS, Android, and Windows Metro. If you'd like to help, funnel your demands and use cases to me (and they have all the more weight when there is a real commercial demand behind them)! Richard From richard.bair at oracle.com Tue Oct 9 10:29:45 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 9 Oct 2012 10:29:45 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: Message-ID: <62864924-F456-4453-A648-2A2F9BF7FFFB@oracle.com> I replied to this on another thread just now, perhaps you have already seen it. This isn't our position. On Oct 9, 2012, at 8:39 AM, Rick Walker wrote: > It is not clear to me whether or not co-bundled apps for iOS and Android > tablets have also been ruled out. This is obviously technically feasible > from earlier demos. Can anyone clarify this? > >> From http://technology.amis.nl/2012/10/08/javaone-2012-the-big-stories/ > > "JavaFX is no longer intended for use on SmartPhones" > "Note: Java Applets are on their way out" From lehmann at media-interactive.de Tue Oct 9 10:34:25 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 9 Oct 2012 19:34:25 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <4FD0A50B-2442-4384-9259-6BEFA3487D89@oracle.com> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <43734010-3906-4067-B759-F06EA56A0DFD@gmail.com> <4FD0A50B-2442-4384-9259-6BEFA3487D89@oracle.com> Message-ID: <50746021.1090404@media-interactive.de> FWIW, the community support on this mailing list is outstanding in my opinion. Usually it does not take more than a day to even get replies directly from Oracle staff. And suggestions are discussed with an open mind. Compare that to the cost and response time of a support contract. Rgds Werner On 09.10.2012 19:20, Richard Bair wrote: > In the Java group, we are very concerned about community involvement. From roman at kennke.org Tue Oct 9 10:44:45 2012 From: roman at kennke.org (Roman Kennke) Date: Tue, 09 Oct 2012 19:44:45 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: <1349804685.24641.3.camel@mercury> Am Dienstag, den 09.10.2012, 10:28 -0700 schrieb Richard Bair: > > It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet > > Oracle are waiting for clear commercial interest to justify such support? > > As has been pointed out several times, JavaFX cannot be considered a success > > if it is limited to the scope of the desktop and perhaps some embedded > > devices. Many predict that the PC in its current form will largely > > disappear in the next 5 years so where would that leave JavaFX? > > > > Java developers are largely passionate about their language and do not want > > to learn Objective C or C# or whatever language is required on each device. > > > > In my opinion, being able to code in Java and deploy to Windows, Linux, > > MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as > > the best platform for client side software development on the planet. > > Please Oracle, don't miss this enormous opportunity! What do we have to do > > to convince you that this REALLY IS A GOOD IDEA? > > The anger and passion exhibited on this thread is very gratifying and very helpful. > Even more helpful would be to funnel as many developers to me as you find that > have a demand for FX on smartphones and tablets. You'll not find more passionate > partisans for JavaFX than here in the Java group. Being able to demonstrate > industry demand and commitment is what we need. Of course, when JavaFX is > open sourced (as Hasan announced at JavaOne we will complete shortly), then > of course anybody could do a port to iOS / Android. Yeah, I wanted to say the same. For example, I would certainly be willing to help on an Android port. Open source it already! :-P (And in reply to the 'Oracle doesn't give a frak about community' claim that has been made elsewhere, I used to be on that side some years ago, but have honestly came to believe that this is not (no longer) true, at least not with respect to Java. Kudos Oracle!) Cheers, Roman From neugens.limasoftware at gmail.com Tue Oct 9 11:00:31 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 9 Oct 2012 20:00:31 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <1349804685.24641.3.camel@mercury> References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> <1349804685.24641.3.camel@mercury> Message-ID: 2012/10/9 Roman Kennke : >> The anger and passion exhibited on this thread is very gratifying and very helpful. >> Even more helpful would be to funnel as many developers to me as you find that >> have a demand for FX on smartphones and tablets. You'll not find more passionate >> partisans for JavaFX than here in the Java group. Being able to demonstrate >> industry demand and commitment is what we need. Of course, when JavaFX is >> open sourced (as Hasan announced at JavaOne we will complete shortly), then >> of course anybody could do a port to iOS / Android. > > Yeah, I wanted to say the same. For example, I would certainly be > willing to help on an Android port. Open source it already! :-P > > (And in reply to the 'Oracle doesn't give a frak about community' claim > that has been made elsewhere, I used to be on that side some years ago, > but have honestly came to believe that this is not (no longer) true, at > least not with respect to Java. Kudos Oracle!) I want to join Roman in supporting Richard on this one: *** Oracle is really doing great. *** So guys, please, don't panic! Once the code is out in the wild it's going to be relatively easy to support whatever platform you want, even ones that are too weird to even think of right now. It's the beauty of Open Source after all. Just give Richard some time! :) Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From hang.vo at oracle.com Tue Oct 9 11:03:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 09 Oct 2012 18:03:48 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-25479: [TextField] Text input starts from wrong position. Message-ID: <20121009180351.27FCA47252@hg.openjdk.java.net> Changeset: c0aff81b30ad Author: leifs Date: 2012-10-09 10:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c0aff81b30ad Fixed RT-25479: [TextField] Text input starts from wrong position. Disable caret bias handling util it can be fully supported. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java From goddard at seznam.cz Tue Oct 9 10:53:27 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Tue, 09 Oct 2012 19:53:27 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20No=20JavaFX=20for=20iOS=2C=20Android=20or=20WP=20=2D=20why=20not=3F?= In-Reply-To: <50746021.1090404@media-interactive.de> Message-ID: <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Thanks for stepping in Richard. Jiri ------------ P?vodn? zpr?va ------------ Od: Werner Lehmann P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? Datum: 09.10.2012 19:36:15 ---------------------------------------- FWIW, the community support on this mailing list is outstanding in my opinion. Usually it does not take more than a day to even get replies directly from Oracle staff. And suggestions are discussed with an open mind. Compare that to the cost and response time of a support contract. Rgds Werner On 09.10.2012 19:20, Richard Bair wrote: > In the Java group, we are very concerned about community involvement. From omeuefilipe at gmail.com Tue Oct 9 11:14:55 2012 From: omeuefilipe at gmail.com (Filipe Portes) Date: Tue, 9 Oct 2012 15:14:55 -0300 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <135960.15603.48905-10536-470314817-1349805207@seznam.cz> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: well, what I really will like to see, more than JavaFx running over mobile plataforms, Is java embedded and JavaFX becoming themselves a pure Java mobile plataform. On Tue, Oct 9, 2012 at 2:53 PM, wrote: > Thanks for stepping in Richard. > > Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Werner Lehmann > P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? > Datum: 09.10.2012 19:36:15 > ------------------------------**---------- > > FWIW, the community support on this mailing list is outstanding in my > opinion. Usually it does not take more than a day to even get replies > directly from Oracle staff. And suggestions are discussed with an open > mind. Compare that to the cost and response time of a support contract. > > Rgds > Werner > > On 09.10.2012 19:20, Richard Bair wrote: > >> In the Java group, we are very concerned about community involvement. >> > > > -- Filipe Portes - @filipeportes Java Architect - Senior Java EE/Web JUGLeader Gojava - @gojava From phidias51 at gmail.com Tue Oct 9 12:04:35 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 9 Oct 2012 12:04:35 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: My preference would be to get the following tasks taken care of before Oracle starts throwing resources at supporting tablets, mobile and JavaFX 3D: - *Deployment using Maven.* Although you can build with Maven, there are a lot of hoops that you still have to jump through, and we still don't have the artifacts in an accessible repo. I think Zonski, and others have blogged about this, and kvetched on mailing lists so I won't repeat their comments here. - *Webstart deployment *- this is still problematic. Currently when you push new artifacts to your web server, it's not replacing the existing JARs in the user's cache -- despite what the documentation says. The "special" javafx tags aren't documented well enough and presume that you're using the Ant tools to generate the JNLP. And getting shaded jars is next to impossible. - *Charts* - support for zooming and panning within the charts. Support for drawing on top of charts. - *Support for Swing components within JavaFX. * If the goal is to replace Swing, then this is one of those essential capabilities that needs to be in place. The current examples only demonstrate how to put JavaFX components within Swing applications. Unfortunately, if you want to reuse any existing components (like JFreeCharts for example) within your project, you're SOL at the moment. - *Support for an EventBus.* Currently, there's a lot of point2point event code that you have to write to fire and listen to events. It would make for a much more useable codebase if you could simply publish and subscribe to events at the application level. - *Release the source.* It's a royal pain to have to download the source through mercurial rather than simply read it as you do with the Swing code or download it as you do with any Maven package. There's also some work that needs to be done to make it easier for people to participate. I have 3 accounts at the moment: one for this mailing list, one for the forums, and one for JIRA. Can we just boil that down to one, and let me login with Facebook or Google credentials? Cheers, Mark On Tue, Oct 9, 2012 at 11:14 AM, Filipe Portes wrote: > well, > > what I really will like to see, more than JavaFx running over mobile > plataforms, Is java embedded and JavaFX becoming themselves a pure Java > mobile plataform. > > On Tue, Oct 9, 2012 at 2:53 PM, wrote: > > > Thanks for stepping in Richard. > > > > Jiri > > > > ------------ P?vodn? zpr?va ------------ > > Od: Werner Lehmann > > P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? > > Datum: 09.10.2012 19:36:15 > > ------------------------------**---------- > > > > FWIW, the community support on this mailing list is outstanding in my > > opinion. Usually it does not take more than a day to even get replies > > directly from Oracle staff. And suggestions are discussed with an open > > mind. Compare that to the cost and response time of a support contract. > > > > Rgds > > Werner > > > > On 09.10.2012 19:20, Richard Bair wrote: > > > >> In the Java group, we are very concerned about community involvement. > >> > > > > > > > > > -- > Filipe Portes - @filipeportes > Java Architect - Senior Java EE/Web > JUGLeader Gojava - @gojava > From hang.vo at oracle.com Tue Oct 9 13:18:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 09 Oct 2012 20:18:11 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20121009201822.9896D47257@hg.openjdk.java.net> Changeset: 3c29ef369f0c Author: hudson Date: 2012-10-04 16:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3c29ef369f0c Added tag 8.0-b59 for changeset da3f3de73066 ! .hgtags Changeset: c8deba0d0fb6 Author: Lubomir Nerad Date: 2012-10-09 12:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c8deba0d0fb6 Fix for RT-24681: added javadocs ! javafx-ui-common/src/javafx/stage/DirectoryChooser.java ! javafx-ui-common/src/javafx/stage/FileChooser.java Changeset: b06b91a885a0 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-09 09:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b06b91a885a0 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt Changeset: ea00b638cdd6 Author: leifs Date: 2012-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ea00b638cdd6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlicesTest.java - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlices_builder_Test.java From mcdonnell.john at gmail.com Tue Oct 9 14:20:24 2012 From: mcdonnell.john at gmail.com (John McDonnell) Date: Tue, 9 Oct 2012 22:20:24 +0100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: Commented in line. On 9 October 2012 20:04, Mark Fortner wrote: > My preference would be to get the following tasks taken care of before > Oracle starts throwing resources at supporting tablets, mobile and JavaFX > 3D: > > - *Deployment using Maven.* Although you can build with Maven, there > are a lot of hoops that you still have to jump through, and we still > don't > have the artifacts in an accessible repo. I think Zonski, and others > have > blogged about this, and kvetched on mailing lists so I won't repeat > their > comments here. > I actually though that this was fixed in 1.7u6, but after trying out a simple maven project in 1.7u7 using netbeans, I realized that it was not as easy as I hoped, well without the help of Google and ZenJava blog. For any sort of development I think these sort of things(Maven support, deployment, etc) need to be looked into, it should be easy by now to simple create a maven project and use JavaFX classes without jumping through any hoops. There will be tighter integration of JavaFX in Java 8, when it comes out right? if so thats still over half a year away :( > - *Charts* - support for zooming and panning within the charts. > Support > for drawing on top of charts. > - *Support for Swing components within JavaFX. * If the goal is to > replace Swing, then this is one of those essential capabilities that > needs > to be in place. The current examples only demonstrate how to put JavaFX > components within Swing applications. Unfortunately, if you want to > reuse > any existing components (like JFreeCharts for example) within your > project, > you're SOL at the moment. > Should JavaFX be able to reuse Swing components? I don't necessarily think it should. Existing swing components wont have the CSS styling and would look out of place surrounded by a Rich UI. I feel JavaFX should be looking forward, as opposed to adding backward compatibility for various Swing libraries. When/If JavaFX is supported on multiple OS's like iOS, Metro, Android, would users want to see a Swing component, or would they like to see a JavaFX component that looks exactly like it should? Though there are swing component libraries that have the functionality that is needed in JavaFX, like as you mentioned JFreeCharts, but surely thats for a oracle/community to adopt and take forward. To see that the community needs and look to address that with a new feature of JavaFX, or a new JavaFX library. Swing libraries grew over time and started tackling the functionality that was missing in swing, like a property Chart AP, TreeTableView, etc, but we need groups like the JFXtras team to take up the baton. That being said, I hope the next release of functionally for the JavaFX charts is somewhat comparable to the functionality offered in projects like JFreeCharts - *Release the source.* It's a royal pain to have to download the source through mercurial rather than simply read it as you do with the Swing code or download it as you do with any Maven package. There's also some work that needs to be done to make it easier for people to participate. I have 3 accounts at the moment: one for this mailing list, one for the forums, and one for JIRA. Can we just boil that down to one, and let me login with Facebook or Google credentials? Cheers, Mark On Tue, Oct 9, 2012 at 11:14 AM, Filipe Portes wrote: > well, > > what I really will like to see, more than JavaFx running over mobile > plataforms, Is java embedded and JavaFX becoming themselves a pure Java > mobile plataform. > > On Tue, Oct 9, 2012 at 2:53 PM, wrote: > > > Thanks for stepping in Richard. > > > > Jiri > > > > ------------ P?vodn? zpr?va ------------ > > Od: Werner Lehmann > > P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? > > Datum: 09.10.2012 19:36:15 > > ------------------------------**---------- > > > > FWIW, the community support on this mailing list is outstanding in my > > opinion. Usually it does not take more than a day to even get replies > > directly from Oracle staff. And suggestions are discussed with an open > > mind. Compare that to the cost and response time of a support contract. > > > > Rgds > > Werner > > > > On 09.10.2012 19:20, Richard Bair wrote: > > > >> In the Java group, we are very concerned about community involvement. > >> > > > > > > > > > -- > Filipe Portes - @filipeportes > Java Architect - Senior Java EE/Web > JUGLeader Gojava - @gojava > -- John From swpalmer at gmail.com Tue Oct 9 14:39:42 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 9 Oct 2012 17:39:42 -0400 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: On Tue, Oct 9, 2012 at 5:20 PM, John McDonnell wrote: > Commented in line. > > On 9 October 2012 20:04, Mark Fortner wrote: > > > - *Support for Swing components within JavaFX. * If the goal is to > > replace Swing, then this is one of those essential capabilities that > > needs > > to be in place. The current examples only demonstrate how to put > JavaFX > > components within Swing applications. Unfortunately, if you want to > > reuse > > any existing components (like JFreeCharts for example) within your > > project, > > you're SOL at the moment. > > > > Should JavaFX be able to reuse Swing components? I don't necessarily think > it should. > > Existing swing components wont have the CSS styling and would look out of > place surrounded by a Rich UI. I feel JavaFX should be looking forward, as > opposed to adding backward compatibility for various Swing libraries. > When/If JavaFX is supported on multiple OS's like iOS, Metro, Android, > would users want to see a Swing component, or would they like to see a > JavaFX component that looks exactly like it should? > > Though there are swing component libraries that have the functionality that > is needed in JavaFX, like as you mentioned JFreeCharts, but surely thats > for a oracle/community to adopt and take forward. To see that the > community needs and look to address that with a new feature of JavaFX, or a > new JavaFX library. Swing libraries grew over time and started tackling > the functionality that was missing in swing, like a property Chart AP, > TreeTableView, etc, but we need groups like the JFXtras team to take up the > baton. That being said, I hope the next release of functionally for the > JavaFX charts is somewhat comparable to the functionality offered in > projects like JFreeCharts > > I agree that If you want Swing, use a JFXPanel in your Swing app until you are ready to go 100% JavaFX. But of course that means JFXPanel needs to work smoothly. It had some rough edges in the beginning. Long term nobody wants two event threads and all the ugly synchronization issues that come up. Deprecate Swing around Java 9 and push forward. Scott From zonski at gmail.com Tue Oct 9 14:43:52 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 10 Oct 2012 08:43:52 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: Richard and crew, is Oracle using JavaFX in commercial situations? If so are you able to tell us how/where (ie what space) and to what extent? Maybe knowing this will help us understand the reasons behind all this and the direction Oracle sees this all going (and allow us to decide if we want to help row that boat or jump out now). Just as (possibility more) disappointing as the mobile stuff is this vibe that Oracle does not see JFX having much of a role in the 'web' space. It looks like a straight bow-out to HTML5. I highly doubt any of this stuff is your, or your team's preference and sentiment, but as great as that is, it doesn't help us. Oracle holds the purse strings and that's what will control, and direct the platform. Serious, non-rhetorical question: if you were a front-line developer right now what sort of job would you say to your customer "the best platform your needs here is JavaFX"? The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. Secondly, where's the incentive for the community to do this? Why not invest our time in making something with a more complete base better instead of plugging gaping holes in a niche, orphaned technology that "has interesting potential". There's no critical mass to the community yet, and another year or two of not being relevant in the major spaces of web and mobile will only see this worsen. I've had to go to HTML5 over the last few months because JFX just isn't ready. Another couple of months and I'll be so heavily invested in HTML5 based solutions that I won't be able to justify coming back. Finally, if we didn't need a large corporation backing/financing the main components of this thing then JFX would have been built by the community years ago. If Oracle is only looking at this platform as some sort of glorified 3D charting gimmick, then the community won't get the under-swell of momentum it needs to get past the tipping point where it just grows by itself. The attitude needs to be "if you build it, they will come". Currently it looks like "when they come they can then build it". Can anyone actually see that working? Without web and/or mobile you're fishing for a community without having any bait. No community means no one to build the tools needed to then grow it, no one pushing IDEs to support it, no one making frameworks others can leverage. Which of course is a cyclic spiral into obscurity. As I said I dont doubt your commitment to this platform but I do now doubt Oracle's. I want to be wrong - tell us how and when JavaFX is going to be relevant to any significant space or sector. On 10/10/2012, at 6:04 AM, Mark Fortner wrote: > My preference would be to get the following tasks taken care of before > Oracle starts throwing resources at supporting tablets, mobile and JavaFX > 3D: > > - *Deployment using Maven.* Although you can build with Maven, there > are a lot of hoops that you still have to jump through, and we still don't > have the artifacts in an accessible repo. I think Zonski, and others have > blogged about this, and kvetched on mailing lists so I won't repeat their > comments here. > - *Webstart deployment *- this is still problematic. Currently when you > push new artifacts to your web server, it's not replacing the existing JARs > in the user's cache -- despite what the documentation says. The "special" > javafx tags aren't documented well enough and presume that you're using the > Ant tools to generate the JNLP. And getting shaded jars is next to > impossible. > - *Charts* - support for zooming and panning within the charts. Support > for drawing on top of charts. > - *Support for Swing components within JavaFX. * If the goal is to > replace Swing, then this is one of those essential capabilities that needs > to be in place. The current examples only demonstrate how to put JavaFX > components within Swing applications. Unfortunately, if you want to reuse > any existing components (like JFreeCharts for example) within your project, > you're SOL at the moment. > - *Support for an EventBus.* Currently, there's a lot of point2point > event code that you have to write to fire and listen to events. It would > make for a much more useable codebase if you could simply publish and > subscribe to events at the application level. > - *Release the source.* It's a royal pain to have to download the > source through mercurial rather than simply read it as you do with the > Swing code or download it as you do with any Maven package. > > There's also some work that needs to be done to make it easier for people > to participate. I have 3 accounts at the moment: one for this mailing > list, one for the forums, and one for JIRA. Can we just boil that down to > one, and let me login with Facebook or Google credentials? > > Cheers, > > Mark > > > > > On Tue, Oct 9, 2012 at 11:14 AM, Filipe Portes wrote: > >> well, >> >> what I really will like to see, more than JavaFx running over mobile >> plataforms, Is java embedded and JavaFX becoming themselves a pure Java >> mobile plataform. >> >> On Tue, Oct 9, 2012 at 2:53 PM, wrote: >> >>> Thanks for stepping in Richard. >>> >>> Jiri >>> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Werner Lehmann >>> P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? >>> Datum: 09.10.2012 19:36:15 >>> ------------------------------**---------- >>> >>> FWIW, the community support on this mailing list is outstanding in my >>> opinion. Usually it does not take more than a day to even get replies >>> directly from Oracle staff. And suggestions are discussed with an open >>> mind. Compare that to the cost and response time of a support contract. >>> >>> Rgds >>> Werner >>> >>> On 09.10.2012 19:20, Richard Bair wrote: >>> >>>> In the Java group, we are very concerned about community involvement. >>>> >>> >>> >>> >> >> >> -- >> Filipe Portes - @filipeportes >> Java Architect - Senior Java EE/Web >> JUGLeader Gojava - @gojava >> From phidias51 at gmail.com Tue Oct 9 14:47:07 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 9 Oct 2012 14:47:07 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: John, The problem is we're not yet at a point where JavaFX components that can fully replace their Swing equivalents. And we may never get there if vendors believe that there's no market for it (kind of a chicken and egg problem). > Should JavaFX be able to reuse Swing components? I don't necessarily > think it should. > > Existing swing components wont have the CSS styling and would look out of > place surrounded by a Rich UI. I feel JavaFX should be looking forward, as > opposed to adding backward compatibility for various Swing libraries. > When/If JavaFX is supported on multiple OS's like iOS, Metro, Android, > would users want to see a Swing component, or would they like to see a > JavaFX component that looks exactly like it should? > > I was speaking about desktop development/applet development primarily where all of the current Swing development occurs. The lack of CSS styling for Swing components doesn't bother me that much and would be tolerable as an interim solution until the JavaFX components are mature enough to be used as replacements. > Though there are swing component libraries that have the functionality > that is needed in JavaFX, like as you mentioned JFreeCharts, but surely > thats for a oracle/community to adopt and take forward. To see that the > community needs and look to address that with a new feature of JavaFX, or a > new JavaFX library. Swing libraries grew over time and started tackling > the functionality that was missing in swing, like a property Chart AP, > TreeTableView, etc, but we need groups like the JFXtras team to take up the > baton. That being said, I hope the next release of functionally for the > JavaFX charts is somewhat comparable to the functionality offered in > projects like JFreeCharts > > Most of the JavaFX libraries I've seen so far provide toy widgets, but not something that would necessarily be useful for corporate app development. Speedometer type dials, and battery gauges aren't really useful when trying to display financial or scientific data. Mark From pedro.duquevieira at gmail.com Tue Oct 9 15:12:39 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Oct 2012 23:12:39 +0100 Subject: No JavaFX for iOS, Android or WP - why not? Message-ID: > > Richard and crew, is Oracle using JavaFX in commercial situations? If so > are you able to tell us how/where (ie what space) and to what extent? Maybe > knowing this will help us understand the reasons behind all this and the > direction Oracle sees this all going (and allow us to decide if we want to > help row that boat or jump out now). > Just as (possibility more) disappointing as the mobile stuff is this vibe > that Oracle does not see JFX having much of a role in the 'web' space. It > looks like a straight bow-out to HTML5. > I highly doubt any of this stuff is your, or your team's preference and > sentiment, but as great as that is, it doesn't help us. Oracle holds the > purse strings and that's what will control, and direct the platform. > Serious, non-rhetorical question: if you were a front-line developer right > now what sort of job would you say to your customer "the best platform your > needs here is JavaFX"? > The notion that once its all open source the community can do all the > extra work to bridge the short commings is a bit of a fantasy. > Firstly, it's going to take way too long to get there, established > platforms are snowballing ahead as JavaFX struggles to catch up. We'll have > HTML6 by the time JFX gets open sourced AND then the community gets round > to adding features that needed to be in there 6 months ago to be > competitive. > Secondly, where's the incentive for the community to do this? Why not > invest our time in making something with a more complete base better > instead of plugging gaping holes in a niche, orphaned technology that "has > interesting potential". There's no critical mass to the community yet, and > another year or two of not being relevant in the major spaces of web and > mobile will only see this worsen. I've had to go to HTML5 over the last few > months because JFX just isn't ready. Another couple of months and I'll be > so heavily invested in HTML5 based solutions that I won't be able to > justify coming back. > Finally, if we didn't need a large corporation backing/financing the main > components of this thing then JFX would have been built by the community > years ago. If Oracle is only looking at this platform as some sort of > glorified 3D charting gimmick, then the community won't get the under-swell > of momentum it needs to get past the tipping point where it just grows by > itself. > The attitude needs to be "if you build it, they will come". Currently it > looks like "when they come they can then build it". Can anyone actually see > that working? > Without web and/or mobile you're fishing for a community without having > any bait. No community means no one to build the tools needed to then grow > it, no one pushing IDEs to support it, no one making frameworks others can > leverage. Which of course is a cyclic spiral into obscurity. > As I said I dont doubt your commitment to this platform but I do now doubt > Oracle's. I want to be wrong - tell us how and when JavaFX is going to be > relevant to any significant space or sector. +100 on Daniel Zwolenski comments. I wish JavaFX to be the platform of choice for RIA but right now with the current state of affairs I don't see that coming. -- Pedro Duque Vieira From freddy at spinningnoodle.com Tue Oct 9 18:33:08 2012 From: freddy at spinningnoodle.com (Freddy Guime) Date: Tue, 9 Oct 2012 20:33:08 -0500 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: Message-ID: <006901cda687$3546ca80$9fd45f80$@com> Interesting observations, in this sense I can relate. I am a Swing developer for an Options Trading Platform here in Chicago, and coming from JavaOne one of my goals was to evaluate the appropriateness of JavaFX to replace our front-end Swing App. For the lack of CSS I agree with Mark. In the realm of Desktop application, while it is definitively a 'nice' feature is not that we 'tinker' with a Swing App skin all day long, and while sometimes painful (Nimbus, I'm looking at you :P) it is probably where we spend the least time in Swing Development. In terms of components, (and I love the components done by Gerrit, and appreciate the work done by Jonathan Giles), I think we are still 'in development'. What I am realizing is that probably, the basics are there, and there seems to be enough 'hooks' and extensibility to fill-in the gaps. We are trying, under-the-covers do a pilot and see how a particular (but yet very important) section of our system behaves under JavaFX. Questions on performance (Options Exchanges sends a lot of Market Data, which required us to tweak JTables immensely, so I'm expected that will happen in FX) and adequacy for our 'financial' app will be answered then. In that sense, it does feel that for us, the Desktop guys (probably a minority nowadays) would have to eventually move away from Swing, as it is going to become 'stale' (Evidenced by not having a single session on Swing at this JavaOne, nor a lot of Swing bugs being closed, kinda expected, but still). One risk that I do see is that because Swing developers will have to move/migrate to another technology, a question of alternative technologies is brought up (even for us, sadly looking at WPF + C# as well) Just adding my 2c as a rogue Desktop Developer :) Freddy Guime ---- Date: Tue, 9 Oct 2012 14:47:07 -0700 From: Mark Fortner Subject: Re: Re: No JavaFX for iOS, Android or WP - why not? To: openjfx-dev at openjdk.java.net Message-ID: Content-Type: text/plain; charset=ISO-8859-1 John, The problem is we're not yet at a point where JavaFX components that can fully replace their Swing equivalents. And we may never get there if vendors believe that there's no market for it (kind of a chicken and egg problem). > Should JavaFX be able to reuse Swing components? I don't necessarily > think it should. > > Existing swing components wont have the CSS styling and would look out of > place surrounded by a Rich UI. I feel JavaFX should be looking forward, as > opposed to adding backward compatibility for various Swing libraries. > When/If JavaFX is supported on multiple OS's like iOS, Metro, Android, > would users want to see a Swing component, or would they like to see a > JavaFX component that looks exactly like it should? > > I was speaking about desktop development/applet development primarily where all of the current Swing development occurs. The lack of CSS styling for Swing components doesn't bother me that much and would be tolerable as an interim solution until the JavaFX components are mature enough to be used as replacements. > Though there are swing component libraries that have the functionality > that is needed in JavaFX, like as you mentioned JFreeCharts, but surely > thats for a oracle/community to adopt and take forward. To see that the > community needs and look to address that with a new feature of JavaFX, or a > new JavaFX library. Swing libraries grew over time and started tackling > the functionality that was missing in swing, like a property Chart AP, > TreeTableView, etc, but we need groups like the JFXtras team to take up the > baton. That being said, I hope the next release of functionally for the > JavaFX charts is somewhat comparable to the functionality offered in > projects like JFreeCharts > > Most of the JavaFX libraries I've seen so far provide toy widgets, but not something that would necessarily be useful for corporate app development. Speedometer type dials, and battery gauges aren't really useful when trying to display financial or scientific data. Mark End of openjfx-dev Digest, Vol 11, Issue 20 ******************************************* From richard.bair at oracle.com Tue Oct 9 19:22:42 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 9 Oct 2012 19:22:42 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: > Serious, non-rhetorical question: if you were a front-line developer right now what sort of job would you say to your customer "the best platform your needs here is JavaFX"? Any serious application. I'm not talking about some web property like nike.com, but rather, all of the sales software or distribution software or whatever is running Nike corporation. With co-bundling and auto-update, you really don't need to build web apps for that kind of stuff. That's what I would be aiming for. > The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. I should hope not. I know many developers (some of whom have already spoken up on this thread) happy to do a port. Android hasn't had any trouble getting 3rd parties to port Android to anything and everything. A new port of JavaFX is not a major undertaking, almost the entire platform just works. > Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. That's just being silly. HTML 5 isn't even going to be here for a few more years, let alone 6. > Secondly, where's the incentive for the community to do this? If there is no incentive, then I guess you've proved the point, no? I should hope there is a large amount of incentive, as others on this thread (and many more privately) have verified. You act as though nobody has adopted JavaFX, but we're seeing a broad swell of adoption, especially among existing Swing developers. There are a lot of people who are developing for JavaFX commercially, and most of those people are not talking about it openly. Some very big customers in the lot. They love FX and are also committed to it. Oracle funds hundreds of salaries based on JavaFX & Java client. There is a huge, heavy investment from Oracle. JavaFX is here for a long time -- we've got paying customers and we've got support contracts. Look, we got beat up real bad for not having Mac and Linux support at 1.0, people questioned publicly whether we'd ever do it. Richard From ozemale at ozemail.com.au Wed Oct 10 01:14:13 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Wed, 10 Oct 2012 19:14:13 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: <00ef01cda6bf$3be3c680$b3ab5380$@com.au> Richard has stated that porting JavaFX to iOS or Android is not currently on the roadmap. So think what that means. The current roadmap extends out to 2015/16 or so with the release of JavaFX 8 & 9 so we are talking about some time after that. Realistically, if JavaFX ever actually does run on iOS or Android then it's going to be 2016/7 at the earliest. That's another 4 or 5 years from now and surely by then JavaFX will be so far behind other mobile platforms that it really will have missed the boat. As much as I hate to say it, by then I could have gained expert skills in Objective C and have released any number of iOS apps. I was pinning my hopes on an official announcement from Oracle at this year's JavaOne that a Beta release of the iOS JavaFX deployment pack was imminent especially after teasing us for so long with demos. I am sure I am not the only one who is bitterly disappointed to learn that such technology is not even on the roadmap. In 4-5 years JavaFX will be completely irrelevant if it only runs on what many are already calling "legacy" desktops. -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Wednesday, 10 October 2012 08:44 To: Mark Fortner Cc: openjfx-dev at openjdk.java.net Subject: Re: No JavaFX for iOS, Android or WP - why not? Richard and crew, is Oracle using JavaFX in commercial situations? If so are you able to tell us how/where (ie what space) and to what extent? Maybe knowing this will help us understand the reasons behind all this and the direction Oracle sees this all going (and allow us to decide if we want to help row that boat or jump out now). Just as (possibility more) disappointing as the mobile stuff is this vibe that Oracle does not see JFX having much of a role in the 'web' space. It looks like a straight bow-out to HTML5. I highly doubt any of this stuff is your, or your team's preference and sentiment, but as great as that is, it doesn't help us. Oracle holds the purse strings and that's what will control, and direct the platform. Serious, non-rhetorical question: if you were a front-line developer right now what sort of job would you say to your customer "the best platform your needs here is JavaFX"? The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. Secondly, where's the incentive for the community to do this? Why not invest our time in making something with a more complete base better instead of plugging gaping holes in a niche, orphaned technology that "has interesting potential". There's no critical mass to the community yet, and another year or two of not being relevant in the major spaces of web and mobile will only see this worsen. I've had to go to HTML5 over the last few months because JFX just isn't ready. Another couple of months and I'll be so heavily invested in HTML5 based solutions that I won't be able to justify coming back. Finally, if we didn't need a large corporation backing/financing the main components of this thing then JFX would have been built by the community years ago. If Oracle is only looking at this platform as some sort of glorified 3D charting gimmick, then the community won't get the under-swell of momentum it needs to get past the tipping point where it just grows by itself. The attitude needs to be "if you build it, they will come". Currently it looks like "when they come they can then build it". Can anyone actually see that working? Without web and/or mobile you're fishing for a community without having any bait. No community means no one to build the tools needed to then grow it, no one pushing IDEs to support it, no one making frameworks others can leverage. Which of course is a cyclic spiral into obscurity. As I said I dont doubt your commitment to this platform but I do now doubt Oracle's. I want to be wrong - tell us how and when JavaFX is going to be relevant to any significant space or sector. On 10/10/2012, at 6:04 AM, Mark Fortner wrote: > My preference would be to get the following tasks taken care of before > Oracle starts throwing resources at supporting tablets, mobile and > JavaFX > 3D: > > - *Deployment using Maven.* Although you can build with Maven, there > are a lot of hoops that you still have to jump through, and we still don't > have the artifacts in an accessible repo. I think Zonski, and others have > blogged about this, and kvetched on mailing lists so I won't repeat their > comments here. > - *Webstart deployment *- this is still problematic. Currently when you > push new artifacts to your web server, it's not replacing the existing JARs > in the user's cache -- despite what the documentation says. The "special" > javafx tags aren't documented well enough and presume that you're using the > Ant tools to generate the JNLP. And getting shaded jars is next to > impossible. > - *Charts* - support for zooming and panning within the charts. Support > for drawing on top of charts. > - *Support for Swing components within JavaFX. * If the goal is to > replace Swing, then this is one of those essential capabilities that needs > to be in place. The current examples only demonstrate how to put JavaFX > components within Swing applications. Unfortunately, if you want to reuse > any existing components (like JFreeCharts for example) within your project, > you're SOL at the moment. > - *Support for an EventBus.* Currently, there's a lot of point2point > event code that you have to write to fire and listen to events. It would > make for a much more useable codebase if you could simply publish and > subscribe to events at the application level. > - *Release the source.* It's a royal pain to have to download the > source through mercurial rather than simply read it as you do with the > Swing code or download it as you do with any Maven package. > > There's also some work that needs to be done to make it easier for > people to participate. I have 3 accounts at the moment: one for this > mailing list, one for the forums, and one for JIRA. Can we just boil > that down to one, and let me login with Facebook or Google credentials? > > Cheers, > > Mark > > > > > On Tue, Oct 9, 2012 at 11:14 AM, Filipe Portes wrote: > >> well, >> >> what I really will like to see, more than JavaFx running over mobile >> plataforms, Is java embedded and JavaFX becoming themselves a pure >> Java mobile plataform. >> >> On Tue, Oct 9, 2012 at 2:53 PM, wrote: >> >>> Thanks for stepping in Richard. >>> >>> Jiri >>> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Werner Lehmann >>> P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? >>> Datum: 09.10.2012 19:36:15 >>> ------------------------------**---------- >>> >>> FWIW, the community support on this mailing list is outstanding in >>> my opinion. Usually it does not take more than a day to even get >>> replies directly from Oracle staff. And suggestions are discussed >>> with an open mind. Compare that to the cost and response time of a support contract. >>> >>> Rgds >>> Werner >>> >>> On 09.10.2012 19:20, Richard Bair wrote: >>> >>>> In the Java group, we are very concerned about community involvement. >>>> >>> >>> >>> >> >> >> -- >> Filipe Portes - @filipeportes >> Java Architect - Senior Java EE/Web >> JUGLeader Gojava - @gojava >> From goddard at seznam.cz Wed Oct 10 04:02:12 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Wed, 10 Oct 2012 13:02:12 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20RE=3A=20No=20JavaFX=20for=20iOS=2C=20Android=20or=20WP=20=2D=20why=20not=3F?= In-Reply-To: <00ef01cda6bf$3be3c680$b3ab5380$@com.au> Message-ID: <136002.15558.48972-30826-1180666988-1349866932@seznam.cz> I still don't understand all the skepticism here. - Swing will be replaced (not physically, but on the market) by JavaFX with some backwards compatibility. JavaFX has employs different programming model (scenegraph) from Swing. Get over it. - Mobile platforms should not be a big problem once JavaFX is opensourced thanks to increasing power of mobile devices that are close to what PC was at early 2000. - Embedded is the new mobile. - One should be able to run JFX embedded on embd. device or mobile device. - The fact that PC market is shrinking doesn't mean there's less money in it for desktop developers. PC will be used by professionals. - If one wants to develop in JFX for tablets there's a WeTab, for other vendors it's just matter of packaging the right JRE & JFX, I believe. Finally, no one really holds anyone back in some community effort. The community is there hack on whatever oracle provides in current version of JFX. The community has always been about putting extra hours into your hobby. The community has been always about sharing stuff. Now, how grateful is this community? - People complained that it's not Java 3-4 years ago. - People complained it's different runtime. - People complained about this and that. - Sun / Oracle opensourced JFX script. No one from the "community" did a shit about those "painpoints". Stop whining. If someone feels like that is not enough, go to Oracle and show your demo. This shit works the best every time. Get a contract, become a partner, push things forward. As a "lone wolf", start to develop components like those in JFXtras, get a job as JFX developer. So far, it's been what ifs, mights and could have beens. Jiri ------------ P?vodn? zpr?va ------------ Od: John C. Turnbull P?edm?t: RE: No JavaFX for iOS, Android or WP - why not? Datum: 10.10.2012 10:30:48 ---------------------------------------- Richard has stated that porting JavaFX to iOS or Android is not currently on the roadmap. So think what that means. The current roadmap extends out to 2015/16 or so with the release of JavaFX 8 & 9 so we are talking about some time after that. Realistically, if JavaFX ever actually does run on iOS or Android then it's going to be 2016/7 at the earliest. That's another 4 or 5 years from now and surely by then JavaFX will be so far behind other mobile platforms that it really will have missed the boat. As much as I hate to say it, by then I could have gained expert skills in Objective C and have released any number of iOS apps. I was pinning my hopes on an official announcement from Oracle at this year's JavaOne that a Beta release of the iOS JavaFX deployment pack was imminent especially after teasing us for so long with demos. I am sure I am not the only one who is bitterly disappointed to learn that such technology is not even on the roadmap. In 4-5 years JavaFX will be completely irrelevant if it only runs on what many are already calling "legacy" desktops. -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Wednesday, 10 October 2012 08:44 To: Mark Fortner Cc: openjfx-dev at openjdk.java.net Subject: Re: No JavaFX for iOS, Android or WP - why not? Richard and crew, is Oracle using JavaFX in commercial situations? If so are you able to tell us how/where (ie what space) and to what extent? Maybe knowing this will help us understand the reasons behind all this and the direction Oracle sees this all going (and allow us to decide if we want to help row that boat or jump out now). Just as (possibility more) disappointing as the mobile stuff is this vibe that Oracle does not see JFX having much of a role in the 'web' space. It looks like a straight bow-out to HTML5. I highly doubt any of this stuff is your, or your team's preference and sentiment, but as great as that is, it doesn't help us. Oracle holds the purse strings and that's what will control, and direct the platform. Serious, non-rhetorical question: if you were a front-line developer right now what sort of job would you say to your customer "the best platform your needs here is JavaFX"? The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. Secondly, where's the incentive for the community to do this? Why not invest our time in making something with a more complete base better instead of plugging gaping holes in a niche, orphaned technology that "has interesting potential". There's no critical mass to the community yet, and another year or two of not being relevant in the major spaces of web and mobile will only see this worsen. I've had to go to HTML5 over the last few months because JFX just isn't ready. Another couple of months and I'll be so heavily invested in HTML5 based solutions that I won't be able to justify coming back. Finally, if we didn't need a large corporation backing/financing the main components of this thing then JFX would have been built by the community years ago. If Oracle is only looking at this platform as some sort of glorified 3D charting gimmick, then the community won't get the under-swell of momentum it needs to get past the tipping point where it just grows by itself. The attitude needs to be "if you build it, they will come". Currently it looks like "when they come they can then build it". Can anyone actually see that working? Without web and/or mobile you're fishing for a community without having any bait. No community means no one to build the tools needed to then grow it, no one pushing IDEs to support it, no one making frameworks others can leverage. Which of course is a cyclic spiral into obscurity. As I said I dont doubt your commitment to this platform but I do now doubt Oracle's. I want to be wrong - tell us how and when JavaFX is going to be relevant to any significant space or sector. On 10/10/2012, at 6:04 AM, Mark Fortner wrote: > My preference would be to get the following tasks taken care of before > Oracle starts throwing resources at supporting tablets, mobile and > JavaFX > 3D: > > - *Deployment using Maven.* Although you can build with Maven, there > are a lot of hoops that you still have to jump through, and we still don't > have the artifacts in an accessible repo. I think Zonski, and others have > blogged about this, and kvetched on mailing lists so I won't repeat their > comments here. > - *Webstart deployment *- this is still problematic. Currently when you > push new artifacts to your web server, it's not replacing the existing JARs > in the user's cache -- despite what the documentation says. The "special" > javafx tags aren't documented well enough and presume that you're using the > Ant tools to generate the JNLP. And getting shaded jars is next to > impossible. > - *Charts* - support for zooming and panning within the charts. Support > for drawing on top of charts. > - *Support for Swing components within JavaFX. * If the goal is to > replace Swing, then this is one of those essential capabilities that needs > to be in place. The current examples only demonstrate how to put JavaFX > components within Swing applications. Unfortunately, if you want to reuse > any existing components (like JFreeCharts for example) within your project, > you're SOL at the moment. > - *Support for an EventBus.* Currently, there's a lot of point2point > event code that you have to write to fire and listen to events. It would > make for a much more useable codebase if you could simply publish and > subscribe to events at the application level. > - *Release the source.* It's a royal pain to have to download the > source through mercurial rather than simply read it as you do with the > Swing code or download it as you do with any Maven package. > > There's also some work that needs to be done to make it easier for > people to participate. I have 3 accounts at the moment: one for this > mailing list, one for the forums, and one for JIRA. Can we just boil > that down to one, and let me login with Facebook or Google credentials? > > Cheers, > > Mark > > > > > On Tue, Oct 9, 2012 at 11:14 AM, Filipe Portes wrote: > >> well, >> >> what I really will like to see, more than JavaFx running over mobile >> plataforms, Is java embedded and JavaFX becoming themselves a pure >> Java mobile plataform. >> >> On Tue, Oct 9, 2012 at 2:53 PM, wrote: >> >>> Thanks for stepping in Richard. >>> >>> Jiri >>> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Werner Lehmann >>> P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? >>> Datum: 09.10.2012 19:36:15 >>> ------------------------------**---------- >>> >>> FWIW, the community support on this mailing list is outstanding in >>> my opinion. Usually it does not take more than a day to even get >>> replies directly from Oracle staff. And suggestions are discussed >>> with an open mind. Compare that to the cost and response time of a support contract. >>> >>> Rgds >>> Werner >>> >>> On 09.10.2012 19:20, Richard Bair wrote: >>> >>>> In the Java group, we are very concerned about community involvement. >>>> >>> >>> >>> >> >> >> -- >> Filipe Portes - @filipeportes >> Java Architect - Senior Java EE/Web >> JUGLeader Gojava - @gojava >> From hang.vo at oracle.com Wed Oct 10 05:33:38 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 10 Oct 2012 12:33:38 +0000 Subject: hg: openjfx/8/graphics/rt: 6 new changesets Message-ID: <20121010123346.148AB4727B@hg.openjdk.java.net> Changeset: c15a91781139 Author: David Grieve Date: 2012-10-04 17:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c15a91781139 RT-25118: replace code removed by bad merge, and other optimizations ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Match.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: bedd78e543a0 Author: David Grieve Date: 2012-10-04 17:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bedd78e543a0 RT-25133: strip off package when comparing class name in css selector ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-controls/test/javafx/scene/control/PopupControlTest.java Changeset: 80b5d7e96fdb Author: David Grieve Date: 2012-10-05 14:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/80b5d7e96fdb RT-25370: upper four bits represent an index. When getting the index value, need to shift unsigned ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java Changeset: fe99329cd02e Author: rbair Date: 2012-10-08 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe99329cd02e Removed tests that are not doing anything. - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlicesTest.java - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlices_builder_Test.java Changeset: c0aff81b30ad Author: leifs Date: 2012-10-09 10:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c0aff81b30ad Fixed RT-25479: [TextField] Text input starts from wrong position. Disable caret bias handling util it can be fully supported. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: ea00b638cdd6 Author: leifs Date: 2012-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ea00b638cdd6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlicesTest.java - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlices_builder_Test.java From thoughtslinger at gmail.com Wed Oct 10 05:53:28 2012 From: thoughtslinger at gmail.com (Rick Walker) Date: Wed, 10 Oct 2012 08:53:28 -0400 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <136002.15558.48972-30826-1180666988-1349866932@seznam.cz> References: <00ef01cda6bf$3be3c680$b3ab5380$@com.au> <136002.15558.48972-30826-1180666988-1349866932@seznam.cz> Message-ID: Richard - I greatly appreciate the clarification. You have soothed some jitters. Oracle has every right to allocate its resources as it sees fit. Real-world demand from developers of commercial FX apps will hopefully tip the scales in favor of an Oracle-delivered iOS/Android stack. As a practical matter, it seems to me that tablet and smartphone co-bundled auto-updating apps may be more likely to be accepted by Apple/Google/Amazon app stores if bundled and packaged with tooling (read javafxpackager) provided by Oracle. Rick From swpalmer at gmail.com Wed Oct 10 06:42:30 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 10 Oct 2012 09:42:30 -0400 Subject: Layout issues Message-ID: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> Hi, I have a custom container extending Pane that implements layoutChildren. I've noticed that this method is called continuously even though my scene is static. It's like something is always in the list of "dirty" nodes and is forcing a re-layout. I don't understand this. I've googled but I can't find a decent tutorial for implementing custom containers or custom layouts. Part of the problem with my application is that nodes are not properly shrining when I remove content from within them, they shrink a little, but not as much as they should. I'm still debugging, but wonder if there is any insight into how the layout system works that I've missed somewhere? Thanks, Scott From randahl at rockit.dk Wed Oct 10 06:56:45 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 10 Oct 2012 15:56:45 +0200 Subject: Layout issues In-Reply-To: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> References: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> Message-ID: Scott, in my experience this is not how JavaFX works in general. All my layoutChildren methods are only called when I change a property that directly or indirectly affects the layout, such as changing the text of a label or invoking requestLayout(). Your application must be doing something actively for this to happen, I believe. Perhaps you could remove parts of your UI until you isolate the component causing the problem. Randahl On Oct 10, 2012, at 15:42 , Scott Palmer wrote: > Hi, > > I have a custom container extending Pane that implements layoutChildren. I've noticed that this method is called continuously even though my scene is static. It's like something is always in the list of "dirty" nodes and is forcing a re-layout. I don't understand this. I've googled but I can't find a decent tutorial for implementing custom containers or custom layouts. > > Part of the problem with my application is that nodes are not properly shrining when I remove content from within them, they shrink a little, but not as much as they should. I'm still debugging, but wonder if there is any insight into how the layout system works that I've missed somewhere? > > Thanks, > > Scott From pedro.duquevieira at gmail.com Wed Oct 10 07:02:47 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 10 Oct 2012 15:02:47 +0100 Subject: No JavaFX for iOS, Android or WP - why not? Message-ID: Hi Richard, What about the problem with applet deployment or webstart. This problem has been around since the beginning and there is no official statements/roadmaps on when is it going to be solved. Just some general pointers but nothing concrete. I think it would be important to get some official statement on this, preferably with deliverable dates. Thanks, best regards, > > Serious, non-rhetorical question: if you were a front-line developer > right now what sort of job would you say to your customer "the best > platform your needs here is JavaFX"? > Any serious application. I'm not talking about some web property like > nike.com, but rather, all of the sales software or distribution software > or whatever is running Nike corporation. With co-bundling and auto-update, > you really don't need to build web apps for that kind of stuff. That's what > I would be aiming for. > > The notion that once its all open source the community can do all the > extra work to bridge the short commings is a bit of a fantasy. > I should hope not. I know many developers (some of whom have already > spoken up on this thread) happy to do a port. Android hasn't had any > trouble getting 3rd parties to port Android to anything and everything. A > new port of JavaFX is not a major undertaking, almost the entire platform > just works. > > Firstly, it's going to take way too long to get there, established > platforms are snowballing ahead as JavaFX struggles to catch up. We'll have > HTML6 by the time JFX gets open sourced AND then the community gets round > to adding features that needed to be in there 6 months ago to be > competitive. > That's just being silly. HTML 5 isn't even going to be here for a few more > years, let alone 6. > > Secondly, where's the incentive for the community to do this? > If there is no incentive, then I guess you've proved the point, no? I > should hope there is a large amount of incentive, as others on this thread > (and many more privately) have verified. You act as though nobody has > adopted JavaFX, but we're seeing a broad swell of adoption, especially > among existing Swing developers. There are a lot of people who are > developing for JavaFX commercially, and most of those people are not > talking about it openly. Some very big customers in the lot. They love FX > and are also committed to it. > Oracle funds hundreds of salaries based on JavaFX & Java client. There is > a huge, heavy investment from Oracle. JavaFX is here for a long time -- > we've got paying customers and we've got support contracts. Look, we got > beat up real bad for not having Mac and Linux support at 1.0, people > questioned publicly whether we'd ever do it. > Richard -- Pedro Duque Vieira From sebastian.rheinnecker at yworks.com Wed Oct 10 08:15:43 2012 From: sebastian.rheinnecker at yworks.com (Sebastian Rheinnecker) Date: Wed, 10 Oct 2012 17:15:43 +0200 Subject: Layout issues In-Reply-To: References: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> Message-ID: <5075911F.50800@yworks.com> Hi Scott, I experienced quite a similar issue a while ago where a custom control of mine got resized over and over again although no changes to the width or height where applied. I overrode and made sure that if the values didn't change it all the method in the super class aren't called. That solved the issue for me. Kind regards, Sebastian On 10.10.2012 15:56, Randahl Fink Isaksen wrote: > Scott, in my experience this is not how JavaFX works in general. All my layoutChildren methods are only called when I change a property that directly or indirectly affects the layout, such as changing the text of a label or invoking requestLayout(). > > Your application must be doing something actively for this to happen, I believe. > > Perhaps you could remove parts of your UI until you isolate the component causing the problem. > > Randahl > > > > On Oct 10, 2012, at 15:42 , Scott Palmer wrote: > >> Hi, >> >> I have a custom container extending Pane that implements layoutChildren. I've noticed that this method is called continuously even though my scene is static. It's like something is always in the list of "dirty" nodes and is forcing a re-layout. I don't understand this. I've googled but I can't find a decent tutorial for implementing custom containers or custom layouts. >> >> Part of the problem with my application is that nodes are not properly shrining when I remove content from within them, they shrink a little, but not as much as they should. I'm still debugging, but wonder if there is any insight into how the layout system works that I've missed somewhere? >> >> Thanks, >> >> Scott -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian M?ller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340 From sebastian.rheinnecker at yworks.com Wed Oct 10 08:21:29 2012 From: sebastian.rheinnecker at yworks.com (Sebastian Rheinnecker) Date: Wed, 10 Oct 2012 17:21:29 +0200 Subject: Layout issues In-Reply-To: <5075911F.50800@yworks.com> References: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> <5075911F.50800@yworks.com> Message-ID: <50759279.3060706@yworks.com> Uhm, I meant to say "I overrode resize(double, double)". Don't know why it slipped ;) On 10.10.2012 17:15, Sebastian Rheinnecker wrote: > Hi Scott, > > I experienced quite a similar issue a while ago where a custom control > of mine got resized over and over again although no changes to the > width or height where applied. I overrode and made sure that if the > values didn't change it all the method in the super class aren't > called. That solved the issue for me. > > Kind regards, > Sebastian > > On 10.10.2012 15:56, Randahl Fink Isaksen wrote: >> Scott, in my experience this is not how JavaFX works in general. All >> my layoutChildren methods are only called when I change a property >> that directly or indirectly affects the layout, such as changing the >> text of a label or invoking requestLayout(). >> >> Your application must be doing something actively for this to happen, >> I believe. >> >> Perhaps you could remove parts of your UI until you isolate the >> component causing the problem. >> >> Randahl >> >> >> >> On Oct 10, 2012, at 15:42 , Scott Palmer wrote: >> >>> Hi, >>> >>> I have a custom container extending Pane that implements >>> layoutChildren. I've noticed that this method is called >>> continuously even though my scene is static. It's like something is >>> always in the list of "dirty" nodes and is forcing a re-layout. I >>> don't understand this. I've googled but I can't find a decent >>> tutorial for implementing custom containers or custom layouts. >>> >>> Part of the problem with my application is that nodes are not >>> properly shrining when I remove content from within them, they >>> shrink a little, but not as much as they should. I'm still >>> debugging, but wonder if there is any insight into how the layout >>> system works that I've missed somewhere? >>> >>> Thanks, >>> >>> Scott > > -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian M?ller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340 From phidias51 at gmail.com Wed Oct 10 08:28:17 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 10 Oct 2012 08:28:17 -0700 Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: Hi Peter, Comments below. > I am preferring to use Gradle these days. Nevertheless the issue of > putting JavaFX in a Maven Repository > is an important. Because JavaFX is not pure Java, the problem with > linking with native library is a major concern. > > Whatever JavaFX JAR you put in a artifact repository, whether SonaType > or Artifactory there has to be way to guarantee the code in the JAR > can always find the native libraries. Oracle have not come with a > scheme. I do not know of a safe way to do this portably that is cross > platform and work across all systems with causing a break if one or > the other dependencies are upgraded. The version, the native library > and the potential upgrades are the sticking problem. > > Then there is a licensing of the JavaFX Runtime and distribution of > Oracle's implementation. > Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version of the Ant tasks would make deployment easier. A maven archetype for creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. > > > - *Webstart deployment *- this is still problematic. Currently when > you > > push new artifacts to your web server, it's not replacing the > existing JARs > > in the user's cache -- despite what the documentation says. The > "special" > > javafx tags aren't documented well enough and presume that you're > using the > > Ant tools to generate the JNLP. And getting shaded jars is next to > > impossible. > > I do not have an answer to this web start problem. I do assume you can > upgrade Java 7. > > I'm currently running Java 7. > > > - *Charts* - support for zooming and panning within the charts. > Support > > for drawing on top of charts. > > The controls and charts code is open source, go and implement your > chart component. > Start with a copy of the line chart and hack it. > > Not really looking to hack JavaFX classes to support basic functionality. I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. > > > - *Support for Swing components within JavaFX. * If the goal is to > > replace Swing, then this is one of those essential capabilities that > needs > > to be in place. The current examples only demonstrate how to put > JavaFX > > components within Swing applications. Unfortunately, if you want to > reuse > > any existing components (like JFreeCharts for example) within your > project, > > you're SOL at the moment. > > They is not going to be 100% free ride on this extra third party > functionality. > > 1) Modify JFreeChart and port some of it or all of it to JavaFX > 2) Hack the existing Chart package until it gets you 80/20 of what you want > Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. > > > - *Support for an EventBus.* Currently, there's a lot of point2point > > event code that you have to write to fire and listen to events. It > would > > make for a much more useable codebase if you could simply publish and > > subscribe to events at the application level. > > Why not write a JavaFX extension framework that maps JavaFX Event to a > MessageBus implementation. > I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. > > > - *Release the source.* It's a royal pain to have to download the > > source through mercurial rather than simply read it as you do with the > > Swing code or download it as you do with any Maven package. > > > > The source code is there as JavaFX 2.2 as openjfx already. > I think you meant make the source code also a downloadable distribution. > Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. > > Hack the build.xml in the openjfx project, and contribute the Ant target. > > I also note that there should be a standalone JavaFX Doc as distribution > Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. > > Ditto - hack the build.xml to javadoc and zip up the javadoc > > Contrib the patch back to the team > > > There's also some work that needs to be done to make it easier for people > > to participate. I have 3 accounts at the moment: one for this mailing > > list, one for the forums, and one for JIRA. Can we just boil that down > to > > one, and let me login with Facebook or Google credentials? > > > > Have you heard of the online services Google Onepass or LastPass or > Yahoo Super wallet? Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase community participation. Most of what I've mentioned are items that should lower those barriers to entry. Mark From tbee at tbee.org Wed Oct 10 09:11:41 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 10 Oct 2012 18:11:41 +0200 Subject: Layout issues In-Reply-To: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> References: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> Message-ID: <50759E3D.9030503@tbee.org> I have been attempting to get custom panes laid out by overriding layoutChilderen as well, and ended up with only partial correct layouts, never quite perfect. Then I switched to listening to the pane's width and height properties and then call a custom relayout() method. That works perfectly. Furthermore, by using binding to such properties combined with the calculation features, it now is a breeze to get stuff laid out. Tom On 2012-10-10 15:42, Scott Palmer wrote: > Hi, > > I have a custom container extending Pane that implements layoutChildren. I've noticed that this method is called continuously even though my scene is static. It's like something is always in the list of "dirty" nodes and is forcing a re-layout. I don't understand this. I've googled but I can't find a decent tutorial for implementing custom containers or custom layouts. > > Part of the problem with my application is that nodes are not properly shrining when I remove content from within them, they shrink a little, but not as much as they should. I'm still debugging, but wonder if there is any insight into how the layout system works that I've missed somewhere? > > Thanks, > > Scott From richard.bair at oracle.com Wed Oct 10 09:12:43 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 10 Oct 2012 09:12:43 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <00ef01cda6bf$3be3c680$b3ab5380$@com.au> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <00ef01cda6bf$3be3c680$b3ab5380$@com.au> Message-ID: <35A6A60E-54CA-4F19-A4B3-046287BB4104@oracle.com> On Oct 10, 2012, at 1:14 AM, John C. Turnbull wrote: > Richard has stated that porting JavaFX to iOS or Android is not currently on the roadmap. So think what that means. The current roadmap extends out to 2015/16 or so with the release of JavaFX 8 & 9 so we are talking about some time after that. Realistically, if JavaFX ever actually does run on iOS or Android then it's going to be 2016/7 at the earliest. That's another 4 or 5 years from now and surely by then JavaFX will be so far behind other mobile platforms that it really will have missed the boat. That's not at all how it works. If it were put on the roadmap, it could be shipped in 6 months. Its not like you can't add features to a roadmap. Richard From tom.schindl at bestsolution.at Wed Oct 10 09:23:57 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 10 Oct 2012 18:23:57 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <35A6A60E-54CA-4F19-A4B3-046287BB4104@oracle.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <00ef01cda6bf$3be3c680$b3ab5380$@com.au> <35A6A60E-54CA-4F19-A4B3-046287BB4104@oracle.com> Message-ID: <5075A11D.80900@bestsolution.at> Hi, Having now read through the complete thread I think there are 2 things to take a way for me/us: * Talk to my customers and make them bug Oracle why they can't do cross platform development including iOS and Android * Wait for Oracle to opensource the rest and pray that you are releasing your current iOS/Android sources so that we can take a look I think I don't have to state how strange it is that some people at Oracle (I'm not talking about Richard and his team) don't really get that if JavaFX doesn't work on all platforms (including iOS/Anroid) they won't ever get enough momentum to really take off. I fully understand that Oracle can't fix all and everything for us. Tom Am 10.10.12 18:12, schrieb Richard Bair: > > On Oct 10, 2012, at 1:14 AM, John C. Turnbull wrote: > >> Richard has stated that porting JavaFX to iOS or Android is not currently on the roadmap. So think what that means. The current roadmap extends out to 2015/16 or so with the release of JavaFX 8 & 9 so we are talking about some time after that. Realistically, if JavaFX ever actually does run on iOS or Android then it's going to be 2016/7 at the earliest. That's another 4 or 5 years from now and surely by then JavaFX will be so far behind other mobile platforms that it really will have missed the boat. > > That's not at all how it works. If it were put on the roadmap, it could be shipped in 6 months. Its not like you can't add features to a roadmap. > > Richard > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Wed Oct 10 09:29:15 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 10 Oct 2012 18:29:15 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: <5075A25B.6060309@tbee.org> The minute someone from Oracle gives me the green light, those artifact are in Maven central. But I'm not going to take on Oracle's corporate lawyers in case I'm doing something that is in their eyes illegal. Tom On 2012-10-09 23:20, John McDonnell wrote: > Commented in line. > > On 9 October 2012 20:04, Mark Fortner wrote: > >> My preference would be to get the following tasks taken care of before >> Oracle starts throwing resources at supporting tablets, mobile and JavaFX >> 3D: >> >> - *Deployment using Maven.* Although you can build with Maven, there >> are a lot of hoops that you still have to jump through, and we still >> don't >> have the artifacts in an accessible repo. I think Zonski, and others >> have >> blogged about this, and kvetched on mailing lists so I won't repeat >> their >> comments here. >> > I actually though that this was fixed in 1.7u6, but after trying out a > simple maven project in 1.7u7 using netbeans, I realized that it was not as > easy as I hoped, well without the help of Google and ZenJava blog. > > For any sort of development I think these sort of things(Maven support, > deployment, etc) need to be looked into, it should be easy by now to simple > create a maven project and use JavaFX classes without jumping through any > hoops. There will be tighter integration of JavaFX in Java 8, when it > comes out right? if so thats still over half a year away :( > From swpalmer at gmail.com Wed Oct 10 11:13:48 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 10 Oct 2012 14:13:48 -0400 Subject: Layout issues In-Reply-To: <50759E3D.9030503@tbee.org> References: <9916D5C3-8439-4DA0-9300-8936410EA653@gmail.com> <50759E3D.9030503@tbee.org> Message-ID: <9974FADF-7FB5-4060-BFFE-1973EBA0ACA7@gmail.com> I found my original problem. One of my components called requestLayout on some of it's children in response to layoutChildren. I changed that to a direct call to layoutChildren and that did the trick. I'm still struggling with odd sizing behaviour - when I remove content from within a container the container still seems to think it counts as far as the layout bounds go. It's odd as I can see the container shrink because it knows some of the content has been removed, but there is another bit of content that is clearly defining the size of the parent even though it has been removed from the parent. Scott On 2012-10-10, at 12:11 PM, Tom Eugelink wrote: > I have been attempting to get custom panes laid out by overriding layoutChilderen as well, and ended up with only partial correct layouts, never quite perfect. Then I switched to listening to the pane's width and height properties and then call a custom relayout() method. That works perfectly. Furthermore, by using binding to such properties combined with the calculation features, it now is a breeze to get stuff laid out. > > Tom > > > On 2012-10-10 15:42, Scott Palmer wrote: >> Hi, >> >> I have a custom container extending Pane that implements layoutChildren. I've noticed that this method is called continuously even though my scene is static. It's like something is always in the list of "dirty" nodes and is forcing a re-layout. I don't understand this. I've googled but I can't find a decent tutorial for implementing custom containers or custom layouts. >> >> Part of the problem with my application is that nodes are not properly shrining when I remove content from within them, they shrink a little, but not as much as they should. I'm still debugging, but wonder if there is any insight into how the layout system works that I've missed somewhere? >> >> Thanks, >> >> Scott > From hang.vo at oracle.com Wed Oct 10 11:33:29 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 10 Oct 2012 18:33:29 +0000 Subject: hg: openjfx/8/controls/rt: Fix for RT-25049: SplitMenuButton have gap. Message-ID: <20121010183332.1C7D847288@hg.openjdk.java.net> Changeset: 988f6f79107b Author: rbair Date: 2012-10-10 11:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/988f6f79107b Fix for RT-25049: SplitMenuButton have gap. As near as I can tell, they have a gap going back a long way. In fact, the gap is still there with Region caching disabled (in fact with region caching turned on, you don't get this gap at all, so I think this error came from some time in the past). The MenuButtonSkinBase layout was incorrect, along with the CSS. ! javafx-ui-common/src/javafx/scene/layout/CornerRadii.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From danno.ferrin at shemnon.com Wed Oct 10 11:35:53 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Wed, 10 Oct 2012 12:35:53 -0600 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: On Wed, Oct 10, 2012 at 9:28 AM, Mark Fortner wrote: > Hi Peter, > > Comments below. > > > > I am preferring to use Gradle these days. Nevertheless the issue of > > putting JavaFX in a Maven Repository > > is an important. Because JavaFX is not pure Java, the problem with > > linking with native library is a major concern. > > > > Whatever JavaFX JAR you put in a artifact repository, whether SonaType > > or Artifactory there has to be way to guarantee the code in the JAR > > can always find the native libraries. Oracle have not come with a > > scheme. I do not know of a safe way to do this portably that is cross > > platform and work across all systems with causing a break if one or > > the other dependencies are upgraded. The version, the native library > > and the potential upgrades are the sticking problem. > > > > Then there is a licensing of the JavaFX Runtime and distribution of > > Oracle's implementation. > > > > Agreed. The assumption seems to be that if you use the Ant tasks to build, > then you're OK. Everything else, you're on your own. Most of the > organizations I've worked for left Ant behind 10 years ago. A mojo version > of the Ant tasks would make deployment easier. This is my problem with Maven the build system. You have to write and deploy classfiles to do anything but derivitives of current build styles. While it is good that it forces truly horrible build styles to conform to a convention as the path of least resistance, when you have to leave the trodden path it is incredibly painful. That is why I advocate Gradle for a new build, you can script your special cases in place and still deploy to a Maven repository. Maven the dependency system is generally speaking a good thing. > A maven archetype for > creating JavaFX projects would go a long way to making things easier. You > simply run the archetype all of your dependencies, Eclipse/NetBeans project > files, runtime environment variables are created for you. You could even > add a starter application. > For the most part it is the existing java archetype is already there. But what would excite me more would be conventions for how to add some of the standard additions to the file layout, so instead of putting stuff in the classpath and wiring in some ant calls you just drop some files in, configure nothing, run the appropriate goal or task, and get your bits. For example, all of this under src/main/deploy deploy.xml - xml config describing some of the values, such as jvm args, app name, etc with defaults driven by the POM icon.png - your default icon icons/icon_xx.png - multi sized icons package//... - per packaging depoyments. Platoform would be macosx, win, webstart, etc. Could also have a deploy.xml to override for local settings. We would need names and locations for signing keys, gatekeeper on mac would be different for sure. ps. why doesn't the list set the mailing list as the reply to? -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From phidias51 at gmail.com Wed Oct 10 11:51:28 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 10 Oct 2012 11:51:28 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: Cheers, Mark Hi Danno, >> >> > I am preferring to use Gradle these days. Nevertheless the issue of >> > putting JavaFX in a Maven Repository >> > is an important. Because JavaFX is not pure Java, the problem with >> > linking with native library is a major concern. >> > >> > Whatever JavaFX JAR you put in a artifact repository, whether SonaType >> > or Artifactory there has to be way to guarantee the code in the JAR >> > can always find the native libraries. Oracle have not come with a >> > scheme. I do not know of a safe way to do this portably that is cross >> > platform and work across all systems with causing a break if one or >> > the other dependencies are upgraded. The version, the native library >> > and the potential upgrades are the sticking problem. >> > >> > Then there is a licensing of the JavaFX Runtime and distribution of >> > Oracle's implementation. >> > >> >> Agreed. The assumption seems to be that if you use the Ant tasks to >> build, >> then you're OK. Everything else, you're on your own. Most of the >> organizations I've worked for left Ant behind 10 years ago. A mojo version >> of the Ant tasks would make deployment easier. > > > This is my problem with Maven the build system. You have to write and > deploy classfiles to do anything but derivitives of current build styles. > While it is good that it forces truly horrible build styles to conform to > a convention as the path of least resistance, when you have to leave the > trodden path it is incredibly painful. That is why I advocate Gradle for a > new build, you can script your special cases in place and still deploy to a > Maven repository. Maven the dependency system is generally speaking a good > thing. > >> The only time I've had to deviate from the well-trodden path is when I've had to take an Ant project, and add Maven to it without breaking the Ant build. I've looked at Gradle, and used it on a Groovy project that I've worked on, but I've found that the majority of the people still use Maven. In a typical technology adoption curve, Gradle seems to be on the leading edge of the curve, Maven on the peak of the curve, and Ant on the trailing edge. My thought was to try and get the JavaFX team to focus on the needs of the 80% of the enterprise developers who are out there and are looking at converting their existing Swing application into a JavaFX app. > A maven archetype for >> creating JavaFX projects would go a long way to making things easier. You >> simply run the archetype all of your dependencies, Eclipse/NetBeans >> project >> files, runtime environment variables are created for you. You could even >> add a starter application. >> > > For the most part it is the existing java archetype is already there. But > what would excite me more would be conventions for how to add some of the > standard additions to the file layout, so instead of putting stuff in the > classpath and wiring in some ant calls you just drop some files in, > configure nothing, run the appropriate goal or task, and get your bits. > > For example, all of this under src/main/deploy > deploy.xml - xml config describing some of the values, such as jvm args, > app name, etc with defaults driven by the POM > icon.png - your default icon > icons/icon_xx.png - multi sized icons > package//... - per packaging depoyments. Platoform would be > macosx, win, webstart, etc. Could also have a deploy.xml to override for > local settings. > > We would need names and locations for signing keys, gatekeeper on mac > would > Agreed. It needs to just as easy as you describe. Unfortunately, it's not there yet. I think Richard mentioned in his quarterly report that he was working on making it easier, but I haven't seen any specifics about this. > > ps. why doesn't the list set the mailing list as the reply to? > > Grrr. ;-) From tbee at tbee.org Wed Oct 10 12:06:42 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 10 Oct 2012 21:06:42 +0200 Subject: reply list In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: <5075C742.1090802@tbee.org> >> >> ps. why doesn't the list set the mailing list as the reply to? >> >> > Grrr. ;-) In Thunderbird I have a "reply" and "reply list" button, only for these mailinglist emails. Tom From randahl at rockit.dk Wed Oct 10 13:01:19 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 10 Oct 2012 22:01:19 +0200 Subject: reply list In-Reply-To: <5075C742.1090802@tbee.org> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> Message-ID: <7BF10BAF-5735-4160-9FFF-4AD5F0E472C2@rockit.dk> The problem is because the mailing list does not set the reply-to header of the outgoing mails. I really wish someone would fix that. It happens quite often that someone replies directly. Randahl On Oct 10, 2012, at 21:06 , Tom Eugelink wrote: > >>> >>> ps. why doesn't the list set the mailing list as the reply to? >>> >>> >> Grrr. ;-) > > > In Thunderbird I have a "reply" and "reply list" button, only for these mailinglist emails. > > Tom > From debasish.raychawdhuri at gmail.com Wed Oct 10 13:07:41 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Thu, 11 Oct 2012 01:37:41 +0530 Subject: reply list In-Reply-To: <7BF10BAF-5735-4160-9FFF-4AD5F0E472C2@rockit.dk> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> <7BF10BAF-5735-4160-9FFF-4AD5F0E472C2@rockit.dk> Message-ID: Yes I am also having the same problem, it must be fixed. On Thu, Oct 11, 2012 at 1:31 AM, Randahl Fink Isaksen wrote: > The problem is because the mailing list does not set the reply-to header of the outgoing mails. I really wish someone would fix that. It happens quite often that someone replies directly. > > Randahl > > > On Oct 10, 2012, at 21:06 , Tom Eugelink wrote: > >> >>>> >>>> ps. why doesn't the list set the mailing list as the reply to? >>>> >>>> >>> Grrr. ;-) >> >> >> In Thunderbird I have a "reply" and "reply list" button, only for these mailinglist emails. >> >> Tom >> > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From james.graham at oracle.com Wed Oct 10 13:26:12 2012 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Oct 2012 13:26:12 -0700 Subject: reply list In-Reply-To: <5075C742.1090802@tbee.org> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> Message-ID: <5075D9E4.3000306@oracle.com> Indeed I prefer it this way as I don't always want to burden the list with my replies. This list gives the option, but "Reply-To-List" lists don't have any convenient way to reply to just the sender... ...jim On 10/10/12 12:06 PM, Tom Eugelink wrote: > >>> >>> ps. why doesn't the list set the mailing list as the reply to? >>> >>> >> Grrr. ;-) > > > In Thunderbird I have a "reply" and "reply list" button, only for these > mailinglist emails. > > Tom > From zonski at gmail.com Wed Oct 10 14:12:03 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 11 Oct 2012 08:12:03 +1100 Subject: Fwd: No JavaFX for iOS, Android or WP - why not? References: Message-ID: Ah yea, forgot to reply all. Begin forwarded message: > From: Daniel Zwolenski > Date: 11 October 2012 1:42:19 AM AEDT > To: Richard Bair > Subject: Re: No JavaFX for iOS, Android or WP - why not? > > This is not whining, this is highlighting problems so solutions can be worked out. I thought that was the point of this forum and this community? > > And to stress even more, as I said very early on this is not just about iOS or Android support. It's about the direction JavaFX is heading and how it can be a real contender for mainstream serious application development, not just for niche use cases and platform enthusiasts. > > I'm not looking for a justification or defence of the current position (that's just wasting time and not making anything better). I'm looking for recognition of a genuine problem and then a workable solution > > Here's the problem: I'm a JFX fan. I want to use JFX. I currently can't. > > I work smack bang in the 'serious application' space Richard has indicated is the prime space for JFX. Right now I am building Grant Application management software (i.e. apply for and allocate funding). It is your classic form based system with a 'public facing' UI for applicants, a 'back-office' management UI, and a power 'admin' UI for helpdesk. I believe the back-office and admin UI systems are exactly the sort of apps Richard is talking about. I also believe this type of app is pretty damn similar to 80% of the Java applications out there. > > What's more my client is a pure-Java advocate, is totally open to using new technologies if they can be demonstrated to be better than their existing ones, and my client has some very sharp developers working for them. They _should_ be an absolute prime candidate for using JavaFX if it is truly the best platform for them. But they can't justify the move and I can't come up with a logical argument why they should. > > Isn't that a problem: the key target space for JFX, the right conditions; the 80% use case and yet still no movement. Isn't that something we should be looking at? I get that others are moving to JFX but as Richard alludes to below these are mostly Swing developers - that's a no brainer and not really the lion's share of the market. We need to see webapp developers making the switch to JFX. > > Tell me how you would sell JavaFX into a client who is already using webapps? I've tried these arguments and they don't work (my argument in bold, webapp developer's counter argument follows): > > JavaFX is cross platform. - Well so is HTML+JScript. In fact HTML will even work on iPads and Android tablets so you can take it into the meeting with you or do your work on the train. What's more to build HTML for all my platforms I just run one simple Maven build and deploy it to my server. To build cross platform JFX I have to have every possible OS setup with JFX installed, then I need the special packaging tool for that platform installed and on my path (with different steps on Mac, Linux and Windows), and I need to upload all of these separately and make sure the right one is delivered to the right client. Oh and there's no auto-updating yet, but in web land the user can just hit refresh. > > JavaFX doesn't have cross-browser problems: Yea but you have to install Java (horrible) or a co-bundled app (still pretty raw), which is really no worse than telling a back-office web user they can only use one browser (such as Chrome), cross-browser issues magically gone! > > JavaFX can do richer user interfaces: not really, have you seen what you can do on the web these days? > > CSS selectors suck to maintain and debug: umm, JFX uses the same CSS selector model. What's more web has already started to address this with @Less, JFX has to play some catchup just to be on par. > > JavaFX is all pure Java none of that nasty scripting: sure but using JQuery and other JScript libraries you don't actually have to write that much JavaScript any more. Add in things like Google Closure Templates and things get quite clean. What's more IDE support for JScript is pretty good these days so you pick up a lot of scripting problems early, which is more than I can say for IDE support for things like FXML or JFX CSS - not enough community pressure to get those supported. > > JavaFX has layout managers: yea ok you win on that one, layout in HTML with CSS is horrible. But then there's things like Twitter Bootstrap which make it manageable, and to be honest us webapp guys have memorized all the obscure CSS hacks to get around this, so really it's not such a big deal, and we'd have to learn all new tricks in JFX anyway. > > JavaFX works offline: hey that's kind of cool but really all our users are connected to the web, and offline has security problems. It's not a strong use case for us, and to be honest we could probably do something with JScript if we really wanted to anyway. > > JavaFX will work on mobile so we can re-use our code and not have to write new XCode: ah, no it won't. Didn't you read those forum posts? > > > Once the web app developer has then finished ripping my arguments apart, he/she then lays in a few more blows: > HTML webapp development has a massive community behind it. Heaps bigger than JFX with a whole range of established tools and platforms, from awesome Spring integration to form validation frameworks, style sheet and HTML template libraries, Twitter Bootstrap, years worth of tutorials, example and well answered questions on StackOverflow > > HTML5 is gradually adding stuff that you wouldn't believe a browser could do, like 3D graphics, multi-media offline data storage. It is doing or will do everything that is on the JFX roadmap. > > Given the Java installation hassles, the client-facing side of things will always have to be HTML so we're going to have to do webapp development no matter what. Since the same coders are going to be working on all three UI's and there are some common components between them all, if we use web across the board then we can re-use things and keep all the patterns consistent making it easier to learn and maintain. > > Are you telling me I can't use Maven to do a JFX build properly? There's no plugin for it - forget it. > > So help me out here. What's the comeback? I've got nothing - and I can't imagine how anyone else building these sorts of apps is in any better position for selling in JavaFX in this key space?! > > > Some other more specific comments inline below. > > > On Wed, Oct 10, 2012 at 1:22 PM, Richard Bair wrote: > > > The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. > > I should hope not. I know many developers (some of whom have already spoken up on this thread) happy to do a port. Android hasn't had any trouble getting 3rd parties to port Android to anything and everything. A new port of JavaFX is not a major undertaking, almost the entire platform just works. > > Sorry to be a bit pedantic, but if it is not a major undertaking then why is it that Oracle is so wary of committing resources to it? This doesn't stack up. Is there some reason other than resources why Oracle isn't wanting to support mobile? > > Also, as I mentioned at the start of this email, iOS and Android is only one half of this conversation. The other is making it competitive with webapps. Which firstly and most importantly means properly addressing deployment well beyond co-bundling (e.g. the JScript 'VM' idea and/or a massively simplified one-click installer for a 'Java Browser' of some kind). > > I can't imagine any of that is trivial. > > > > Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. > > That's just being silly. HTML 5 isn't even going to be here for a few more years, let alone 6. > > Fair call but 'lazy' might be a better adjective than 'silly'. I was hand-waving for the feature number when I said HTML6, I meant that by the time all the above work is done HTML will have had those (2, 3, 4, 5?) years to improve upon it's current position (i.e. it will be at HTML-now++), whereas JFX will just be hitting the point that HTML is at now. That's before we take into account the size of the community improving HTML+JScript vs the size of the community improving JFX. > > And it's worth noting that although the HTML5 spec is not going to 'be here for a few more years' the good bits of the implementation are actually already alive and well in modern browsers. Basically when webapp people talk about HTML5 in general conversation they are usually talking about where HTML is at now. It's pretty good compared to what it was even a few years ago. More standard, less buggy, and good tools for hiding the worst of it. > > GWT (which allows you to compile Java to cross-platform JScript) is on the decline for example, since the current state of HTML makes it less relevant (of course the GWT enthusiasts will react to that comment just as angrily as the Flash ones would if I said that was on the decline, and as the JFX have been when I suggest something is out competing it - we all love our team). > > > > Secondly, where's the incentive for the community to do this? > > If there is no incentive, then I guess you've proved the point, no? > > Not quite. My question was not "where's the incentive for mobile and webapp support" but rather why put effort into adding this to the JFX platform when a competitor (i.e. webapp) already has it. Why not instead just move to that competitor and use your 'spare time' to add something even cooler on top of it. > > There's absolutely no doubt in my mind that the community not only wants, but has to have, both mobile and web support in their toolkit. If there is one toolkit that can offer both cleanly, allowing reuse between platforms, then that will be the one developers will turn to even if it has some other minor shortcomings. Web is nudging there already but it's crude. JavaFX could do it better but if it turns up too late for the party everyone will already be on the dance floor with Webapp. > > > I should hope there is a large amount of incentive, as others on this thread (and many more privately) have verified. You act as though nobody has adopted JavaFX, but we're seeing a broad swell of adoption, especially among existing Swing developers. > > I'd love to know more about the non-Swing developers adopting it. How many are there, why are they doing it, how are they finding it and what are they building with it. > > Convincing Swing developers to move to JFX is like convincing a kid to eat ice cream instead of sprouts. It's the other movements that are the indicators of long term mainstream success in my opinion. > > There are a lot of people who are developing for JavaFX commercially, and most of those people are not talking about it openly. Some very big customers in the lot. They love FX and are also committed to it. > > Get them talking. Get them making noise. They need a community as much as the community needs them. Silence gets no one anywhere in this game. Growth leads to growth, snowball, critical mass, momentum. > > Do we have a "JFX sightings" yet? If not, I'd say that would be useful. > > Oracle funds hundreds of salaries based on JavaFX & Java client. There is a huge, heavy investment from Oracle. JavaFX is here for a long time -- we've got paying customers and we've got support contracts. Look, we got beat up real bad for not having Mac and Linux support at 1.0, people questioned publicly whether we'd ever do it. > > On the Mac/Linux issue, it was pretty early on for my involvement so maybe I remember incorrectly but I thought you guys made a pretty public commitment to supporting these from the outset (just didn't specify dates). So the guys 'beating you up' just didn't trust Oracle and were unjustified in this. > > That's not the same as this situation is it? What we're seeing here is an open (if slightly vague) stance being taken to not support mobile and not care too much about web. We're hearing "Oracle won't do it but the community can if it wants". > > As ever with this stuff you're going to cop the brunt of it because you're the face of it all. I've seen enough of how you and your team work to know you guys want everything we want for this platform, and you're all working your guts out to make it happen. I'm sure you're probably pushing back on this just as hard as we're all pushing back on you. For me this isn't about lampooning any of the work here or kicking or screaming for the sake of it - it's about waving a flag at the train driver so we can pull out the map and check that we're on the right track (and if needs be get the union to march on HQ to get some new tracks laid). > > Truly sort out deployment and I am certain JFX can penetrate webapp (but only if it happens soon, html5 is winning the battle for hearts and minds). > > Support mobile and I am certain JFX will own this space quickly (easy win - it's such a mess). > > Either space would be enough to grow the community past tipping point (and from this everything else would flow). > > Supporting both spaces would make it the all round winner. > > Support neither and, in my opinion, JFX will be limited to the space currently owned by Swing. Sure it'll be around for a long time but it won't be a main player, and certainly won't achieve it's potential. > > From debasish.raychawdhuri at gmail.com Wed Oct 10 16:26:48 2012 From: debasish.raychawdhuri at gmail.com (Debasish Ray Chawdhuri) Date: Thu, 11 Oct 2012 04:56:48 +0530 Subject: reply list In-Reply-To: <5075D9E4.3000306@oracle.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> <5075D9E4.3000306@oracle.com> Message-ID: Since the question was asked on the mailing list, other people following the mailing list should get the answers. There is no hide-and-seek here. Most of the time you should not contact the sender directly. Just in case you do (for whatever weird reason, is it too bad to be shared?), you can still copy address of the sender. You may be thinking of the mailing list as some kind of help forum, where you are the expert and and resolve people's problems, so you give an answer only to them. But that should not be the intention of the list. It is more made for a community discussion. When you give an answer, other people should be able to see that answer and ask more questions or possibly challenge your answer. This is how a community should work. Why do you want to deal with individuals? On Thu, Oct 11, 2012 at 1:56 AM, Jim Graham wrote: > Indeed I prefer it this way as I don't always want to burden the list with > my replies. > > This list gives the option, but "Reply-To-List" lists don't have any > convenient way to reply to just the sender... > > ...jim > > > On 10/10/12 12:06 PM, Tom Eugelink wrote: >> >> >>>> >>>> ps. why doesn't the list set the mailing list as the reply to? >>>> >>>> >>> Grrr. ;-) >> >> >> >> In Thunderbird I have a "reply" and "reply list" button, only for these >> mailinglist emails. >> >> Tom >> > -- Debasish Ray Chawdhuri http://www.geekyarticles.com/ [A collection of advanced articles on java] From randahl at rockit.dk Wed Oct 10 16:46:06 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 11 Oct 2012 01:46:06 +0200 Subject: reply list In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> <5075D9E4.3000306@oracle.com> Message-ID: +1 from me. Well said! R. On Oct 11, 2012, at 1:26 , Debasish Ray Chawdhuri wrote: > Since the question was asked on the mailing list, other people > following the mailing list should get the answers. There is no > hide-and-seek here. Most of the time you should not contact the sender > directly. Just in case you do (for whatever weird reason, is it too > bad to be shared?), you can still copy address of the sender. > > You may be thinking of the mailing list as some kind of help forum, > where you are the expert and and resolve people's problems, so you > give an answer only to them. But that should not be the intention of > the list. It is more made for a community discussion. When you give an > answer, other people should be able to see that answer and ask more > questions or possibly challenge your answer. This is how a community > should work. > > Why do you want to deal with individuals? > > On Thu, Oct 11, 2012 at 1:56 AM, Jim Graham wrote: >> Indeed I prefer it this way as I don't always want to burden the list with >> my replies. >> >> This list gives the option, but "Reply-To-List" lists don't have any >> convenient way to reply to just the sender... >> >> ...jim >> >> >> On 10/10/12 12:06 PM, Tom Eugelink wrote: >>> >>> >>>>> >>>>> ps. why doesn't the list set the mailing list as the reply to? >>>>> >>>>> >>>> Grrr. ;-) >>> >>> >>> >>> In Thunderbird I have a "reply" and "reply list" button, only for these >>> mailinglist emails. >>> >>> Tom >>> >> > > > > -- > Debasish Ray Chawdhuri > http://www.geekyarticles.com/ > [A collection of advanced articles on java] From james.graham at oracle.com Wed Oct 10 18:10:53 2012 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Oct 2012 18:10:53 -0700 Subject: reply list In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> <5075D9E4.3000306@oracle.com> Message-ID: <50761C9D.5030207@oracle.com> First, my comment was not any official position (as I said "I" prefer). A reply may not always be an answer. I'm implying no hide-and-seek here, but intentionally I may want to clarify something before I make an informed public response, or hash out some half-baked ideas in private before bringing them to list in a "more well baked" form. If I feel I am speaking from a position of knowledge then I will, quite instinctively, hit Reply-To-All and not even have to think about whether my message is reaching people. To avoid beating this issue any further - my general feelings are summarized well by resources found at the following page: http://marc.merlins.org/netrants/listreplyto.html which points primarily to this really well written message on the topic: http://www.unicom.com/pw/reply-to-harmful.html (and also includes a pointer to a counter-point that he refutes as well in another link...) ...jim On 10/10/12 4:26 PM, Debasish Ray Chawdhuri wrote: > Since the question was asked on the mailing list, other people > following the mailing list should get the answers. There is no > hide-and-seek here. Most of the time you should not contact the sender > directly. Just in case you do (for whatever weird reason, is it too > bad to be shared?), you can still copy address of the sender. > > You may be thinking of the mailing list as some kind of help forum, > where you are the expert and and resolve people's problems, so you > give an answer only to them. But that should not be the intention of > the list. It is more made for a community discussion. When you give an > answer, other people should be able to see that answer and ask more > questions or possibly challenge your answer. This is how a community > should work. > > Why do you want to deal with individuals? > > On Thu, Oct 11, 2012 at 1:56 AM, Jim Graham wrote: >> Indeed I prefer it this way as I don't always want to burden the list with >> my replies. >> >> This list gives the option, but "Reply-To-List" lists don't have any >> convenient way to reply to just the sender... >> >> ...jim >> >> >> On 10/10/12 12:06 PM, Tom Eugelink wrote: >>> >>> >>>>> >>>>> ps. why doesn't the list set the mailing list as the reply to? >>>>> >>>>> >>>> Grrr. ;-) >>> >>> >>> >>> In Thunderbird I have a "reply" and "reply list" button, only for these >>> mailinglist emails. >>> >>> Tom >>> >> > > > From goddard at seznam.cz Thu Oct 11 02:43:04 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Thu, 11 Oct 2012 11:43:04 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Fwd=3A=20No=20JavaFX=20for=20iOS=2C=20Android=20or=20WP=20=2D=20why=20not=3F?= In-Reply-To: Message-ID: <136091.15429.49126-10977-571333069-1349948583@seznam.cz> Has anyone actually tried to get JFX running on iPhone / iPad / Android except the guys from Oracle? The ARMs in Raspberry Pi and Apple iPhone seem to be quite similar. iPhone uses ARM 7, JavaSE embedded is targeted at ARM 6/7 https://blogs.oracle.com/jtc/entry/raspberry_pi_and_java_se more technical writeup: https://blogs.oracle.com/javaone/entry/session_report_java_on_the Jiri ------------ P?vodn? zpr?va ------------ Od: Daniel Zwolenski P?edm?t: Fwd: No JavaFX for iOS, Android or WP - why not? Datum: 10.10.2012 23:13:58 ---------------------------------------- Ah yea, forgot to reply all. Begin forwarded message: > From: Daniel Zwolenski > Date: 11 October 2012 1:42:19 AM AEDT > To: Richard Bair > Subject: Re: No JavaFX for iOS, Android or WP - why not? > > This is not whining, this is highlighting problems so solutions can be worked out. I thought that was the point of this forum and this community? > > And to stress even more, as I said very early on this is not just about iOS or Android support. It's about the direction JavaFX is heading and how it can be a real contender for mainstream serious application development, not just for niche use cases and platform enthusiasts. > > I'm not looking for a justification or defence of the current position (that's just wasting time and not making anything better). I'm looking for recognition of a genuine problem and then a workable solution > > Here's the problem: I'm a JFX fan. I want to use JFX. I currently can't. > > I work smack bang in the 'serious application' space Richard has indicated is the prime space for JFX. Right now I am building Grant Application management software (i.e. apply for and allocate funding). It is your classic form based system with a 'public facing' UI for applicants, a 'back-office' management UI, and a power 'admin' UI for helpdesk. I believe the back-office and admin UI systems are exactly the sort of apps Richard is talking about. I also believe this type of app is pretty damn similar to 80% of the Java applications out there. > > What's more my client is a pure-Java advocate, is totally open to using new technologies if they can be demonstrated to be better than their existing ones, and my client has some very sharp developers working for them. They _should_ be an absolute prime candidate for using JavaFX if it is truly the best platform for them. But they can't justify the move and I can't come up with a logical argument why they should. > > Isn't that a problem: the key target space for JFX, the right conditions; the 80% use case and yet still no movement. Isn't that something we should be looking at? I get that others are moving to JFX but as Richard alludes to below these are mostly Swing developers - that's a no brainer and not really the lion's share of the market. We need to see webapp developers making the switch to JFX. > > Tell me how you would sell JavaFX into a client who is already using webapps? I've tried these arguments and they don't work (my argument in bold, webapp developer's counter argument follows): > > JavaFX is cross platform. - Well so is HTML+JScript. In fact HTML will even work on iPads and Android tablets so you can take it into the meeting with you or do your work on the train. What's more to build HTML for all my platforms I just run one simple Maven build and deploy it to my server. To build cross platform JFX I have to have every possible OS setup with JFX installed, then I need the special packaging tool for that platform installed and on my path (with different steps on Mac, Linux and Windows), and I need to upload all of these separately and make sure the right one is delivered to the right client. Oh and there's no auto-updating yet, but in web land the user can just hit refresh. > > JavaFX doesn't have cross-browser problems: Yea but you have to install Java (horrible) or a co-bundled app (still pretty raw), which is really no worse than telling a back-office web user they can only use one browser (such as Chrome), cross-browser issues magically gone! > > JavaFX can do richer user interfaces: not really, have you seen what you can do on the web these days? > > CSS selectors suck to maintain and debug: umm, JFX uses the same CSS selector model. What's more web has already started to address this with @Less, JFX has to play some catchup just to be on par. > > JavaFX is all pure Java none of that nasty scripting: sure but using JQuery and other JScript libraries you don't actually have to write that much JavaScript any more. Add in things like Google Closure Templates and things get quite clean. What's more IDE support for JScript is pretty good these days so you pick up a lot of scripting problems early, which is more than I can say for IDE support for things like FXML or JFX CSS - not enough community pressure to get those supported. > > JavaFX has layout managers: yea ok you win on that one, layout in HTML with CSS is horrible. But then there's things like Twitter Bootstrap which make it manageable, and to be honest us webapp guys have memorized all the obscure CSS hacks to get around this, so really it's not such a big deal, and we'd have to learn all new tricks in JFX anyway. > > JavaFX works offline: hey that's kind of cool but really all our users are connected to the web, and offline has security problems. It's not a strong use case for us, and to be honest we could probably do something with JScript if we really wanted to anyway. > > JavaFX will work on mobile so we can re-use our code and not have to write new XCode: ah, no it won't. Didn't you read those forum posts? > > > Once the web app developer has then finished ripping my arguments apart, he/she then lays in a few more blows: > HTML webapp development has a massive community behind it. Heaps bigger than JFX with a whole range of established tools and platforms, from awesome Spring integration to form validation frameworks, style sheet and HTML template libraries, Twitter Bootstrap, years worth of tutorials, example and well answered questions on StackOverflow > > HTML5 is gradually adding stuff that you wouldn't believe a browser could do, like 3D graphics, multi-media offline data storage. It is doing or will do everything that is on the JFX roadmap. > > Given the Java installation hassles, the client-facing side of things will always have to be HTML so we're going to have to do webapp development no matter what. Since the same coders are going to be working on all three UI's and there are some common components between them all, if we use web across the board then we can re-use things and keep all the patterns consistent making it easier to learn and maintain. > > Are you telling me I can't use Maven to do a JFX build properly? There's no plugin for it - forget it. > > So help me out here. What's the comeback? I've got nothing - and I can't imagine how anyone else building these sorts of apps is in any better position for selling in JavaFX in this key space?! > > > Some other more specific comments inline below. > > > On Wed, Oct 10, 2012 at 1:22 PM, Richard Bair wrote: > > > The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. > > I should hope not. I know many developers (some of whom have already spoken up on this thread) happy to do a port. Android hasn't had any trouble getting 3rd parties to port Android to anything and everything. A new port of JavaFX is not a major undertaking, almost the entire platform just works. > > Sorry to be a bit pedantic, but if it is not a major undertaking then why is it that Oracle is so wary of committing resources to it? This doesn't stack up. Is there some reason other than resources why Oracle isn't wanting to support mobile? > > Also, as I mentioned at the start of this email, iOS and Android is only one half of this conversation. The other is making it competitive with webapps. Which firstly and most importantly means properly addressing deployment well beyond co-bundling (e.g. the JScript 'VM' idea and/or a massively simplified one-click installer for a 'Java Browser' of some kind). > > I can't imagine any of that is trivial. > > > > Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. > > That's just being silly. HTML 5 isn't even going to be here for a few more years, let alone 6. > > Fair call but 'lazy' might be a better adjective than 'silly'. I was hand-waving for the feature number when I said HTML6, I meant that by the time all the above work is done HTML will have had those (2, 3, 4, 5?) years to improve upon it's current position (i.e. it will be at HTML-now++), whereas JFX will just be hitting the point that HTML is at now. That's before we take into account the size of the community improving HTML+JScript vs the size of the community improving JFX. > > And it's worth noting that although the HTML5 spec is not going to 'be here for a few more years' the good bits of the implementation are actually already alive and well in modern browsers. Basically when webapp people talk about HTML5 in general conversation they are usually talking about where HTML is at now. It's pretty good compared to what it was even a few years ago. More standard, less buggy, and good tools for hiding the worst of it. > > GWT (which allows you to compile Java to cross-platform JScript) is on the decline for example, since the current state of HTML makes it less relevant (of course the GWT enthusiasts will react to that comment just as angrily as the Flash ones would if I said that was on the decline, and as the JFX have been when I suggest something is out competing it - we all love our team). > > > > Secondly, where's the incentive for the community to do this? > > If there is no incentive, then I guess you've proved the point, no? > > Not quite. My question was not "where's the incentive for mobile and webapp support" but rather why put effort into adding this to the JFX platform when a competitor (i.e. webapp) already has it. Why not instead just move to that competitor and use your 'spare time' to add something even cooler on top of it. > > There's absolutely no doubt in my mind that the community not only wants, but has to have, both mobile and web support in their toolkit. If there is one toolkit that can offer both cleanly, allowing reuse between platforms, then that will be the one developers will turn to even if it has some other minor shortcomings. Web is nudging there already but it's crude. JavaFX could do it better but if it turns up too late for the party everyone will already be on the dance floor with Webapp. > > > I should hope there is a large amount of incentive, as others on this thread (and many more privately) have verified. You act as though nobody has adopted JavaFX, but we're seeing a broad swell of adoption, especially among existing Swing developers. > > I'd love to know more about the non-Swing developers adopting it. How many are there, why are they doing it, how are they finding it and what are they building with it. > > Convincing Swing developers to move to JFX is like convincing a kid to eat ice cream instead of sprouts. It's the other movements that are the indicators of long term mainstream success in my opinion. > > There are a lot of people who are developing for JavaFX commercially, and most of those people are not talking about it openly. Some very big customers in the lot. They love FX and are also committed to it. > > Get them talking. Get them making noise. They need a community as much as the community needs them. Silence gets no one anywhere in this game. Growth leads to growth, snowball, critical mass, momentum. > > Do we have a "JFX sightings" yet? If not, I'd say that would be useful. > > Oracle funds hundreds of salaries based on JavaFX & Java client. There is a huge, heavy investment from Oracle. JavaFX is here for a long time -- we've got paying customers and we've got support contracts. Look, we got beat up real bad for not having Mac and Linux support at 1.0, people questioned publicly whether we'd ever do it. > > On the Mac/Linux issue, it was pretty early on for my involvement so maybe I remember incorrectly but I thought you guys made a pretty public commitment to supporting these from the outset (just didn't specify dates). So the guys 'beating you up' just didn't trust Oracle and were unjustified in this. > > That's not the same as this situation is it? What we're seeing here is an open (if slightly vague) stance being taken to not support mobile and not care too much about web. We're hearing "Oracle won't do it but the community can if it wants". > > As ever with this stuff you're going to cop the brunt of it because you're the face of it all. I've seen enough of how you and your team work to know you guys want everything we want for this platform, and you're all working your guts out to make it happen. I'm sure you're probably pushing back on this just as hard as we're all pushing back on you. For me this isn't about lampooning any of the work here or kicking or screaming for the sake of it - it's about waving a flag at the train driver so we can pull out the map and check that we're on the right track (and if needs be get the union to march on HQ to get some new tracks laid). > > Truly sort out deployment and I am certain JFX can penetrate webapp (but only if it happens soon, html5 is winning the battle for hearts and minds). > > Support mobile and I am certain JFX will own this space quickly (easy win - it's such a mess). > > Either space would be enough to grow the community past tipping point (and from this everything else would flow). > > Supporting both spaces would make it the all round winner. > > Support neither and, in my opinion, JFX will be limited to the space currently owned by Swing. Sure it'll be around for a long time but it won't be a main player, and certainly won't achieve it's potential. > > From randahl at rockit.dk Thu Oct 11 05:59:44 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 11 Oct 2012 14:59:44 +0200 Subject: Jira is down Message-ID: It looks like Jira needs a reboot. I get: "The jira.home directory '/issues/jira-42' is already locked. Please see the JIRA documentation for more information on locked jira.home directories." Randahl From kevin.rushforth at oracle.com Thu Oct 11 06:02:45 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Oct 2012 06:02:45 -0700 Subject: Jira is down In-Reply-To: References: Message-ID: <5076C375.9090502@oracle.com> Yes, this has been reported to the lab managers. -- Kevin Randahl Fink Isaksen wrote: > It looks like Jira needs a reboot. I get: > > "The jira.home directory '/issues/jira-42' is already locked. Please see the JIRA documentation for more information on locked jira.home directories." > > Randahl From omurata at ga2.so-net.ne.jp Thu Oct 11 07:21:09 2012 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Thu, 11 Oct 2012 23:21:09 +0900 Subject: JavaFX will be available on WindowsRT? In-Reply-To: References: Message-ID: <5076D5D5.90509@ga2.so-net.ne.jp> > >From http://technology.amis.nl/2012/10/08/javaone-2012-the-big-stories/ > > "JavaFX is no longer intended for use on SmartPhones" > "Note: Java Applets are on their way out" > > I understand that JavaFX will not be available on iOS nor Android nor WindowsPhone. And then JavaFX will be available on WindowsRT ( Windows8 on ARM ) ? WindowsRT is not SmaortPhone but a kind of Desktop. Best regards Tadashi Ohmura From goddard at seznam.cz Thu Oct 11 08:16:41 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Thu, 11 Oct 2012 17:16:41 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Fwd=3A=20No=20JavaFX=20for=20iOS=2C=20Android=20or=20WP=20=2D=20why=20not=3F?= In-Reply-To: <136091.15429.49126-10977-571333069-1349948583@seznam.cz> Message-ID: <136123.15397.49179-884-1118160099-1349968601@seznam.cz> Useful info about JFX on ARM from Oracle: http://jdk7.java.net/fxarmpreview/javafx-arm-developer-preview.html Jiri ------------ P?vodn? zpr?va ------------ Od: P?edm?t: Re: Fwd: No JavaFX for iOS, Android or WP - why not? Datum: 11.10.2012 11:57:22 ---------------------------------------- Has anyone actually tried to get JFX running on iPhone / iPad / Android except the guys from Oracle? The ARMs in Raspberry Pi and Apple iPhone seem to be quite similar. iPhone uses ARM 7, JavaSE embedded is targeted at ARM 6/7 https://blogs.oracle.com/jtc/entry/raspberry_pi_and_java_se more technical writeup: https://blogs.oracle.com/javaone/entry/session_report_java_on_the Jiri ------------ P?vodn? zpr?va ------------ Od: Daniel Zwolenski P?edm?t: Fwd: No JavaFX for iOS, Android or WP - why not? Datum: 10.10.2012 23:13:58 ---------------------------------------- Ah yea, forgot to reply all. Begin forwarded message: > From: Daniel Zwolenski > Date: 11 October 2012 1:42:19 AM AEDT > To: Richard Bair > Subject: Re: No JavaFX for iOS, Android or WP - why not? > > This is not whining, this is highlighting problems so solutions can be worked out. I thought that was the point of this forum and this community? > > And to stress even more, as I said very early on this is not just about iOS or Android support. It's about the direction JavaFX is heading and how it can be a real contender for mainstream serious application development, not just for niche use cases and platform enthusiasts. > > I'm not looking for a justification or defence of the current position (that's just wasting time and not making anything better). I'm looking for recognition of a genuine problem and then a workable solution > > Here's the problem: I'm a JFX fan. I want to use JFX. I currently can't. > > I work smack bang in the 'serious application' space Richard has indicated is the prime space for JFX. Right now I am building Grant Application management software (i.e. apply for and allocate funding). It is your classic form based system with a 'public facing' UI for applicants, a 'back-office' management UI, and a power 'admin' UI for helpdesk. I believe the back-office and admin UI systems are exactly the sort of apps Richard is talking about. I also believe this type of app is pretty damn similar to 80% of the Java applications out there. > > What's more my client is a pure-Java advocate, is totally open to using new technologies if they can be demonstrated to be better than their existing ones, and my client has some very sharp developers working for them. They _should_ be an absolute prime candidate for using JavaFX if it is truly the best platform for them. But they can't justify the move and I can't come up with a logical argument why they should. > > Isn't that a problem: the key target space for JFX, the right conditions; the 80% use case and yet still no movement. Isn't that something we should be looking at? I get that others are moving to JFX but as Richard alludes to below these are mostly Swing developers - that's a no brainer and not really the lion's share of the market. We need to see webapp developers making the switch to JFX. > > Tell me how you would sell JavaFX into a client who is already using webapps? I've tried these arguments and they don't work (my argument in bold, webapp developer's counter argument follows): > > JavaFX is cross platform. - Well so is HTML+JScript. In fact HTML will even work on iPads and Android tablets so you can take it into the meeting with you or do your work on the train. What's more to build HTML for all my platforms I just run one simple Maven build and deploy it to my server. To build cross platform JFX I have to have every possible OS setup with JFX installed, then I need the special packaging tool for that platform installed and on my path (with different steps on Mac, Linux and Windows), and I need to upload all of these separately and make sure the right one is delivered to the right client. Oh and there's no auto-updating yet, but in web land the user can just hit refresh. > > JavaFX doesn't have cross-browser problems: Yea but you have to install Java (horrible) or a co-bundled app (still pretty raw), which is really no worse than telling a back-office web user they can only use one browser (such as Chrome), cross-browser issues magically gone! > > JavaFX can do richer user interfaces: not really, have you seen what you can do on the web these days? > > CSS selectors suck to maintain and debug: umm, JFX uses the same CSS selector model. What's more web has already started to address this with @Less, JFX has to play some catchup just to be on par. > > JavaFX is all pure Java none of that nasty scripting: sure but using JQuery and other JScript libraries you don't actually have to write that much JavaScript any more. Add in things like Google Closure Templates and things get quite clean. What's more IDE support for JScript is pretty good these days so you pick up a lot of scripting problems early, which is more than I can say for IDE support for things like FXML or JFX CSS - not enough community pressure to get those supported. > > JavaFX has layout managers: yea ok you win on that one, layout in HTML with CSS is horrible. But then there's things like Twitter Bootstrap which make it manageable, and to be honest us webapp guys have memorized all the obscure CSS hacks to get around this, so really it's not such a big deal, and we'd have to learn all new tricks in JFX anyway. > > JavaFX works offline: hey that's kind of cool but really all our users are connected to the web, and offline has security problems. It's not a strong use case for us, and to be honest we could probably do something with JScript if we really wanted to anyway. > > JavaFX will work on mobile so we can re-use our code and not have to write new XCode: ah, no it won't. Didn't you read those forum posts? > > > Once the web app developer has then finished ripping my arguments apart, he/she then lays in a few more blows: > HTML webapp development has a massive community behind it. Heaps bigger than JFX with a whole range of established tools and platforms, from awesome Spring integration to form validation frameworks, style sheet and HTML template libraries, Twitter Bootstrap, years worth of tutorials, example and well answered questions on StackOverflow > > HTML5 is gradually adding stuff that you wouldn't believe a browser could do, like 3D graphics, multi-media offline data storage. It is doing or will do everything that is on the JFX roadmap. > > Given the Java installation hassles, the client-facing side of things will always have to be HTML so we're going to have to do webapp development no matter what. Since the same coders are going to be working on all three UI's and there are some common components between them all, if we use web across the board then we can re-use things and keep all the patterns consistent making it easier to learn and maintain. > > Are you telling me I can't use Maven to do a JFX build properly? There's no plugin for it - forget it. > > So help me out here. What's the comeback? I've got nothing - and I can't imagine how anyone else building these sorts of apps is in any better position for selling in JavaFX in this key space?! > > > Some other more specific comments inline below. > > > On Wed, Oct 10, 2012 at 1:22 PM, Richard Bair wrote: > > > The notion that once its all open source the community can do all the extra work to bridge the short commings is a bit of a fantasy. > > I should hope not. I know many developers (some of whom have already spoken up on this thread) happy to do a port. Android hasn't had any trouble getting 3rd parties to port Android to anything and everything. A new port of JavaFX is not a major undertaking, almost the entire platform just works. > > Sorry to be a bit pedantic, but if it is not a major undertaking then why is it that Oracle is so wary of committing resources to it? This doesn't stack up. Is there some reason other than resources why Oracle isn't wanting to support mobile? > > Also, as I mentioned at the start of this email, iOS and Android is only one half of this conversation. The other is making it competitive with webapps. Which firstly and most importantly means properly addressing deployment well beyond co-bundling (e.g. the JScript 'VM' idea and/or a massively simplified one-click installer for a 'Java Browser' of some kind). > > I can't imagine any of that is trivial. > > > > Firstly, it's going to take way too long to get there, established platforms are snowballing ahead as JavaFX struggles to catch up. We'll have HTML6 by the time JFX gets open sourced AND then the community gets round to adding features that needed to be in there 6 months ago to be competitive. > > That's just being silly. HTML 5 isn't even going to be here for a few more years, let alone 6. > > Fair call but 'lazy' might be a better adjective than 'silly'. I was hand-waving for the feature number when I said HTML6, I meant that by the time all the above work is done HTML will have had those (2, 3, 4, 5?) years to improve upon it's current position (i.e. it will be at HTML-now++), whereas JFX will just be hitting the point that HTML is at now. That's before we take into account the size of the community improving HTML+JScript vs the size of the community improving JFX. > > And it's worth noting that although the HTML5 spec is not going to 'be here for a few more years' the good bits of the implementation are actually already alive and well in modern browsers. Basically when webapp people talk about HTML5 in general conversation they are usually talking about where HTML is at now. It's pretty good compared to what it was even a few years ago. More standard, less buggy, and good tools for hiding the worst of it. > > GWT (which allows you to compile Java to cross-platform JScript) is on the decline for example, since the current state of HTML makes it less relevant (of course the GWT enthusiasts will react to that comment just as angrily as the Flash ones would if I said that was on the decline, and as the JFX have been when I suggest something is out competing it - we all love our team). > > > > Secondly, where's the incentive for the community to do this? > > If there is no incentive, then I guess you've proved the point, no? > > Not quite. My question was not "where's the incentive for mobile and webapp support" but rather why put effort into adding this to the JFX platform when a competitor (i.e. webapp) already has it. Why not instead just move to that competitor and use your 'spare time' to add something even cooler on top of it. > > There's absolutely no doubt in my mind that the community not only wants, but has to have, both mobile and web support in their toolkit. If there is one toolkit that can offer both cleanly, allowing reuse between platforms, then that will be the one developers will turn to even if it has some other minor shortcomings. Web is nudging there already but it's crude. JavaFX could do it better but if it turns up too late for the party everyone will already be on the dance floor with Webapp. > > > I should hope there is a large amount of incentive, as others on this thread (and many more privately) have verified. You act as though nobody has adopted JavaFX, but we're seeing a broad swell of adoption, especially among existing Swing developers. > > I'd love to know more about the non-Swing developers adopting it. How many are there, why are they doing it, how are they finding it and what are they building with it. > > Convincing Swing developers to move to JFX is like convincing a kid to eat ice cream instead of sprouts. It's the other movements that are the indicators of long term mainstream success in my opinion. > > There are a lot of people who are developing for JavaFX commercially, and most of those people are not talking about it openly. Some very big customers in the lot. They love FX and are also committed to it. > > Get them talking. Get them making noise. They need a community as much as the community needs them. Silence gets no one anywhere in this game. Growth leads to growth, snowball, critical mass, momentum. > > Do we have a "JFX sightings" yet? If not, I'd say that would be useful. > > Oracle funds hundreds of salaries based on JavaFX & Java client. There is a huge, heavy investment from Oracle. JavaFX is here for a long time -- we've got paying customers and we've got support contracts. Look, we got beat up real bad for not having Mac and Linux support at 1.0, people questioned publicly whether we'd ever do it. > > On the Mac/Linux issue, it was pretty early on for my involvement so maybe I remember incorrectly but I thought you guys made a pretty public commitment to supporting these from the outset (just didn't specify dates). So the guys 'beating you up' just didn't trust Oracle and were unjustified in this. > > That's not the same as this situation is it? What we're seeing here is an open (if slightly vague) stance being taken to not support mobile and not care too much about web. We're hearing "Oracle won't do it but the community can if it wants". > > As ever with this stuff you're going to cop the brunt of it because you're the face of it all. I've seen enough of how you and your team work to know you guys want everything we want for this platform, and you're all working your guts out to make it happen. I'm sure you're probably pushing back on this just as hard as we're all pushing back on you. For me this isn't about lampooning any of the work here or kicking or screaming for the sake of it - it's about waving a flag at the train driver so we can pull out the map and check that we're on the right track (and if needs be get the union to march on HQ to get some new tracks laid). > > Truly sort out deployment and I am certain JFX can penetrate webapp (but only if it happens soon, html5 is winning the battle for hearts and minds). > > Support mobile and I am certain JFX will own this space quickly (easy win - it's such a mess). > > Either space would be enough to grow the community past tipping point (and from this everything else would flow). > > Supporting both spaces would make it the all round winner. > > Support neither and, in my opinion, JFX will be limited to the space currently owned by Swing. Sure it'll be around for a long time but it won't be a main player, and certainly won't achieve it's potential. > > From david.dehaven at oracle.com Thu Oct 11 08:31:42 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 11 Oct 2012 08:31:42 -0700 Subject: reply list In-Reply-To: <50761C9D.5030207@oracle.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> <5075D9E4.3000306@oracle.com> <50761C9D.5030207@oracle.com> Message-ID: <581602AB-3402-446E-88A6-77CC778EEB6F@oracle.com> It all boils down to RFC-2822 superseding RFC-822 and the new language states that reply-to is an originator field supplied by the author alone. The list software should inject list headers as outlined in RFC-2369, one such header is List-Post which provides an address to send responses to the list at, then it's up to the client to decide whether to use From, Reply-To or List-Post when composing a response. This list conforms to RFC-2369 and provides such a field: List-Post: If you want the default reply action to post to the list then you must configure your client to do so, there is nothing to be done on the list side. -DrD- > First, my comment was not any official position (as I said "I" prefer). > > A reply may not always be an answer. I'm implying no hide-and-seek here, but intentionally I may want to clarify something before I make an informed public response, or hash out some half-baked ideas in private before bringing them to list in a "more well baked" form. If I feel I am speaking from a position of knowledge then I will, quite instinctively, hit Reply-To-All and not even have to think about whether my message is reaching people. > > To avoid beating this issue any further - my general feelings are summarized well by resources found at the following page: > > http://marc.merlins.org/netrants/listreplyto.html > > which points primarily to this really well written message on the topic: > http://www.unicom.com/pw/reply-to-harmful.html > > (and also includes a pointer to a counter-point that he refutes as well in another link...) > > ...jim > > On 10/10/12 4:26 PM, Debasish Ray Chawdhuri wrote: >> Since the question was asked on the mailing list, other people >> following the mailing list should get the answers. There is no >> hide-and-seek here. Most of the time you should not contact the sender >> directly. Just in case you do (for whatever weird reason, is it too >> bad to be shared?), you can still copy address of the sender. >> >> You may be thinking of the mailing list as some kind of help forum, >> where you are the expert and and resolve people's problems, so you >> give an answer only to them. But that should not be the intention of >> the list. It is more made for a community discussion. When you give an >> answer, other people should be able to see that answer and ask more >> questions or possibly challenge your answer. This is how a community >> should work. >> >> Why do you want to deal with individuals? >> >> On Thu, Oct 11, 2012 at 1:56 AM, Jim Graham wrote: >>> Indeed I prefer it this way as I don't always want to burden the list with >>> my replies. >>> >>> This list gives the option, but "Reply-To-List" lists don't have any >>> convenient way to reply to just the sender... >>> >>> ...jim >>> >>> >>> On 10/10/12 12:06 PM, Tom Eugelink wrote: >>>> >>>> >>>>>> >>>>>> ps. why doesn't the list set the mailing list as the reply to? >>>>>> >>>>>> >>>>> Grrr. ;-) >>>> >>>> >>>> >>>> In Thunderbird I have a "reply" and "reply list" button, only for these >>>> mailinglist emails. >>>> >>>> Tom >>>> >>> >> >> >> From lehmann at media-interactive.de Thu Oct 11 09:02:13 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 11 Oct 2012 18:02:13 +0200 Subject: reply list In-Reply-To: <581602AB-3402-446E-88A6-77CC778EEB6F@oracle.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <5075C742.1090802@tbee.org> <5075D9E4.3000306@oracle.com> <50761C9D.5030207@oracle.com> <581602AB-3402-446E-88A6-77CC778EEB6F@oracle.com> Message-ID: <5076ED85.8000301@media-interactive.de> In Thunderbird you will find this in the main menu, Message | Reply to List. This command can also be added to the toolbar. On 11.10.2012 17:31, David DeHaven wrote: > If you want the default reply action to post to the list then you > must configure your client to do so, there is nothing to be done on > the list side. From hang.vo at oracle.com Thu Oct 11 10:17:14 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 11 Oct 2012 17:17:14 +0000 Subject: hg: openjfx/8/controls/rt: Updated documentation to indicate contents draw over borders on regions. Message-ID: <20121011171720.0FBBA472C3@hg.openjdk.java.net> Changeset: 32ed56155a53 Author: rbair Date: 2012-10-11 10:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/32ed56155a53 Updated documentation to indicate contents draw over borders on regions. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html From hang.vo at oracle.com Thu Oct 11 13:02:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 11 Oct 2012 20:02:44 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20121011200247.CACB0472CF@hg.openjdk.java.net> Changeset: 8d346510b927 Author: leifs Date: 2012-10-11 12:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8d346510b927 Additional fix for RT-25049 to avoid label truncation. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java Changeset: 41cfd7b80910 Author: David Grieve Date: 2012-10-11 15:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/41cfd7b80910 RT-25016: calculated value not stored in cache when styles are recalculted. remove fastpath check and always cache calculated value. ensure inline styles are cached locally ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: ef37b66b00b0 Author: David Grieve Date: 2012-10-11 15:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ef37b66b00b0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Thu Oct 11 13:17:12 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 11 Oct 2012 20:17:12 +0000 Subject: hg: openjfx/8/controls/rt: Make VK_TYPE_NAMES array package private. Message-ID: <20121011201716.4E536472D5@hg.openjdk.java.net> Changeset: 09253f3afb0b Author: leifs Date: 2012-10-11 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/09253f3afb0b Make VK_TYPE_NAMES array package private. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java From hang.vo at oracle.com Thu Oct 11 15:20:02 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 11 Oct 2012 22:20:02 +0000 Subject: hg: openjfx/8/master/rt: 9 new changesets Message-ID: <20121011222014.27870472F4@hg.openjdk.java.net> Changeset: c8deba0d0fb6 Author: Lubomir Nerad Date: 2012-10-09 12:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c8deba0d0fb6 Fix for RT-24681: added javadocs ! javafx-ui-common/src/javafx/stage/DirectoryChooser.java ! javafx-ui-common/src/javafx/stage/FileChooser.java Changeset: b06b91a885a0 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-09 09:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b06b91a885a0 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt Changeset: c15a91781139 Author: David Grieve Date: 2012-10-04 17:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c15a91781139 RT-25118: replace code removed by bad merge, and other optimizations ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Match.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: bedd78e543a0 Author: David Grieve Date: 2012-10-04 17:06 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bedd78e543a0 RT-25133: strip off package when comparing class name in css selector ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-controls/test/javafx/scene/control/PopupControlTest.java Changeset: 80b5d7e96fdb Author: David Grieve Date: 2012-10-05 14:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/80b5d7e96fdb RT-25370: upper four bits represent an index. When getting the index value, need to shift unsigned ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java Changeset: fe99329cd02e Author: rbair Date: 2012-10-08 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe99329cd02e Removed tests that are not doing anything. - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlicesTest.java - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlices_builder_Test.java Changeset: c0aff81b30ad Author: leifs Date: 2012-10-09 10:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c0aff81b30ad Fixed RT-25479: [TextField] Text input starts from wrong position. Disable caret bias handling util it can be fully supported. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: ea00b638cdd6 Author: leifs Date: 2012-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ea00b638cdd6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlicesTest.java - javafx-ui-common/test/unit/javafx/scene/layout/BorderImageSlices_builder_Test.java Changeset: 7f6a99c842fd Author: hudson Date: 2012-10-11 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7f6a99c842fd Added tag 8.0-b60 for changeset ea00b638cdd6 ! .hgtags From tbee at tbee.org Fri Oct 12 08:56:53 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 12 Oct 2012 17:56:53 +0200 Subject: bold & italic Message-ID: <50783DC5.1050402@tbee.org> I've got two Text nodes in my layout; I can style them with -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? Tom From randahl at rockit.dk Fri Oct 12 09:04:02 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 12 Oct 2012 18:04:02 +0200 Subject: bold & italic In-Reply-To: <50783DC5.1050402@tbee.org> References: <50783DC5.1050402@tbee.org> Message-ID: Just a wild guess: Could it be that there is no italic version of the font chosen? You could verify this by choosing another font. R. On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: > I've got two Text nodes in my layout; I can style them with -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? > > Tom > From tbee at tbee.org Fri Oct 12 09:08:55 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 12 Oct 2012 18:08:55 +0200 Subject: bold & italic In-Reply-To: References: <50783DC5.1050402@tbee.org> Message-ID: <50784097.3080101@tbee.org> Hm. Could be. I'm using the default font. On 2012-10-12 18:04, Randahl Fink Isaksen wrote: > Just a wild guess: Could it be that there is no italic version of the font chosen? You could verify this by choosing another font. > > R. > > > On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: > >> I've got two Text nodes in my layout; I can style them with -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? >> >> Tom >> From philip.race at oracle.com Fri Oct 12 10:01:17 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Oct 2012 10:01:17 -0700 Subject: bold & italic In-Reply-To: <50784097.3080101@tbee.org> References: <50783DC5.1050402@tbee.org> <50784097.3080101@tbee.org> Message-ID: <50784CDD.10008@oracle.com> I thought the problem might be setting it via CSS but at least on Windows that works for me. So are you on OS X ? I think the default font there may not have italic styles. -phil. On 10/12/2012 9:08 AM, Tom Eugelink wrote: > Hm. Could be. I'm using the default font. > > > On 2012-10-12 18:04, Randahl Fink Isaksen wrote: >> Just a wild guess: Could it be that there is no italic version of the >> font chosen? You could verify this by choosing another font. >> >> R. >> >> >> On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: >> >>> I've got two Text nodes in my layout; I can style them with >>> -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? >>> >>> Tom >>> > From tbee at tbee.org Fri Oct 12 10:05:11 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 12 Oct 2012 19:05:11 +0200 Subject: bold & italic In-Reply-To: <50784CDD.10008@oracle.com> References: <50783DC5.1050402@tbee.org> <50784097.3080101@tbee.org> <50784CDD.10008@oracle.com> Message-ID: <50784DC7.2070108@tbee.org> I'm on windows xp. On 2012-10-12 19:01, Phil Race wrote: > I thought the problem might be setting it via CSS but at least on Windows that works for me. > > So are you on OS X ? I think the default font there may not have italic styles. > > -phil. > > On 10/12/2012 9:08 AM, Tom Eugelink wrote: >> Hm. Could be. I'm using the default font. >> >> >> On 2012-10-12 18:04, Randahl Fink Isaksen wrote: >>> Just a wild guess: Could it be that there is no italic version of the font chosen? You could verify this by choosing another font. >>> >>> R. >>> >>> >>> On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: >>> >>>> I've got two Text nodes in my layout; I can style them with -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? >>>> >>>> Tom >>>> >> > From philip.race at oracle.com Fri Oct 12 10:21:15 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Oct 2012 10:21:15 -0700 Subject: bold & italic In-Reply-To: <50784DC7.2070108@tbee.org> References: <50783DC5.1050402@tbee.org> <50784097.3080101@tbee.org> <50784CDD.10008@oracle.com> <50784DC7.2070108@tbee.org> Message-ID: <5078518B.1040907@oracle.com> Ah, then same issue. I'd forgotten that Tahoma lacks an italic style. -phil. On 10/12/2012 10:05 AM, Tom Eugelink wrote: > I'm on windows xp. > > > On 2012-10-12 19:01, Phil Race wrote: >> I thought the problem might be setting it via CSS but at least on >> Windows that works for me. >> >> So are you on OS X ? I think the default font there may not have >> italic styles. >> >> -phil. >> >> On 10/12/2012 9:08 AM, Tom Eugelink wrote: >>> Hm. Could be. I'm using the default font. >>> >>> >>> On 2012-10-12 18:04, Randahl Fink Isaksen wrote: >>>> Just a wild guess: Could it be that there is no italic version of >>>> the font chosen? You could verify this by choosing another font. >>>> >>>> R. >>>> >>>> >>>> On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: >>>> >>>>> I've got two Text nodes in my layout; I can style them with >>>>> -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? >>>>> >>>>> Tom >>>>> >>> >> > From philip.race at oracle.com Fri Oct 12 10:33:00 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Oct 2012 10:33:00 -0700 Subject: bold & italic In-Reply-To: <5078518B.1040907@oracle.com> References: <50783DC5.1050402@tbee.org> <50784097.3080101@tbee.org> <50784CDD.10008@oracle.com> <50784DC7.2070108@tbee.org> <5078518B.1040907@oracle.com> Message-ID: <5078544C.4070505@oracle.com> BTW .. in case it has escaped notice or not been mentioned, it looks unlikely that other than FX 2.2.X patch releases, that future releases : meaning JDK 8/ FX 8 etc, will support XP ... It'll get dropped because MS will be EOSLing XP anyway. -phil. On 10/12/2012 10:21 AM, Phil Race wrote: > Ah, then same issue. I'd forgotten that Tahoma lacks an italic style. > > -phil. > > On 10/12/2012 10:05 AM, Tom Eugelink wrote: >> I'm on windows xp. >> >> >> On 2012-10-12 19:01, Phil Race wrote: >>> I thought the problem might be setting it via CSS but at least on >>> Windows that works for me. >>> >>> So are you on OS X ? I think the default font there may not have >>> italic styles. >>> >>> -phil. >>> >>> On 10/12/2012 9:08 AM, Tom Eugelink wrote: >>>> Hm. Could be. I'm using the default font. >>>> >>>> >>>> On 2012-10-12 18:04, Randahl Fink Isaksen wrote: >>>>> Just a wild guess: Could it be that there is no italic version of >>>>> the font chosen? You could verify this by choosing another font. >>>>> >>>>> R. >>>>> >>>>> >>>>> On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: >>>>> >>>>>> I've got two Text nodes in my layout; I can style them with >>>>>> -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? >>>>>> >>>>>> Tom >>>>>> >>>> >>> >> > From randahl at rockit.dk Fri Oct 12 10:46:22 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 12 Oct 2012 19:46:22 +0200 Subject: bold & italic In-Reply-To: <5078544C.4070505@oracle.com> References: <50783DC5.1050402@tbee.org> <50784097.3080101@tbee.org> <50784CDD.10008@oracle.com> <50784DC7.2070108@tbee.org> <5078518B.1040907@oracle.com> <5078544C.4070505@oracle.com> Message-ID: No support for Windows XP? Well, it is also over a decade old, so perhaps the efforts of the JavaFX developers was better spent elsewhere. Randahl On Oct 12, 2012, at 19:33 , Phil Race wrote: > BTW .. in case it has escaped notice or not been mentioned, it > looks unlikely that other than FX 2.2.X patch releases, > that future releases : meaning JDK 8/ FX 8 etc, will support XP ... > It'll get dropped because MS will be EOSLing XP anyway. > > -phil. > > On 10/12/2012 10:21 AM, Phil Race wrote: >> Ah, then same issue. I'd forgotten that Tahoma lacks an italic style. >> >> -phil. >> >> On 10/12/2012 10:05 AM, Tom Eugelink wrote: >>> I'm on windows xp. >>> >>> >>> On 2012-10-12 19:01, Phil Race wrote: >>>> I thought the problem might be setting it via CSS but at least on Windows that works for me. >>>> >>>> So are you on OS X ? I think the default font there may not have italic styles. >>>> >>>> -phil. >>>> >>>> On 10/12/2012 9:08 AM, Tom Eugelink wrote: >>>>> Hm. Could be. I'm using the default font. >>>>> >>>>> >>>>> On 2012-10-12 18:04, Randahl Fink Isaksen wrote: >>>>>> Just a wild guess: Could it be that there is no italic version of the font chosen? You could verify this by choosing another font. >>>>>> >>>>>> R. >>>>>> >>>>>> >>>>>> On Oct 12, 2012, at 17:56 , Tom Eugelink wrote: >>>>>> >>>>>>> I've got two Text nodes in my layout; I can style them with -fx-font-weight: bold, but -fx-font-style: italic is ignored. Why? >>>>>>> >>>>>>> Tom >>>>>>> >>>>> >>>> >>> >> > From tbee at tbee.org Fri Oct 12 11:35:36 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 12 Oct 2012 20:35:36 +0200 Subject: bold & italic In-Reply-To: <5078544C.4070505@oracle.com> References: <50783DC5.1050402@tbee.org> <50784097.3080101@tbee.org> <50784CDD.10008@oracle.com> <50784DC7.2070108@tbee.org> <5078518B.1040907@oracle.com> <5078544C.4070505@oracle.com> Message-ID: <507862F8.6000109@tbee.org> I've got a VMWare image that clone whenever I start a new development project. And it's still WXP based. Maybe I should upgrade... Tom On 2012-10-12 19:33, Phil Race wrote: > BTW .. in case it has escaped notice or not been mentioned, it > looks unlikely that other than FX 2.2.X patch releases, > that future releases : meaning JDK 8/ FX 8 etc, will support XP ... > It'll get dropped because MS will be EOSLing XP anyway. > > -phil. From hang.vo at oracle.com Fri Oct 12 12:02:15 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 12 Oct 2012 19:02:15 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121012190218.646D447331@hg.openjdk.java.net> Changeset: 393c90eb52e0 Author: David Grieve Date: 2012-10-12 14:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/393c90eb52e0 RT-25225: default background color should be transparent per w3c spec ! javafx-ui-common/src/javafx/scene/layout/Background.java Changeset: 9352015d712d Author: David Grieve Date: 2012-10-12 14:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9352015d712d RT-24784: ensure parent style manager is properly initialized ! javafx-ui-common/src/javafx/scene/Parent.java From hang.vo at oracle.com Fri Oct 12 18:03:19 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 13 Oct 2012 01:03:19 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20121013010325.988AA4734E@hg.openjdk.java.net> Changeset: 91c30a8859db Author: rbair Date: 2012-09-20 22:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91c30a8859db Improved handling of thumb size, from previous patch 81cc13fe6f96 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 408ee6a41174 Author: David Hill Date: 2012-10-09 17:44 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/408ee6a41174 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: 19bdbf3b30ee Author: David Hill Date: 2012-10-12 11:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19bdbf3b30ee Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt From Claus.Luethje at osys.ch Mon Oct 15 04:33:46 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Mon, 15 Oct 2012 11:33:46 +0000 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: Message-ID: <193FF4ED343AF14F8CDC65B4792C954D13296353@Jeri.osys.ch> I want to be working on mobile app based on JavaFX with my team. We have built skills (and still are) and interest, but how can we convince customers to invest in JavaFX? I see JavaFX as a very efficient way to build GUIs; it's fast, versatile and fun. It could be a perfect match for RIA, but time-to-market is important and JavaFX isn't there yet. Regards Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Pedro Duque Vieira Sent: Mittwoch, 10. Oktober 2012 00:13 To: OpenJFX Mailing List Subject: Re: No JavaFX for iOS, Android or WP - why not? > > Richard and crew, is Oracle using JavaFX in commercial situations? If > so are you able to tell us how/where (ie what space) and to what > extent? Maybe knowing this will help us understand the reasons behind > all this and the direction Oracle sees this all going (and allow us to > decide if we want to help row that boat or jump out now). > Just as (possibility more) disappointing as the mobile stuff is this > vibe that Oracle does not see JFX having much of a role in the 'web' > space. It looks like a straight bow-out to HTML5. > I highly doubt any of this stuff is your, or your team's preference > and sentiment, but as great as that is, it doesn't help us. Oracle > holds the purse strings and that's what will control, and direct the platform. > Serious, non-rhetorical question: if you were a front-line developer > right now what sort of job would you say to your customer "the best > platform your needs here is JavaFX"? > The notion that once its all open source the community can do all the > extra work to bridge the short commings is a bit of a fantasy. > Firstly, it's going to take way too long to get there, established > platforms are snowballing ahead as JavaFX struggles to catch up. We'll > have > HTML6 by the time JFX gets open sourced AND then the community gets > round to adding features that needed to be in there 6 months ago to be > competitive. > Secondly, where's the incentive for the community to do this? Why not > invest our time in making something with a more complete base better > instead of plugging gaping holes in a niche, orphaned technology that > "has interesting potential". There's no critical mass to the community > yet, and another year or two of not being relevant in the major spaces > of web and mobile will only see this worsen. I've had to go to HTML5 > over the last few months because JFX just isn't ready. Another couple > of months and I'll be so heavily invested in HTML5 based solutions > that I won't be able to justify coming back. > Finally, if we didn't need a large corporation backing/financing the > main components of this thing then JFX would have been built by the > community years ago. If Oracle is only looking at this platform as > some sort of glorified 3D charting gimmick, then the community won't > get the under-swell of momentum it needs to get past the tipping point > where it just grows by itself. > The attitude needs to be "if you build it, they will come". Currently > it looks like "when they come they can then build it". Can anyone > actually see that working? > Without web and/or mobile you're fishing for a community without > having any bait. No community means no one to build the tools needed > to then grow it, no one pushing IDEs to support it, no one making > frameworks others can leverage. Which of course is a cyclic spiral into obscurity. > As I said I dont doubt your commitment to this platform but I do now > doubt Oracle's. I want to be wrong - tell us how and when JavaFX is > going to be relevant to any significant space or sector. +100 on Daniel Zwolenski comments. I wish JavaFX to be the platform of choice for RIA but right now with the current state of affairs I don't see that coming. -- Pedro Duque Vieira From Claus.Luethje at osys.ch Mon Oct 15 04:45:39 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Mon, 15 Oct 2012 11:45:39 +0000 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> +1 for the maven support -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Mittwoch, 10. Oktober 2012 17:28 To: openjfx-dev at openjdk.java.net Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? Hi Peter, Comments below. > I am preferring to use Gradle these days. Nevertheless the issue of > putting JavaFX in a Maven Repository is an important. Because JavaFX > is not pure Java, the problem with linking with native library is a > major concern. > > Whatever JavaFX JAR you put in a artifact repository, whether SonaType > or Artifactory there has to be way to guarantee the code in the JAR > can always find the native libraries. Oracle have not come with a > scheme. I do not know of a safe way to do this portably that is cross > platform and work across all systems with causing a break if one or > the other dependencies are upgraded. The version, the native library > and the potential upgrades are the sticking problem. > > Then there is a licensing of the JavaFX Runtime and distribution of > Oracle's implementation. > Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version of the Ant tasks would make deployment easier. A maven archetype for creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. > > > - *Webstart deployment *- this is still problematic. Currently > > when > you > > push new artifacts to your web server, it's not replacing the > existing JARs > > in the user's cache -- despite what the documentation says. The > "special" > > javafx tags aren't documented well enough and presume that you're > using the > > Ant tools to generate the JNLP. And getting shaded jars is next to > > impossible. > > I do not have an answer to this web start problem. I do assume you can > upgrade Java 7. > > I'm currently running Java 7. > > > - *Charts* - support for zooming and panning within the charts. > Support > > for drawing on top of charts. > > The controls and charts code is open source, go and implement your > chart component. > Start with a copy of the line chart and hack it. > > Not really looking to hack JavaFX classes to support basic functionality. I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. > > > - *Support for Swing components within JavaFX. * If the goal is to > > replace Swing, then this is one of those essential capabilities > > that > needs > > to be in place. The current examples only demonstrate how to put > JavaFX > > components within Swing applications. Unfortunately, if you want > > to > reuse > > any existing components (like JFreeCharts for example) within > > your > project, > > you're SOL at the moment. > > They is not going to be 100% free ride on this extra third party > functionality. > > 1) Modify JFreeChart and port some of it or all of it to JavaFX > 2) Hack the existing Chart package until it gets you 80/20 of what you > want > Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. > > > - *Support for an EventBus.* Currently, there's a lot of point2point > > event code that you have to write to fire and listen to events. > > It > would > > make for a much more useable codebase if you could simply publish and > > subscribe to events at the application level. > > Why not write a JavaFX extension framework that maps JavaFX Event to a > MessageBus implementation. > I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. > > > - *Release the source.* It's a royal pain to have to download the > > source through mercurial rather than simply read it as you do with the > > Swing code or download it as you do with any Maven package. > > > > The source code is there as JavaFX 2.2 as openjfx already. > I think you meant make the source code also a downloadable distribution. > Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. > > Hack the build.xml in the openjfx project, and contribute the Ant target. > > I also note that there should be a standalone JavaFX Doc as > distribution > Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. > > Ditto - hack the build.xml to javadoc and zip up the javadoc > > Contrib the patch back to the team > > > There's also some work that needs to be done to make it easier for > > people to participate. I have 3 accounts at the moment: one for > > this mailing list, one for the forums, and one for JIRA. Can we > > just boil that down > to > > one, and let me login with Facebook or Google credentials? > > > > Have you heard of the online services Google Onepass or LastPass or > Yahoo Super wallet? Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase community participation. Most of what I've mentioned are items that should lower those barriers to entry. Mark From tom.schindl at bestsolution.at Mon Oct 15 04:54:11 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 15 Oct 2012 13:54:11 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> Message-ID: <507BF963.6080404@bestsolution.at> Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330) Tom Am 15.10.12 13:45, schrieb Claus Luethje: > +1 for the maven support > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner > Sent: Mittwoch, 10. Oktober 2012 17:28 > To: openjfx-dev at openjdk.java.net > Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? > > Hi Peter, > > Comments below. > > >> I am preferring to use Gradle these days. Nevertheless the issue of >> putting JavaFX in a Maven Repository is an important. Because JavaFX >> is not pure Java, the problem with linking with native library is a >> major concern. >> >> Whatever JavaFX JAR you put in a artifact repository, whether SonaType >> or Artifactory there has to be way to guarantee the code in the JAR >> can always find the native libraries. Oracle have not come with a >> scheme. I do not know of a safe way to do this portably that is cross >> platform and work across all systems with causing a break if one or >> the other dependencies are upgraded. The version, the native library >> and the potential upgrades are the sticking problem. >> >> Then there is a licensing of the JavaFX Runtime and distribution of >> Oracle's implementation. >> > > Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version > of the Ant tasks would make deployment easier. A maven archetype for > creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. > > > >> >>> - *Webstart deployment *- this is still problematic. Currently >>> when >> you >>> push new artifacts to your web server, it's not replacing the >> existing JARs >>> in the user's cache -- despite what the documentation says. The >> "special" >>> javafx tags aren't documented well enough and presume that you're >> using the >>> Ant tools to generate the JNLP. And getting shaded jars is next to >>> impossible. >> >> I do not have an answer to this web start problem. I do assume you can >> upgrade Java 7. >> >> > > I'm currently running Java 7. > > > >> >>> - *Charts* - support for zooming and panning within the charts. >> Support >>> for drawing on top of charts. >> >> The controls and charts code is open source, go and implement your >> chart component. >> Start with a copy of the line chart and hack it. >> >> > Not really looking to hack JavaFX classes to support basic functionality. > I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. > > > >> >>> - *Support for Swing components within JavaFX. * If the goal is to >>> replace Swing, then this is one of those essential capabilities >>> that >> needs >>> to be in place. The current examples only demonstrate how to put >> JavaFX >>> components within Swing applications. Unfortunately, if you want >>> to >> reuse >>> any existing components (like JFreeCharts for example) within >>> your >> project, >>> you're SOL at the moment. >> >> They is not going to be 100% free ride on this extra third party >> functionality. >> >> 1) Modify JFreeChart and port some of it or all of it to JavaFX >> 2) Hack the existing Chart package until it gets you 80/20 of what you >> want >> > > Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. > If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. > > When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. > > > >> >>> - *Support for an EventBus.* Currently, there's a lot of point2point >>> event code that you have to write to fire and listen to events. >>> It >> would >>> make for a much more useable codebase if you could simply publish and >>> subscribe to events at the application level. >> >> Why not write a JavaFX extension framework that maps JavaFX Event to a >> MessageBus implementation. >> > > I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. > > > > >> >>> - *Release the source.* It's a royal pain to have to download the >>> source through mercurial rather than simply read it as you do with the >>> Swing code or download it as you do with any Maven package. >>> >> >> The source code is there as JavaFX 2.2 as openjfx already. >> I think you meant make the source code also a downloadable distribution. >> > > Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. > > >> >> Hack the build.xml in the openjfx project, and contribute the Ant target. >> >> I also note that there should be a standalone JavaFX Doc as >> distribution >> > > Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. > > >> >> Ditto - hack the build.xml to javadoc and zip up the javadoc >> >> Contrib the patch back to the team >> >>> There's also some work that needs to be done to make it easier for >>> people to participate. I have 3 accounts at the moment: one for >>> this mailing list, one for the forums, and one for JIRA. Can we >>> just boil that down >> to >>> one, and let me login with Facebook or Google credentials? >>> >> >> Have you heard of the online services Google Onepass or LastPass or >> Yahoo Super wallet? > > > Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase > community participation. Most of what I've mentioned are items that > should lower those barriers to entry. > > > Mark > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From neugens.limasoftware at gmail.com Mon Oct 15 05:00:18 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 15 Oct 2012 14:00:18 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <193FF4ED343AF14F8CDC65B4792C954D13296353@Jeri.osys.ch> References: <193FF4ED343AF14F8CDC65B4792C954D13296353@Jeri.osys.ch> Message-ID: 2012/10/15 Claus Luethje : > I want to be working on mobile app based on JavaFX with my team. We have built skills (and still are) and interest, but how can we convince customers to invest in JavaFX? > I see JavaFX as a very efficient way to build GUIs; it's fast, versatile and fun. It could be a perfect match for RIA, but time-to-market is important and JavaFX isn't there yet. > Regards > Claus Hi Claus, I can share with you you my own experience on this. In the past, I've been part of a team who was delivering a stripped down j2se solution for the automotive market. It was a solution mostly targeting JavaTV/Xlet environments, the kind of things you find in high class cars today (with DVD readers and all the funny gadgets that I will never understand how people can ever use while driving :). Now, there are a number of good APIs that are part of this environment, most of the functionality of the most famous JSRs even found a way in some form into nowadays popular mobile platforms like Android and iOS (location services, OpenGL for mobile devices, camera services, etc...). This, however, wasn't enough. We then decided to port LWUIT to offer this framework as a base for the mobile UI work, since at the time LWUIT was only working on J2ME we wrote our own layer over the stripped down J2SE. The solution we were providing was not just about adding those tools and that's it, we were offering also all kind of frameworks to help integrate those things in a secure way (service on demand, class isolation, etc...) It was a good product in the end, because of this high level of integration, it offered a very good value added. Android and iOS are good choices because they offer this value added too, they have tools, good support and documentation, and lots of interesting APIs, and everything is well consolidated in a coherent environment. So the question you're asking "how can we convince customers to invest in JavaFX" is very simple to answer: help build this ecosystem around it and consolidate. The JavaFX community will take care of enabling this ecosystem, depending on the specific needs of the individuals, over multiple choices of platforms and operating systems, as soon as the whole thing goes Open Source, I'm very confident on this. Ultimately, the choice is yours, and it's most probably driven by current customers need, but in my opinion it's worth to build extra skills and code over this platform. [1] Cheers, Mario [1] Standard disclaimer apply: This is a personal opinion only, use at your own risk! I'm not affiliated in any way with Oracle, nor this opinion is necessarily shared by my employer or Oracle or anybody else, etc... -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From Claus.Luethje at osys.ch Mon Oct 15 05:06:24 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Mon, 15 Oct 2012 12:06:24 +0000 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <507BF963.6080404@bestsolution.at> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> Oh, I must have missed this info. In this case, let's hope JavaFX in soon pushed into the bootclasspath. Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl Sent: Montag, 15. Oktober 2012 13:54 To: openjfx-dev at openjdk.java.net Subject: Re: No JavaFX for iOS, Android or WP - why not? Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330) Tom Am 15.10.12 13:45, schrieb Claus Luethje: > +1 for the maven support > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark > Fortner > Sent: Mittwoch, 10. Oktober 2012 17:28 > To: openjfx-dev at openjdk.java.net > Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? > > Hi Peter, > > Comments below. > > >> I am preferring to use Gradle these days. Nevertheless the issue of >> putting JavaFX in a Maven Repository is an important. Because JavaFX >> is not pure Java, the problem with linking with native library is a >> major concern. >> >> Whatever JavaFX JAR you put in a artifact repository, whether >> SonaType or Artifactory there has to be way to guarantee the code in >> the JAR can always find the native libraries. Oracle have not come >> with a scheme. I do not know of a safe way to do this portably that >> is cross platform and work across all systems with causing a break if >> one or the other dependencies are upgraded. The version, the native >> library and the potential upgrades are the sticking problem. >> >> Then there is a licensing of the JavaFX Runtime and distribution of >> Oracle's implementation. >> > > Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version > of the Ant tasks would make deployment easier. A maven archetype for > creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. > > > >> >>> - *Webstart deployment *- this is still problematic. Currently >>> when >> you >>> push new artifacts to your web server, it's not replacing the >> existing JARs >>> in the user's cache -- despite what the documentation says. The >> "special" >>> javafx tags aren't documented well enough and presume that you're >> using the >>> Ant tools to generate the JNLP. And getting shaded jars is next to >>> impossible. >> >> I do not have an answer to this web start problem. I do assume you >> can upgrade Java 7. >> >> > > I'm currently running Java 7. > > > >> >>> - *Charts* - support for zooming and panning within the charts. >> Support >>> for drawing on top of charts. >> >> The controls and charts code is open source, go and implement your >> chart component. >> Start with a copy of the line chart and hack it. >> >> > Not really looking to hack JavaFX classes to support basic functionality. > I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. > > > >> >>> - *Support for Swing components within JavaFX. * If the goal is to >>> replace Swing, then this is one of those essential capabilities >>> that >> needs >>> to be in place. The current examples only demonstrate how to put >> JavaFX >>> components within Swing applications. Unfortunately, if you want >>> to >> reuse >>> any existing components (like JFreeCharts for example) within >>> your >> project, >>> you're SOL at the moment. >> >> They is not going to be 100% free ride on this extra third party >> functionality. >> >> 1) Modify JFreeChart and port some of it or all of it to JavaFX >> 2) Hack the existing Chart package until it gets you 80/20 of what >> you want >> > > Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. > If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. > > When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. > > > >> >>> - *Support for an EventBus.* Currently, there's a lot of point2point >>> event code that you have to write to fire and listen to events. >>> It >> would >>> make for a much more useable codebase if you could simply publish and >>> subscribe to events at the application level. >> >> Why not write a JavaFX extension framework that maps JavaFX Event to >> a MessageBus implementation. >> > > I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. > > > > >> >>> - *Release the source.* It's a royal pain to have to download the >>> source through mercurial rather than simply read it as you do with the >>> Swing code or download it as you do with any Maven package. >>> >> >> The source code is there as JavaFX 2.2 as openjfx already. >> I think you meant make the source code also a downloadable distribution. >> > > Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. > > >> >> Hack the build.xml in the openjfx project, and contribute the Ant target. >> >> I also note that there should be a standalone JavaFX Doc as >> distribution >> > > Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. > > >> >> Ditto - hack the build.xml to javadoc and zip up the javadoc >> >> Contrib the patch back to the team >> >>> There's also some work that needs to be done to make it easier for >>> people to participate. I have 3 accounts at the moment: one for >>> this mailing list, one for the forums, and one for JIRA. Can we >>> just boil that down >> to >>> one, and let me login with Facebook or Google credentials? >>> >> >> Have you heard of the online services Google Onepass or LastPass or >> Yahoo Super wallet? > > > Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase > community participation. Most of what I've mentioned are items that > should lower those barriers to entry. > > > Mark > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From zonski at gmail.com Mon Oct 15 05:39:39 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 15 Oct 2012 23:39:39 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> Message-ID: <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> Just for clarity, the bootclasspath addition will only solve the first part of the Maven issue, ie the jars will be available to *compile* against. For actual *packaging* for deployment, JFX has special ant tools, which creates bundles (for webstart, applet and native) and these bundles are quite magic so not trivial to assemble without the ant tools. As such these Ant tools would need to be ported (or wrapped by) a Maven plugin in order to have a clean JFX Maven build that is inline with what you would be accustomed to when building say a webapp with Maven. You could of course callout to the ant tasks but the build is far enough off a normal Maven build doing this that you'd likely be better off just using Ant (+ivy) as it would be simpler/cleaner. Or there's Gradle. If the bootclasspath thing happens it does at least partially resolve the long standing legal hurdles to Maven integration so the community *may* well be able to (finally) build this plugin. However I imagine the legal issue will still stand with regards to the Jars used by the packaging tools (as these likely won't be on the bootclasspath), which means the plugin probably legally won't be able to redistribute these tool jars making it harder to implement such a plugin. Any such Maven plugin and support will be the full responsibility of the community unless there was a change in current stance. The Oracle JFX team support ANT only, all other build platforms are left as an exercise for the reader. On 15/10/2012, at 11:06 PM, Claus Luethje wrote: > Oh, I must have missed this info. In this case, let's hope JavaFX in soon pushed into the bootclasspath. > Claus > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl > Sent: Montag, 15. Oktober 2012 13:54 > To: openjfx-dev at openjdk.java.net > Subject: Re: No JavaFX for iOS, Android or WP - why not? > > Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330) > > Tom > > Am 15.10.12 13:45, schrieb Claus Luethje: >> +1 for the maven support >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark >> Fortner >> Sent: Mittwoch, 10. Oktober 2012 17:28 >> To: openjfx-dev at openjdk.java.net >> Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? >> >> Hi Peter, >> >> Comments below. >> >> >>> I am preferring to use Gradle these days. Nevertheless the issue of >>> putting JavaFX in a Maven Repository is an important. Because JavaFX >>> is not pure Java, the problem with linking with native library is a >>> major concern. >>> >>> Whatever JavaFX JAR you put in a artifact repository, whether >>> SonaType or Artifactory there has to be way to guarantee the code in >>> the JAR can always find the native libraries. Oracle have not come >>> with a scheme. I do not know of a safe way to do this portably that >>> is cross platform and work across all systems with causing a break if >>> one or the other dependencies are upgraded. The version, the native >>> library and the potential upgrades are the sticking problem. >>> >>> Then there is a licensing of the JavaFX Runtime and distribution of >>> Oracle's implementation. >>> >> >> Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version >> of the Ant tasks would make deployment easier. A maven archetype for >> creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. >> >> >> >>> >>>> - *Webstart deployment *- this is still problematic. Currently >>>> when >>> you >>>> push new artifacts to your web server, it's not replacing the >>> existing JARs >>>> in the user's cache -- despite what the documentation says. The >>> "special" >>>> javafx tags aren't documented well enough and presume that you're >>> using the >>>> Ant tools to generate the JNLP. And getting shaded jars is next to >>>> impossible. >>> >>> I do not have an answer to this web start problem. I do assume you >>> can upgrade Java 7. >>> >>> >> >> I'm currently running Java 7. >> >> >> >>> >>>> - *Charts* - support for zooming and panning within the charts. >>> Support >>>> for drawing on top of charts. >>> >>> The controls and charts code is open source, go and implement your >>> chart component. >>> Start with a copy of the line chart and hack it. >>> >>> >> Not really looking to hack JavaFX classes to support basic functionality. >> I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. >> >> >> >>> >>>> - *Support for Swing components within JavaFX. * If the goal is to >>>> replace Swing, then this is one of those essential capabilities >>>> that >>> needs >>>> to be in place. The current examples only demonstrate how to put >>> JavaFX >>>> components within Swing applications. Unfortunately, if you want >>>> to >>> reuse >>>> any existing components (like JFreeCharts for example) within >>>> your >>> project, >>>> you're SOL at the moment. >>> >>> They is not going to be 100% free ride on this extra third party >>> functionality. >>> >>> 1) Modify JFreeChart and port some of it or all of it to JavaFX >>> 2) Hack the existing Chart package until it gets you 80/20 of what >>> you want >>> >> >> Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. >> If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. > >> >> When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. >> >> >> >>> >>>> - *Support for an EventBus.* Currently, there's a lot of point2point >>>> event code that you have to write to fire and listen to events. >>>> It >>> would >>>> make for a much more useable codebase if you could simply publish and >>>> subscribe to events at the application level. >>> >>> Why not write a JavaFX extension framework that maps JavaFX Event to >>> a MessageBus implementation. >>> >> >> I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. >> >> >> >> >>> >>>> - *Release the source.* It's a royal pain to have to download the >>>> source through mercurial rather than simply read it as you do with the >>>> Swing code or download it as you do with any Maven package. >>>> >>> >>> The source code is there as JavaFX 2.2 as openjfx already. >>> I think you meant make the source code also a downloadable distribution. >>> >> >> Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. >> >> >>> >>> Hack the build.xml in the openjfx project, and contribute the Ant target. >>> >>> I also note that there should be a standalone JavaFX Doc as >>> distribution >>> >> >> Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. >> >> >>> >>> Ditto - hack the build.xml to javadoc and zip up the javadoc >>> >>> Contrib the patch back to the team >>> >>>> There's also some work that needs to be done to make it easier for >>>> people to participate. I have 3 accounts at the moment: one for >>>> this mailing list, one for the forums, and one for JIRA. Can we >>>> just boil that down >>> to >>>> one, and let me login with Facebook or Google credentials? >>>> >>> >>> Have you heard of the online services Google Onepass or LastPass or >>> Yahoo Super wallet? >> >> >> Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase >> community participation. Most of what I've mentioned are items that >> should lower those barriers to entry. >> >> >> Mark >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Mon Oct 15 05:49:39 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 15 Oct 2012 14:49:39 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> Message-ID: <507C0663.2070606@bestsolution.at> [Please note I have no idea of all how maven works and how it does the classloading, ... .] Well if this stuff is found at a well defined place why does the plugin have to redistribute them? e.g. in e(fx)clipse I simply generate a ant-build script which uses the JDK-Location to find the fx-ant additions and the javafxrt.jar when compiling. Would the easiest thing for a maven build be that it generates an ant-file and then launches ant? Tom Am 15.10.12 14:39, schrieb Daniel Zwolenski: > Just for clarity, the bootclasspath addition will only solve the first part of the Maven issue, ie the jars will be available to *compile* against. > > For actual *packaging* for deployment, JFX has special ant tools, which creates bundles (for webstart, applet and native) and these bundles are quite magic so not trivial to assemble without the ant tools. As such these Ant tools would need to be ported (or wrapped by) a Maven plugin in order to have a clean JFX Maven build that is inline with what you would be accustomed to when building say a webapp with Maven. > > You could of course callout to the ant tasks but the build is far enough off a normal Maven build doing this that you'd likely be better off just using Ant (+ivy) as it would be simpler/cleaner. Or there's Gradle. > > If the bootclasspath thing happens it does at least partially resolve the long standing legal hurdles to Maven integration so the community *may* well be able to (finally) build this plugin. However I imagine the legal issue will still stand with regards to the Jars used by the packaging tools (as these likely won't be on the bootclasspath), which means the plugin probably legally won't be able to redistribute these tool jars making it harder to implement such a plugin. > > Any such Maven plugin and support will be the full responsibility of the community unless there was a change in current stance. The Oracle JFX team support ANT only, all other build platforms are left as an exercise for the reader. > > > > On 15/10/2012, at 11:06 PM, Claus Luethje wrote: > >> Oh, I must have missed this info. In this case, let's hope JavaFX in soon pushed into the bootclasspath. >> Claus >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl >> Sent: Montag, 15. Oktober 2012 13:54 >> To: openjfx-dev at openjdk.java.net >> Subject: Re: No JavaFX for iOS, Android or WP - why not? >> >> Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330) >> >> Tom >> >> Am 15.10.12 13:45, schrieb Claus Luethje: >>> +1 for the maven support >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark >>> Fortner >>> Sent: Mittwoch, 10. Oktober 2012 17:28 >>> To: openjfx-dev at openjdk.java.net >>> Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? >>> >>> Hi Peter, >>> >>> Comments below. >>> >>> >>>> I am preferring to use Gradle these days. Nevertheless the issue of >>>> putting JavaFX in a Maven Repository is an important. Because JavaFX >>>> is not pure Java, the problem with linking with native library is a >>>> major concern. >>>> >>>> Whatever JavaFX JAR you put in a artifact repository, whether >>>> SonaType or Artifactory there has to be way to guarantee the code in >>>> the JAR can always find the native libraries. Oracle have not come >>>> with a scheme. I do not know of a safe way to do this portably that >>>> is cross platform and work across all systems with causing a break if >>>> one or the other dependencies are upgraded. The version, the native >>>> library and the potential upgrades are the sticking problem. >>>> >>>> Then there is a licensing of the JavaFX Runtime and distribution of >>>> Oracle's implementation. >>>> >>> >>> Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version >>> of the Ant tasks would make deployment easier. A maven archetype for >>> creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. >>> >>> >>> >>>> >>>>> - *Webstart deployment *- this is still problematic. Currently >>>>> when >>>> you >>>>> push new artifacts to your web server, it's not replacing the >>>> existing JARs >>>>> in the user's cache -- despite what the documentation says. The >>>> "special" >>>>> javafx tags aren't documented well enough and presume that you're >>>> using the >>>>> Ant tools to generate the JNLP. And getting shaded jars is next to >>>>> impossible. >>>> >>>> I do not have an answer to this web start problem. I do assume you >>>> can upgrade Java 7. >>>> >>>> >>> >>> I'm currently running Java 7. >>> >>> >>> >>>> >>>>> - *Charts* - support for zooming and panning within the charts. >>>> Support >>>>> for drawing on top of charts. >>>> >>>> The controls and charts code is open source, go and implement your >>>> chart component. >>>> Start with a copy of the line chart and hack it. >>>> >>>> >>> Not really looking to hack JavaFX classes to support basic functionality. >>> I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. >>> >>> >>> >>>> >>>>> - *Support for Swing components within JavaFX. * If the goal is to >>>>> replace Swing, then this is one of those essential capabilities >>>>> that >>>> needs >>>>> to be in place. The current examples only demonstrate how to put >>>> JavaFX >>>>> components within Swing applications. Unfortunately, if you want >>>>> to >>>> reuse >>>>> any existing components (like JFreeCharts for example) within >>>>> your >>>> project, >>>>> you're SOL at the moment. >>>> >>>> They is not going to be 100% free ride on this extra third party >>>> functionality. >>>> >>>> 1) Modify JFreeChart and port some of it or all of it to JavaFX >>>> 2) Hack the existing Chart package until it gets you 80/20 of what >>>> you want >>>> >>> >>> Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. >>> If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. >> >>> >>> When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. >>> >>> >>> >>>> >>>>> - *Support for an EventBus.* Currently, there's a lot of point2point >>>>> event code that you have to write to fire and listen to events. >>>>> It >>>> would >>>>> make for a much more useable codebase if you could simply publish and >>>>> subscribe to events at the application level. >>>> >>>> Why not write a JavaFX extension framework that maps JavaFX Event to >>>> a MessageBus implementation. >>>> >>> >>> I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. >>> >>> >>> >>> >>>> >>>>> - *Release the source.* It's a royal pain to have to download the >>>>> source through mercurial rather than simply read it as you do with the >>>>> Swing code or download it as you do with any Maven package. >>>>> >>>> >>>> The source code is there as JavaFX 2.2 as openjfx already. >>>> I think you meant make the source code also a downloadable distribution. >>>> >>> >>> Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. >>> >>> >>>> >>>> Hack the build.xml in the openjfx project, and contribute the Ant target. >>>> >>>> I also note that there should be a standalone JavaFX Doc as >>>> distribution >>>> >>> >>> Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. >>> >>> >>>> >>>> Ditto - hack the build.xml to javadoc and zip up the javadoc >>>> >>>> Contrib the patch back to the team >>>> >>>>> There's also some work that needs to be done to make it easier for >>>>> people to participate. I have 3 accounts at the moment: one for >>>>> this mailing list, one for the forums, and one for JIRA. Can we >>>>> just boil that down >>>> to >>>>> one, and let me login with Facebook or Google credentials? >>>>> >>>> >>>> Have you heard of the online services Google Onepass or LastPass or >>>> Yahoo Super wallet? >>> >>> >>> Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase >>> community participation. Most of what I've mentioned are items that >>> should lower those barriers to entry. >>> >>> >>> Mark >>> >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From zonski at gmail.com Mon Oct 15 06:59:27 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 16 Oct 2012 00:59:27 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <507C0663.2070606@bestsolution.at> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <507C0663.2070606@bestsolution.at> Message-ID: On 15/10/2012, at 11:49 PM, Tom Schindl wrote: > [Please note I have no idea of all how maven works and how it does the > classloading, ... .] > > Well if this stuff is found at a well defined place why does the plugin > have to redistribute them? > > e.g. in e(fx)clipse I simply generate a ant-build script which uses the > JDK-Location to find the fx-ant additions and the javafxrt.jar when > compiling. Yes this an option. If someone wants to build this plugin they will likely want to go down that road if they can't legally bundle the tools in their own code. This isn't an option for the actual rt.jar though as you can't hijack the compile path in the same way as you can the assembly tool path. Ie this will only be a practical option after the rt is on the bootclasspath as originally discussed. Which is why this plugin hasn't been written by the community yet - waiting on oracle. > > Would the easiest thing for a maven build be that it generates an > ant-file and then launches ant? No, Maven can call ant tasks so there is no need to generate an ant file. Maven users would not be overly happy with doing this though. Maven uses convention, ant uses configuration. Maven users will not be happy configuring a whole lot of ant tasks. The plugin would work out all the ant settings from the structure of the project. A maven user would expect to setup a build for their maven project by simply specifying the plugin reference and one or two lines of config (eg jnlp vs applet). The rest would all just happen magically. It's all pretty moot at this stage till the bootclasspath issue is fixed anyway. I was just pointing out that there would be more work and more challenges after this, whereas I think there might be a conception that this will be resolved (several maven requests were already marked incorrectly as resolved even before the bootclasspath fix has been done). Maven users won't be super impressed about having to manually install something like wix to do native builds too. Maven users are spoilt and used to most things just magically happening. This one would probably rate as just an annoyance though whereas the lack of plugin above would be a real deterrent for most. > > Tom > > Am 15.10.12 14:39, schrieb Daniel Zwolenski: >> Just for clarity, the bootclasspath addition will only solve the first part of the Maven issue, ie the jars will be available to *compile* against. >> >> For actual *packaging* for deployment, JFX has special ant tools, which creates bundles (for webstart, applet and native) and these bundles are quite magic so not trivial to assemble without the ant tools. As such these Ant tools would need to be ported (or wrapped by) a Maven plugin in order to have a clean JFX Maven build that is inline with what you would be accustomed to when building say a webapp with Maven. >> >> You could of course callout to the ant tasks but the build is far enough off a normal Maven build doing this that you'd likely be better off just using Ant (+ivy) as it would be simpler/cleaner. Or there's Gradle. >> >> If the bootclasspath thing happens it does at least partially resolve the long standing legal hurdles to Maven integration so the community *may* well be able to (finally) build this plugin. However I imagine the legal issue will still stand with regards to the Jars used by the packaging tools (as these likely won't be on the bootclasspath), which means the plugin probably legally won't be able to redistribute these tool jars making it harder to implement such a plugin. >> >> Any such Maven plugin and support will be the full responsibility of the community unless there was a change in current stance. The Oracle JFX team support ANT only, all other build platforms are left as an exercise for the reader. >> >> >> >> On 15/10/2012, at 11:06 PM, Claus Luethje wrote: >> >>> Oh, I must have missed this info. In this case, let's hope JavaFX in soon pushed into the bootclasspath. >>> Claus >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl >>> Sent: Montag, 15. Oktober 2012 13:54 >>> To: openjfx-dev at openjdk.java.net >>> Subject: Re: No JavaFX for iOS, Android or WP - why not? >>> >>> Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330) >>> >>> Tom >>> >>> Am 15.10.12 13:45, schrieb Claus Luethje: >>>> +1 for the maven support >>>> >>>> -----Original Message----- >>>> From: openjfx-dev-bounces at openjdk.java.net >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark >>>> Fortner >>>> Sent: Mittwoch, 10. Oktober 2012 17:28 >>>> To: openjfx-dev at openjdk.java.net >>>> Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? >>>> >>>> Hi Peter, >>>> >>>> Comments below. >>>> >>>> >>>>> I am preferring to use Gradle these days. Nevertheless the issue of >>>>> putting JavaFX in a Maven Repository is an important. Because JavaFX >>>>> is not pure Java, the problem with linking with native library is a >>>>> major concern. >>>>> >>>>> Whatever JavaFX JAR you put in a artifact repository, whether >>>>> SonaType or Artifactory there has to be way to guarantee the code in >>>>> the JAR can always find the native libraries. Oracle have not come >>>>> with a scheme. I do not know of a safe way to do this portably that >>>>> is cross platform and work across all systems with causing a break if >>>>> one or the other dependencies are upgraded. The version, the native >>>>> library and the potential upgrades are the sticking problem. >>>>> >>>>> Then there is a licensing of the JavaFX Runtime and distribution of >>>>> Oracle's implementation. >>>>> >>>> >>>> Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version >>>> of the Ant tasks would make deployment easier. A maven archetype for >>>> creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. >>>> >>>> >>>> >>>>> >>>>>> - *Webstart deployment *- this is still problematic. Currently >>>>>> when >>>>> you >>>>>> push new artifacts to your web server, it's not replacing the >>>>> existing JARs >>>>>> in the user's cache -- despite what the documentation says. The >>>>> "special" >>>>>> javafx tags aren't documented well enough and presume that you're >>>>> using the >>>>>> Ant tools to generate the JNLP. And getting shaded jars is next to >>>>>> impossible. >>>>> >>>>> I do not have an answer to this web start problem. I do assume you >>>>> can upgrade Java 7. >>>>> >>>>> >>>> >>>> I'm currently running Java 7. >>>> >>>> >>>> >>>>> >>>>>> - *Charts* - support for zooming and panning within the charts. >>>>> Support >>>>>> for drawing on top of charts. >>>>> >>>>> The controls and charts code is open source, go and implement your >>>>> chart component. >>>>> Start with a copy of the line chart and hack it. >>>>> >>>>> >>>> Not really looking to hack JavaFX classes to support basic functionality. >>>> I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. >>>> >>>> >>>> >>>>> >>>>>> - *Support for Swing components within JavaFX. * If the goal is to >>>>>> replace Swing, then this is one of those essential capabilities >>>>>> that >>>>> needs >>>>>> to be in place. The current examples only demonstrate how to put >>>>> JavaFX >>>>>> components within Swing applications. Unfortunately, if you want >>>>>> to >>>>> reuse >>>>>> any existing components (like JFreeCharts for example) within >>>>>> your >>>>> project, >>>>>> you're SOL at the moment. >>>>> >>>>> They is not going to be 100% free ride on this extra third party >>>>> functionality. >>>>> >>>>> 1) Modify JFreeChart and port some of it or all of it to JavaFX >>>>> 2) Hack the existing Chart package until it gets you 80/20 of what >>>>> you want >>>>> >>>> >>>> Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. >>>> If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. >>> >>>> >>>> When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. >>>> >>>> >>>> >>>>> >>>>>> - *Support for an EventBus.* Currently, there's a lot of point2point >>>>>> event code that you have to write to fire and listen to events. >>>>>> It >>>>> would >>>>>> make for a much more useable codebase if you could simply publish and >>>>>> subscribe to events at the application level. >>>>> >>>>> Why not write a JavaFX extension framework that maps JavaFX Event to >>>>> a MessageBus implementation. >>>>> >>>> >>>> I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. >>>> >>>> >>>> >>>> >>>>> >>>>>> - *Release the source.* It's a royal pain to have to download the >>>>>> source through mercurial rather than simply read it as you do with the >>>>>> Swing code or download it as you do with any Maven package. >>>>>> >>>>> >>>>> The source code is there as JavaFX 2.2 as openjfx already. >>>>> I think you meant make the source code also a downloadable distribution. >>>>> >>>> >>>> Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. >>>> >>>> >>>>> >>>>> Hack the build.xml in the openjfx project, and contribute the Ant target. >>>>> >>>>> I also note that there should be a standalone JavaFX Doc as >>>>> distribution >>>>> >>>> >>>> Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. >>>> >>>> >>>>> >>>>> Ditto - hack the build.xml to javadoc and zip up the javadoc >>>>> >>>>> Contrib the patch back to the team >>>>> >>>>>> There's also some work that needs to be done to make it easier for >>>>>> people to participate. I have 3 accounts at the moment: one for >>>>>> this mailing list, one for the forums, and one for JIRA. Can we >>>>>> just boil that down >>>>> to >>>>>> one, and let me login with Facebook or Google credentials? >>>>>> >>>>> >>>>> Have you heard of the online services Google Onepass or LastPass or >>>>> Yahoo Super wallet? >>>> >>>> >>>> Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase >>>> community participation. Most of what I've mentioned are items that >>>> should lower those barriers to entry. >>>> >>>> >>>> Mark >>>> >>> >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From swpalmer at gmail.com Mon Oct 15 11:03:23 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 15 Oct 2012 14:03:23 -0400 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> Message-ID: <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> The bootclasspath will solve all issues for me, as I'm not using or interested in the magic packaging for deployment. I have to make a custom installer anyway, no magic installer will install all the rest of my non-java dependencies. Though I am using WiX, I don't expect there is any hook to provide my own WiX source files to customize the automatically generated installer. So far we have used some hackery to force the JFX runtime onto the classpath and put a copy of the JFX runtime into our local Maven repo to shut it up. It does some ugly reflection things (setAccessible(true)) but it works. I think it is okay to defer the Maven plugin, as Maven's ability to package up a standard .jar file should be enough make a working JavaFX application. The ability to run the jfxpackager from the command line (with it's new abilities) allows for access to some of the fancier features just be using Maven's exec plugin. The classpath issue is the big blocker. Scott On 2012-10-15, at 8:39 AM, Daniel Zwolenski wrote: > Just for clarity, the bootclasspath addition will only solve the first part of the Maven issue, ie the jars will be available to *compile* against. > > For actual *packaging* for deployment, JFX has special ant tools, which creates bundles (for webstart, applet and native) and these bundles are quite magic so not trivial to assemble without the ant tools. As such these Ant tools would need to be ported (or wrapped by) a Maven plugin in order to have a clean JFX Maven build that is inline with what you would be accustomed to when building say a webapp with Maven. > > You could of course callout to the ant tasks but the build is far enough off a normal Maven build doing this that you'd likely be better off just using Ant (+ivy) as it would be simpler/cleaner. Or there's Gradle. > > If the bootclasspath thing happens it does at least partially resolve the long standing legal hurdles to Maven integration so the community *may* well be able to (finally) build this plugin. However I imagine the legal issue will still stand with regards to the Jars used by the packaging tools (as these likely won't be on the bootclasspath), which means the plugin probably legally won't be able to redistribute these tool jars making it harder to implement such a plugin. > > Any such Maven plugin and support will be the full responsibility of the community unless there was a change in current stance. The Oracle JFX team support ANT only, all other build platforms are left as an exercise for the reader. > > > > On 15/10/2012, at 11:06 PM, Claus Luethje wrote: > >> Oh, I must have missed this info. In this case, let's hope JavaFX in soon pushed into the bootclasspath. >> Claus >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl >> Sent: Montag, 15. Oktober 2012 13:54 >> To: openjfx-dev at openjdk.java.net >> Subject: Re: No JavaFX for iOS, Android or WP - why not? >> >> Well once javafx is on the bootclasspath this doesn't make any sense so time is better invested in pushing into the bootclasspath in 7u something which is the last info I got from Kevin (See >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166330) >> >> Tom >> >> Am 15.10.12 13:45, schrieb Claus Luethje: >>> +1 for the maven support >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark >>> Fortner >>> Sent: Mittwoch, 10. Oktober 2012 17:28 >>> To: openjfx-dev at openjdk.java.net >>> Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not? >>> >>> Hi Peter, >>> >>> Comments below. >>> >>> >>>> I am preferring to use Gradle these days. Nevertheless the issue of >>>> putting JavaFX in a Maven Repository is an important. Because JavaFX >>>> is not pure Java, the problem with linking with native library is a >>>> major concern. >>>> >>>> Whatever JavaFX JAR you put in a artifact repository, whether >>>> SonaType or Artifactory there has to be way to guarantee the code in >>>> the JAR can always find the native libraries. Oracle have not come >>>> with a scheme. I do not know of a safe way to do this portably that >>>> is cross platform and work across all systems with causing a break if >>>> one or the other dependencies are upgraded. The version, the native >>>> library and the potential upgrades are the sticking problem. >>>> >>>> Then there is a licensing of the JavaFX Runtime and distribution of >>>> Oracle's implementation. >>>> >>> >>> Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version >>> of the Ant tasks would make deployment easier. A maven archetype for >>> creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application. >>> >>> >>> >>>> >>>>> - *Webstart deployment *- this is still problematic. Currently >>>>> when >>>> you >>>>> push new artifacts to your web server, it's not replacing the >>>> existing JARs >>>>> in the user's cache -- despite what the documentation says. The >>>> "special" >>>>> javafx tags aren't documented well enough and presume that you're >>>> using the >>>>> Ant tools to generate the JNLP. And getting shaded jars is next to >>>>> impossible. >>>> >>>> I do not have an answer to this web start problem. I do assume you >>>> can upgrade Java 7. >>>> >>>> >>> >>> I'm currently running Java 7. >>> >>> >>> >>>> >>>>> - *Charts* - support for zooming and panning within the charts. >>>> Support >>>>> for drawing on top of charts. >>>> >>>> The controls and charts code is open source, go and implement your >>>> chart component. >>>> Start with a copy of the line chart and hack it. >>>> >>>> >>> Not really looking to hack JavaFX classes to support basic functionality. >>> I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand. >>> >>> >>> >>>> >>>>> - *Support for Swing components within JavaFX. * If the goal is to >>>>> replace Swing, then this is one of those essential capabilities >>>>> that >>>> needs >>>>> to be in place. The current examples only demonstrate how to put >>>> JavaFX >>>>> components within Swing applications. Unfortunately, if you want >>>>> to >>>> reuse >>>>> any existing components (like JFreeCharts for example) within >>>>> your >>>> project, >>>>> you're SOL at the moment. >>>> >>>> They is not going to be 100% free ride on this extra third party >>>> functionality. >>>> >>>> 1) Modify JFreeChart and port some of it or all of it to JavaFX >>>> 2) Hack the existing Chart package until it gets you 80/20 of what >>>> you want >>>> >>> >>> Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over. >>> If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base. >> >>> >>> When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in. >>> >>> >>> >>>> >>>>> - *Support for an EventBus.* Currently, there's a lot of point2point >>>>> event code that you have to write to fire and listen to events. >>>>> It >>>> would >>>>> make for a much more useable codebase if you could simply publish and >>>>> subscribe to events at the application level. >>>> >>>> Why not write a JavaFX extension framework that maps JavaFX Event to >>>> a MessageBus implementation. >>>> >>> >>> I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners. >>> >>> >>> >>> >>>> >>>>> - *Release the source.* It's a royal pain to have to download the >>>>> source through mercurial rather than simply read it as you do with the >>>>> Swing code or download it as you do with any Maven package. >>>>> >>>> >>>> The source code is there as JavaFX 2.2 as openjfx already. >>>> I think you meant make the source code also a downloadable distribution. >>>> >>> >>> Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included. >>> >>> >>>> >>>> Hack the build.xml in the openjfx project, and contribute the Ant target. >>>> >>>> I also note that there should be a standalone JavaFX Doc as >>>> distribution >>>> >>> >>> Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free. >>> >>> >>>> >>>> Ditto - hack the build.xml to javadoc and zip up the javadoc >>>> >>>> Contrib the patch back to the team >>>> >>>>> There's also some work that needs to be done to make it easier for >>>>> people to participate. I have 3 accounts at the moment: one for >>>>> this mailing list, one for the forums, and one for JIRA. Can we >>>>> just boil that down >>>> to >>>>> one, and let me login with Facebook or Google credentials? >>>>> >>>> >>>> Have you heard of the online services Google Onepass or LastPass or >>>> Yahoo Super wallet? >>> >>> >>> Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase >>> community participation. Most of what I've mentioned are items that >>> should lower those barriers to entry. >>> >>> >>> Mark >>> >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 From igor.nekrestyanov at oracle.com Mon Oct 15 11:20:27 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 15 Oct 2012 11:20:27 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> Message-ID: <507C53EB.7020006@oracle.com> > Though I am using WiX, I don't expect there is any hook to provide my own WiX source files to customize the automatically generated installer. You can certainly overwrite wix config file with custom version. See http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGICFDB -igor From mp at jugs.org Mon Oct 15 11:29:25 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Mon, 15 Oct 2012 20:29:25 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <507C53EB.7020006@oracle.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> Message-ID: <507C5605.8000502@jugs.org> Aren't we drifting away a little bit from the original topic of this thread :-? Am 15.10.2012 20:20, schrieb Igor Nekrestyanov: > > Though I am using WiX, I don't expect there is any hook to provide > my own WiX source files to customize the automatically generated > installer. > > You can certainly overwrite wix config file with custom version. See > http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGICFDB > > -igor > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From zonski at gmail.com Mon Oct 15 13:11:31 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 16 Oct 2012 07:11:31 +1100 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <507C5605.8000502@jugs.org> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> Message-ID: <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> Yea, we should have changed the subject, my bad. On the other hand the original conversation has continued slightly at: https://forums.oracle.com/forums/message.jspa?messageID=10633435#10633435 But nothing new really from oracle on supporting either the mobile or the webapp spaces. On 16/10/2012, at 5:29 AM, "Dr. Michael Paus" wrote: > Aren't we drifting away a little bit from the original topic of this thread :-? > > Am 15.10.2012 20:20, schrieb Igor Nekrestyanov: >> > Though I am using WiX, I don't expect there is any hook to provide my own WiX source files to customize the automatically generated installer. >> >> You can certainly overwrite wix config file with custom version. See >> http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGICFDB >> >> -igor >> > > > -- > -------------------------------------------------------------------------------------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > From phidias51 at gmail.com Mon Oct 15 13:55:02 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 15 Oct 2012 13:55:02 -0700 Subject: Maven support Message-ID: There have been several discussions in the past six months about Maven support in JavaFX and I wanted to re-open the topic and perhaps get a comprehensive and current must-have list before filing an issue on it. Here's my list: - Create a Maven archetype to generate a JavaFX project skeleton. The archetype would: - Generate the appropriate folder structure including a folder for distribution resources like the splashscreen. - Generate a POM file with the appropriate dependencies. - Generate Maven goals for creating: - JNLP - Double-clickable JAR - Windows executable - Linux RPM and Deb files http://mojo.codehaus.org/rpm-maven-plugin/, http://mojo.codehaus.org/deb-maven-plugin/ - Mac DMG file: http://mojo.codehaus.org/osxappbundle-maven-plugin/ - Handle signing of the JARs (including dependencies). - Generate the source, and javadoc artifacts and install them in a public repository. Even though the JavaFX binaries are being distributed, the source and the JavaDoc are not, which makes debugging a pain. The POM should have no native dependencies. Development shops typically have a build machine (usually Linux) that runs automated builds, and the machine should be able to build any platform-specific executable. The POM shouldn't rely on Ant calls. The Maven plugin should be self-contained and easily configurable. Once the basics are sorted out, it would be good to re-examine how developing JavaFX apps could be made even easier with Maven. For example, it might be nice to autogenerate these "Observable" POJOs from POJOs that already exist and are being used on the server. Imagine having the JavaFX version of Spring ROO or Grails where the forms and controllers you need are automatically generated. This would make it easier the prospect of transitioning to a new toolkit less daunting, and make it possible to build on the infrastructure and services that you already have in place. Mark From david.dehaven at oracle.com Mon Oct 15 14:20:23 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 15 Oct 2012 14:20:23 -0700 Subject: Proposed changes to media Track and children Message-ID: To support multi-track movies (primarily for alternate languages and subtitles/captioning), we need to make some changes to the existing public media API. Other changes will be discussed separately... I have two (and a half) options at the moment and I thought I'd throw it out to you guys to help decide which direction to go. Option 1> Make the following changes to Track and it's subclasses: Changes to Track: - Add public final Locale getLocale(), returns a Locale if one is provided by the container or null if not - Add public final long getTrackId(), returns a unique numeric track ID that will be used by the stack to identify this specific track - Add public final Map getMetadata(), returns any metadata specific to this Track (returned Map is an UnmodifiableMap for security) Changes to AudioTrack: - getLanguage(): deprecate, "use Track.getLocale() instead." Which is all that method does now anyways. Option 2> - Deprecate Track, AudioTrack, VideoTrack and the Media.tracks property - Add a "tracks" value to the Media metadata Map (retrieved by Media.getMetadata()). This would essentially be a Map>. The outer Map would contain one entry per track, keyed to the tracks unique ID (what would be returned by getTrackID() above) and it's Map would be the metadata associated with that track, including all the fields currently contained in the Track classes. Option 1.5, a compromise between Option 1 and Option 2> - Deprecate AudioTrack and VideoTrack, leave Track and Media.tracks property - Add a track type property (yet another enum?) and reflect the type in the track metadata (textually, using names like "video" and "audio") - Include the other changes to Track in option 1 - The properties of Audio/VideoTrack would be accessed from the track metadata Reasoning (read: my lousy attempt at kicking off a discussion): The Track classes are pure metadata (I've no intention of ever changing that?) and at the moment we have kind of a duality of metadata representation for Media, provided as a Map via the Media metadata property and also represented by an assortment of properties in Media and the Track classes. Option 1 basically sticks with the current split model, extending it to allow more flexibility moving forward. Of particular importance is the unique track ID which will be required to select which tracks are active in the future. Option 2 reduces classes in the API and treats tracks purely as metadata, but it also ends up embedding Maps three levels deep which seems a bit ugly to me. Option 1.5 is a bit of a compromise between the two, leaving the tracks property that can be listened to (which is handy for UI purposes and might be handy for streaming, if it's supported) but still moving information into a metadata table instead of cluttering the classes up with a bunch of properties for data that may or may not exist. I've opened a JIRA issue to track this: http://javafx-jira.kenai.com/browse/RT-25678 -DrD- From zonski at gmail.com Mon Oct 15 15:29:53 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 16 Oct 2012 09:29:53 +1100 Subject: Maven support In-Reply-To: References: Message-ID: Hi Mark, You have summed up the Maven requirements perfectly. A few comments inline below. On Tue, Oct 16, 2012 at 7:55 AM, Mark Fortner wrote: > There have been several discussions in the past six months about Maven > support in JavaFX and I wanted to re-open the topic and perhaps get a > comprehensive and current must-have list before filing an issue on it. > Great to have this comprehensive list, however be aware that numerous issues exist in JIRA already (search for Maven) and there have been several energetic attempts to get some movement here. Several of the issues have been closed previously by the JFX team with some key ones as "Won't fix". In general the Oracle guys are officially "hands off" on Maven (and all non-ANT build tools). On the flip side the community has been unable to progress this because of some of the issues. You will likely find that the Maven+JFX advocates have either given up or are waiting for true co-bundling or total open sourcing before doing anything further. > Here's my list: > > - Create a Maven archetype to generate a JavaFX project skeleton. The > archetype would: > - Generate the appropriate folder structure including a folder for > distribution resources like the splashscreen. > - Generate a POM file with the appropriate dependencies. > - Generate Maven goals for creating: > - JNLP > - Double-clickable JAR > - Windows executable > - Linux RPM and Deb files > http://mojo.codehaus.org/rpm-maven-plugin/, > http://mojo.codehaus.org/deb-maven-plugin/ > - Mac DMG file: > http://mojo.codehaus.org/osxappbundle-maven-plugin/ > - Handle signing of the JARs (including dependencies). > Yes to all. For those not used to Maven, this is effectively the 'plugin' side of it that I was talking about in my previous email. i.e. the bit that needs doing *after* the bootclasspath issue is finally resolved. - Generate the source, and javadoc artifacts and install them in a > public repository. Even though the JavaFX binaries are being > distributed, > the source and the JavaDoc are not, which makes debugging a pain. > There may be some Issues with version management on this one (i.e. the Maven plugin having a different version to the runtime). Since JFX is "part of Java" (or trying to be), JFX should do whatever Java does in this space in my opinion. > The POM should have no native dependencies. Development shops typically > have a build machine (usually Linux) that runs automated builds, and the > machine should be able to build any platform-specific executable. > This is definitely the ideal, and one of the major drawbacks/show-stoppers to cross-platform JFX at the moment (i.e. the current native build process is only slightly better than say a C++ native build). This issue applies equally to the ANT tasks. I created this issue a while ago: http://javafx-jira.kenai.com/browse/RT-22994 This is currently not possible for native installers. Some very major work would need to be done on the way the native builds work and there's not been any public discussions indicating this is something the JFX team is looking into. > The POM shouldn't rely on Ant calls. The Maven plugin should be > self-contained and easily configurable. > I started work on this plugin (maybe a year ago or so). The ANT tasks call onto the 'packager' library and the Maven plugin could/should do the same. The packager code is quite clean and abstracted away from ANT. There is definitely no *technical* need for either the developer or the plugin to call out to ANT as an intermediary. The actual implementation of the plugin is actually quite straight forward (though time consuming). I abandoned my plugin development due to two hurdles: 1) Oracle legal restrictions against putting the JARs in a public repo and 2) The native DLL loading of JFX is not Maven friendly (so even if you put the JARs in yourself it's still very messy) There was no movement from Oracle in addressing either of the above. The move to co-bundling (which will only be complete when the bootclasspath issue is resolved) will render both of these issues irrelevant so Maven+JFX users have been waiting (and waiting) for this before doing anything further on it. > Once the basics are sorted out, it would be good to re-examine how > developing JavaFX apps could be made even easier with Maven. For example, it might be nice to autogenerate these "Observable" POJOs from POJOs that > already exist and are being used on the server. Imagine having the JavaFX > version of Spring ROO or Grails where the forms and controllers you need > are automatically generated. This would make it easier the prospect of > transitioning to a new toolkit less daunting, and make it possible to build > on the infrastructure and services that you already have in place. Some RAD tools would be awesome. I don't think this is Maven's space though but definitely within the ROO and Grails space. SceneBuilder is the 'RAD' tool of the JFX platform but it is basically an FXML WYSIWYG editor. All of the above would aid adoption of JFX but all of the above has been discussed at length before without much actual progress. From swpalmer at gmail.com Mon Oct 15 15:31:00 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 15 Oct 2012 18:31:00 -0400 Subject: Proposed changes to media Track and children In-Reply-To: References: Message-ID: <2466471E-6DF6-4C52-8CC8-CDBCB7C40CED@gmail.com> I think I like option 1. Do you need to make a new method to get the locale or can it simply be included as metadata in the map? Scott On 2012-10-15, at 5:20 PM, David DeHaven wrote: > > To support multi-track movies (primarily for alternate languages and subtitles/captioning), we need to make some changes to the existing public media API. Other changes will be discussed separately... > > I have two (and a half) options at the moment and I thought I'd throw it out to you guys to help decide which direction to go. > > Option 1> > Make the following changes to Track and it's subclasses: > Changes to Track: > - Add public final Locale getLocale(), returns a Locale if one is provided by the container or null if not > - Add public final long getTrackId(), returns a unique numeric track ID that will be used by the stack to identify this specific track > - Add public final Map getMetadata(), returns any metadata specific to this Track (returned Map is an UnmodifiableMap for security) > > Changes to AudioTrack: > - getLanguage(): deprecate, "use Track.getLocale() instead." Which is all that method does now anyways. > > > Option 2> > - Deprecate Track, AudioTrack, VideoTrack and the Media.tracks property > - Add a "tracks" value to the Media metadata Map (retrieved by Media.getMetadata()). This would essentially be a Map>. The outer Map would contain one entry per track, keyed to the tracks unique ID (what would be returned by getTrackID() above) and it's Map would be the metadata associated with that track, including all the fields currently contained in the Track classes. > > > Option 1.5, a compromise between Option 1 and Option 2> > - Deprecate AudioTrack and VideoTrack, leave Track and Media.tracks property > - Add a track type property (yet another enum?) and reflect the type in the track metadata (textually, using names like "video" and "audio") > - Include the other changes to Track in option 1 > - The properties of Audio/VideoTrack would be accessed from the track metadata > > > Reasoning (read: my lousy attempt at kicking off a discussion): > > The Track classes are pure metadata (I've no intention of ever changing that?) and at the moment we have kind of a duality of metadata representation for Media, provided as a Map via the Media metadata property and also represented by an assortment of properties in Media and the Track classes. Option 1 basically sticks with the current split model, extending it to allow more flexibility moving forward. Of particular importance is the unique track ID which will be required to select which tracks are active in the future. Option 2 reduces classes in the API and treats tracks purely as metadata, but it also ends up embedding Maps three levels deep which seems a bit ugly to me. Option 1.5 is a bit of a compromise between the two, leaving the tracks property that can be listened to (which is handy for UI purposes and might be handy for streaming, if it's supported) but still moving information into a metadata table instead of cluttering the classes up with a bunch of properties for data that may or may not exist. > > > I've opened a JIRA issue to track this: > http://javafx-jira.kenai.com/browse/RT-25678 > > -DrD- > From phidias51 at gmail.com Mon Oct 15 15:39:57 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 15 Oct 2012 15:39:57 -0700 Subject: Maven support In-Reply-To: References: Message-ID: Hi Dan, Along the lines of "things that I'd like to see, but not necessarily Maven related", it would be really useful if data and service binding were easier/possible. I'd like to be able to click on a combobox and point to the JSON service that supplies the data for the combobox. And then point the onSelect event handler to the service responsible for persisting the selection. When Rave came out this was one of the features that really caught developers eyes and made them reconsider JSF. Admittedly people have backtracked on that decision, but it's definitely something that would speed up the development process. Cheers, Mark On Mon, Oct 15, 2012 at 3:29 PM, Daniel Zwolenski wrote: > Hi Mark, > > You have summed up the Maven requirements perfectly. A few comments inline > below. > > On Tue, Oct 16, 2012 at 7:55 AM, Mark Fortner wrote: > >> There have been several discussions in the past six months about Maven >> support in JavaFX and I wanted to re-open the topic and perhaps get a >> comprehensive and current must-have list before filing an issue on it. >> > > Great to have this comprehensive list, however be aware that numerous > issues exist in JIRA already (search for Maven) and there have been several > energetic attempts to get some movement here. Several of the issues have > been closed previously by the JFX team with some key ones as "Won't fix". > > In general the Oracle guys are officially "hands off" on Maven (and all > non-ANT build tools). On the flip side the community has been unable to > progress this because of some of the issues. You will likely find that the > Maven+JFX advocates have either given up or are waiting for true > co-bundling or total open sourcing before doing anything further. > > > >> Here's my list: >> >> - Create a Maven archetype to generate a JavaFX project skeleton. The >> archetype would: >> - Generate the appropriate folder structure including a folder for >> >> distribution resources like the splashscreen. >> - Generate a POM file with the appropriate dependencies. >> - Generate Maven goals for creating: >> - JNLP >> - Double-clickable JAR >> - Windows executable >> - Linux RPM and Deb files >> http://mojo.codehaus.org/rpm-maven-plugin/, >> http://mojo.codehaus.org/deb-maven-plugin/ >> - Mac DMG file: >> http://mojo.codehaus.org/osxappbundle-maven-plugin/ >> - Handle signing of the JARs (including dependencies). >> > > Yes to all. > > For those not used to Maven, this is effectively the 'plugin' side of it > that I was talking about in my previous email. i.e. the bit that needs > doing *after* the bootclasspath issue is finally resolved. > > - Generate the source, and javadoc artifacts and install them in a >> >> public repository. Even though the JavaFX binaries are being >> distributed, >> the source and the JavaDoc are not, which makes debugging a pain. >> > > There may be some Issues with version management on this one (i.e. the > Maven plugin having a different version to the runtime). > > Since JFX is "part of Java" (or trying to be), JFX should do whatever Java > does in this space in my opinion. > > >> The POM should have no native dependencies. Development shops typically >> have a build machine (usually Linux) that runs automated builds, and the >> machine should be able to build any platform-specific executable. >> > > This is definitely the ideal, and one of the major drawbacks/show-stoppers > to cross-platform JFX at the moment (i.e. the current native build process > is only slightly better than say a C++ native build). > > This issue applies equally to the ANT tasks. I created this issue a while > ago: http://javafx-jira.kenai.com/browse/RT-22994 > > This is currently not possible for native installers. Some very major work > would need to be done on the way the native builds work and there's not > been any public discussions indicating this is something the JFX team is > looking into. > > > >> The POM shouldn't rely on Ant calls. The Maven plugin should be >> self-contained and easily configurable. >> > > I started work on this plugin (maybe a year ago or so). The ANT tasks call > onto the 'packager' library and the Maven plugin could/should do the same. > The packager code is quite clean and abstracted away from ANT. There is > definitely no *technical* need for either the developer or the plugin to > call out to ANT as an intermediary. > > The actual implementation of the plugin is actually quite straight forward > (though time consuming). I abandoned my plugin development due to two > hurdles: > > 1) Oracle legal restrictions against putting the JARs in a public repo and > 2) The native DLL loading of JFX is not Maven friendly (so even if you put > the JARs in yourself it's still very messy) > > There was no movement from Oracle in addressing either of the above. > > The move to co-bundling (which will only be complete when the > bootclasspath issue is resolved) will render both of these issues > irrelevant so Maven+JFX users have been waiting (and waiting) for this > before doing anything further on it. > > > >> Once the basics are sorted out, it would be good to re-examine how >> developing JavaFX apps could be made even easier with Maven. For example, > > it might be nice to autogenerate these "Observable" POJOs from POJOs that >> already exist and are being used on the server. Imagine having the JavaFX >> version of Spring ROO or Grails where the forms and controllers you need >> are automatically generated. This would make it easier the prospect of >> transitioning to a new toolkit less daunting, and make it possible to >> build >> on the infrastructure and services that you already have in place. > > > Some RAD tools would be awesome. I don't think this is Maven's space > though but definitely within the ROO and Grails space. SceneBuilder is the > 'RAD' tool of the JFX platform but it is basically an FXML WYSIWYG editor. > > All of the above would aid adoption of JFX but all of the above has been > discussed at length before without much actual progress. > > From david.dehaven at oracle.com Mon Oct 15 16:59:41 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 15 Oct 2012 16:59:41 -0700 Subject: Proposed changes to media Track and children In-Reply-To: <2466471E-6DF6-4C52-8CC8-CDBCB7C40CED@gmail.com> References: <2466471E-6DF6-4C52-8CC8-CDBCB7C40CED@gmail.com> Message-ID: <2584B236-897A-488B-901D-5AE637190B58@oracle.com> Track.getLocale() is meant to replace AudioTrack.getLanguage() but for all Tracks and in a form that's (potentially) less ambiguous than a String. You're correct in that it's a convenience accessor, you'd be able to get the same Locale by calling Track.getMetadata().get("locale"). As far as need goes.. well, that was kind of my point for Option 2 :) It's all in the metadata. My personal feeling on this is if we stick with Option 1 or 1.5 then it falls under the case of "most commonly used" properties, so it should probably get an accessor. -DrD- > I think I like option 1. Do you need to make a new method to get the locale or can it simply be included as metadata in the map? > > Scott > > On 2012-10-15, at 5:20 PM, David DeHaven wrote: > >> >> To support multi-track movies (primarily for alternate languages and subtitles/captioning), we need to make some changes to the existing public media API. Other changes will be discussed separately... >> >> I have two (and a half) options at the moment and I thought I'd throw it out to you guys to help decide which direction to go. >> >> Option 1> >> Make the following changes to Track and it's subclasses: >> Changes to Track: >> - Add public final Locale getLocale(), returns a Locale if one is provided by the container or null if not >> - Add public final long getTrackId(), returns a unique numeric track ID that will be used by the stack to identify this specific track >> - Add public final Map getMetadata(), returns any metadata specific to this Track (returned Map is an UnmodifiableMap for security) >> >> Changes to AudioTrack: >> - getLanguage(): deprecate, "use Track.getLocale() instead." Which is all that method does now anyways. >> >> >> Option 2> >> - Deprecate Track, AudioTrack, VideoTrack and the Media.tracks property >> - Add a "tracks" value to the Media metadata Map (retrieved by Media.getMetadata()). This would essentially be a Map>. The outer Map would contain one entry per track, keyed to the tracks unique ID (what would be returned by getTrackID() above) and it's Map would be the metadata associated with that track, including all the fields currently contained in the Track classes. >> >> >> Option 1.5, a compromise between Option 1 and Option 2> >> - Deprecate AudioTrack and VideoTrack, leave Track and Media.tracks property >> - Add a track type property (yet another enum?) and reflect the type in the track metadata (textually, using names like "video" and "audio") >> - Include the other changes to Track in option 1 >> - The properties of Audio/VideoTrack would be accessed from the track metadata >> >> >> Reasoning (read: my lousy attempt at kicking off a discussion): >> >> The Track classes are pure metadata (I've no intention of ever changing that?) and at the moment we have kind of a duality of metadata representation for Media, provided as a Map via the Media metadata property and also represented by an assortment of properties in Media and the Track classes. Option 1 basically sticks with the current split model, extending it to allow more flexibility moving forward. Of particular importance is the unique track ID which will be required to select which tracks are active in the future. Option 2 reduces classes in the API and treats tracks purely as metadata, but it also ends up embedding Maps three levels deep which seems a bit ugly to me. Option 1.5 is a bit of a compromise between the two, leaving the tracks property that can be listened to (which is handy for UI purposes and might be handy for streaming, if it's supported) but still moving information into a metadata table instead of cluttering the classes up with a bunch of properties for data that may or may not exist. >> >> >> I've opened a JIRA issue to track this: >> http://javafx-jira.kenai.com/browse/RT-25678 >> >> -DrD- >> From tobi at ultramixer.com Mon Oct 15 22:59:41 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 16 Oct 2012 07:59:41 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> Message-ID: We should not change the topic, we should continue on discussing this topic. Because it's much more important than any Maven support! (feel free to start a new discussion about that). So now there are 48 posts concerning "No JavaFX on iOS, Android...."... It's the most important topic in the official JavaFX2 forum! So Oracle, do you think really there is no relevance??? Do you think really there is no demand for JavaFX? Do you think really there is any choice for JavaFX2 on mobile? No, there is no choice. 48posts from the community - 0 official posts from Oracle. What should it tell us? Oracle don't speak to their community - if they don't like. That's not what we need. We, the community need a strong leader with clear positions and statements. Please say YES or NO to JavaFX2 on mobile. Otherwise you can stop your investments in that great technology. There are so many so good JavaFX guys from Oracle, like Jasper, Richard, Nicolas, to name just a few. Oracle management, It's not fair to leave them alone. Best regards, Tobi Am 15.10.2012 um 22:11 schrieb Daniel Zwolenski : > Yea, we should have changed the subject, my bad. > > On the other hand the original conversation has continued slightly at: > https://forums.oracle.com/forums/message.jspa?messageID=10633435#10633435 > > But nothing new really from oracle on supporting either the mobile or the webapp spaces. > > > On 16/10/2012, at 5:29 AM, "Dr. Michael Paus" wrote: > >> Aren't we drifting away a little bit from the original topic of this thread :-? >> >> Am 15.10.2012 20:20, schrieb Igor Nekrestyanov: >>>> Though I am using WiX, I don't expect there is any hook to provide my own WiX source files to customize the automatically generated installer. >>> >>> You can certainly overwrite wix config file with custom version. See >>> http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGICFDB >>> >>> -igor >>> >> >> >> -- >> -------------------------------------------------------------------------------------- >> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). >> For more information visit www.jugs.de. >> From John_Smith at symantec.com Tue Oct 16 04:53:24 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 16 Oct 2012 04:53:24 -0700 Subject: Maven support In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221601DAFC39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> For those interested in Maven: See http://javafx-jira.kenai.com/browse/RT-25282 "Create a Maven plugin for JavaFX" -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Monday, October 15, 2012 1:55 PM To: openjfx-dev at openjdk.java.net Subject: Maven support There have been several discussions in the past six months about Maven support in JavaFX and I wanted to re-open the topic and perhaps get a comprehensive and current must-have list before filing an issue on it. Here's my list: - Create a Maven archetype to generate a JavaFX project skeleton. The archetype would: - Generate the appropriate folder structure including a folder for distribution resources like the splashscreen. - Generate a POM file with the appropriate dependencies. - Generate Maven goals for creating: - JNLP - Double-clickable JAR - Windows executable - Linux RPM and Deb files http://mojo.codehaus.org/rpm-maven-plugin/, http://mojo.codehaus.org/deb-maven-plugin/ - Mac DMG file: http://mojo.codehaus.org/osxappbundle-maven-plugin/ - Handle signing of the JARs (including dependencies). - Generate the source, and javadoc artifacts and install them in a public repository. Even though the JavaFX binaries are being distributed, the source and the JavaDoc are not, which makes debugging a pain. The POM should have no native dependencies. Development shops typically have a build machine (usually Linux) that runs automated builds, and the machine should be able to build any platform-specific executable. The POM shouldn't rely on Ant calls. The Maven plugin should be self-contained and easily configurable. Once the basics are sorted out, it would be good to re-examine how developing JavaFX apps could be made even easier with Maven. For example, it might be nice to autogenerate these "Observable" POJOs from POJOs that already exist and are being used on the server. Imagine having the JavaFX version of Spring ROO or Grails where the forms and controllers you need are automatically generated. This would make it easier the prospect of transitioning to a new toolkit less daunting, and make it possible to build on the infrastructure and services that you already have in place. Mark From java.whoover at gmail.com Tue Oct 16 05:28:03 2012 From: java.whoover at gmail.com (Will Hoover) Date: Tue, 16 Oct 2012 08:28:03 -0400 Subject: Maven support In-Reply-To: References: Message-ID: <507d52d4.0f37650a.5f92.400a@mx.google.com> If your JSON service has a backing POJO model you can use something like this: http://wp.me/p2rLDc-1c -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Monday, October 15, 2012 6:40 PM To: openjfx-dev at openjdk.java.net Subject: Re: Maven support Hi Dan, Along the lines of "things that I'd like to see, but not necessarily Maven related", it would be really useful if data and service binding were easier/possible. I'd like to be able to click on a combobox and point to the JSON service that supplies the data for the combobox. And then point the onSelect event handler to the service responsible for persisting the selection. When Rave came out this was one of the features that really caught developers eyes and made them reconsider JSF. Admittedly people have backtracked on that decision, but it's definitely something that would speed up the development process. Cheers, Mark On Mon, Oct 15, 2012 at 3:29 PM, Daniel Zwolenski wrote: > Hi Mark, > > You have summed up the Maven requirements perfectly. A few comments > inline below. > > On Tue, Oct 16, 2012 at 7:55 AM, Mark Fortner wrote: > >> There have been several discussions in the past six months about >> Maven support in JavaFX and I wanted to re-open the topic and perhaps >> get a comprehensive and current must-have list before filing an issue on it. >> > > Great to have this comprehensive list, however be aware that numerous > issues exist in JIRA already (search for Maven) and there have been > several energetic attempts to get some movement here. Several of the > issues have been closed previously by the JFX team with some key ones as "Won't fix". > > In general the Oracle guys are officially "hands off" on Maven (and > all non-ANT build tools). On the flip side the community has been > unable to progress this because of some of the issues. You will likely > find that the > Maven+JFX advocates have either given up or are waiting for true > co-bundling or total open sourcing before doing anything further. > > > >> Here's my list: >> >> - Create a Maven archetype to generate a JavaFX project skeleton. The >> archetype would: >> - Generate the appropriate folder structure including a folder >> for >> >> distribution resources like the splashscreen. >> - Generate a POM file with the appropriate dependencies. >> - Generate Maven goals for creating: >> - JNLP >> - Double-clickable JAR >> - Windows executable >> - Linux RPM and Deb files >> http://mojo.codehaus.org/rpm-maven-plugin/, >> http://mojo.codehaus.org/deb-maven-plugin/ >> - Mac DMG file: >> http://mojo.codehaus.org/osxappbundle-maven-plugin/ >> - Handle signing of the JARs (including dependencies). >> > > Yes to all. > > For those not used to Maven, this is effectively the 'plugin' side of > it that I was talking about in my previous email. i.e. the bit that > needs doing *after* the bootclasspath issue is finally resolved. > > - Generate the source, and javadoc artifacts and install them in a >> >> public repository. Even though the JavaFX binaries are being >> distributed, >> the source and the JavaDoc are not, which makes debugging a pain. >> > > There may be some Issues with version management on this one (i.e. the > Maven plugin having a different version to the runtime). > > Since JFX is "part of Java" (or trying to be), JFX should do whatever > Java does in this space in my opinion. > > >> The POM should have no native dependencies. Development shops >> typically have a build machine (usually Linux) that runs automated >> builds, and the machine should be able to build any platform-specific executable. >> > > This is definitely the ideal, and one of the major > drawbacks/show-stoppers to cross-platform JFX at the moment (i.e. the > current native build process is only slightly better than say a C++ native build). > > This issue applies equally to the ANT tasks. I created this issue a > while > ago: http://javafx-jira.kenai.com/browse/RT-22994 > > This is currently not possible for native installers. Some very major > work would need to be done on the way the native builds work and > there's not been any public discussions indicating this is something > the JFX team is looking into. > > > >> The POM shouldn't rely on Ant calls. The Maven plugin should be >> self-contained and easily configurable. >> > > I started work on this plugin (maybe a year ago or so). The ANT tasks > call onto the 'packager' library and the Maven plugin could/should do the same. > The packager code is quite clean and abstracted away from ANT. There > is definitely no *technical* need for either the developer or the > plugin to call out to ANT as an intermediary. > > The actual implementation of the plugin is actually quite straight > forward (though time consuming). I abandoned my plugin development due > to two > hurdles: > > 1) Oracle legal restrictions against putting the JARs in a public repo > and > 2) The native DLL loading of JFX is not Maven friendly (so even if you > put the JARs in yourself it's still very messy) > > There was no movement from Oracle in addressing either of the above. > > The move to co-bundling (which will only be complete when the > bootclasspath issue is resolved) will render both of these issues > irrelevant so Maven+JFX users have been waiting (and waiting) for this > before doing anything further on it. > > > >> Once the basics are sorted out, it would be good to re-examine how >> developing JavaFX apps could be made even easier with Maven. For >> example, > > it might be nice to autogenerate these "Observable" POJOs from POJOs > that >> already exist and are being used on the server. Imagine having the >> JavaFX version of Spring ROO or Grails where the forms and >> controllers you need are automatically generated. This would make it >> easier the prospect of transitioning to a new toolkit less daunting, >> and make it possible to build on the infrastructure and services that >> you already have in place. > > > Some RAD tools would be awesome. I don't think this is Maven's space > though but definitely within the ROO and Grails space. SceneBuilder is > the 'RAD' tool of the JFX platform but it is basically an FXML WYSIWYG editor. > > All of the above would aid adoption of JFX but all of the above has > been discussed at length before without much actual progress. > > From hang.vo at oracle.com Tue Oct 16 05:48:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 16 Oct 2012 12:48:41 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20121016124847.7D4A2473A1@hg.openjdk.java.net> Changeset: 7831b4f4de86 Author: Martin Sladecek Date: 2012-10-16 14:37 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7831b4f4de86 RT-25147 [FindBugs] GradientUtils$Point - A mutable static field could be changed by malicious code or by accident from another package. ! javafx-ui-common/src/com/sun/javafx/scene/paint/GradientUtils.java Changeset: bae4dedcad85 Author: Martin Sladecek Date: 2012-10-16 14:39 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bae4dedcad85 merge Changeset: 4dd0ce0f750e Author: Lubomir Nerad Date: 2012-10-16 14:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4dd0ce0f750e Fix for RT-25148: [FindBugs] Toolkit.java - A mutable static field could be changed by malicious code or by accident from another package. ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java From hang.vo at oracle.com Tue Oct 16 06:18:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 16 Oct 2012 13:18:18 +0000 Subject: hg: openjfx/8/controls/rt: RT-20786 : Focus couldn't be received or traversed. Message-ID: <20121016131821.F2F42473A2@hg.openjdk.java.net> Changeset: c731a926c171 Author: mickf Date: 2012-10-16 14:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c731a926c171 RT-20786 : Focus couldn't be received or traversed. ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java ! javafx-ui-common/src/javafx/scene/Scene.java From danno.ferrin at shemnon.com Tue Oct 16 09:05:14 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Tue, 16 Oct 2012 10:05:14 -0600 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> Message-ID: On Mon, Oct 15, 2012 at 11:59 PM, Tobias Bley wrote: > [SNIP] > 48posts from the community - 0 official posts from Oracle. What should it > tell us? Oracle don't speak to their community - if they don't like. That's > not what we need. We, the community need a strong leader with clear > positions and statements. > [SNIP] Did you completely miss the part where Richard Bair participated in this thread? In the context of his job? To me that constitutes Oracle speaking to their community. --Danno From danno.ferrin at shemnon.com Tue Oct 16 09:09:59 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Tue, 16 Oct 2012 10:09:59 -0600 Subject: Maven support In-Reply-To: References: Message-ID: On Mon, Oct 15, 2012 at 4:29 PM, Daniel Zwolenski wrote: > > Once the basics are sorted out, it would be good to re-examine how > > developing JavaFX apps could be made even easier with Maven. For > example, > > it might be nice to autogenerate these "Observable" POJOs from POJOs that > > already exist and are being used on the server. Imagine having the > JavaFX > > version of Spring ROO or Grails where the forms and controllers you need > > are automatically generated. This would make it easier the prospect of > > transitioning to a new toolkit less daunting, and make it possible to > build > > on the infrastructure and services that you already have in place. > > > Some RAD tools would be awesome. I don't think this is Maven's space though > but definitely within the ROO and Grails space. SceneBuilder is the 'RAD' > tool of the JFX platform but it is basically an FXML WYSIWYG editor. > > The JavaFX version of Grails is called Griffon. -- http://griffon-framework.org/ It is substantially derived from Grails (i.e. the first 0.0 release had large poritons cut and pasted, I would know). -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From phidias51 at gmail.com Tue Oct 16 09:44:11 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 16 Oct 2012 09:44:11 -0700 Subject: Maven support In-Reply-To: References: Message-ID: Thanks for the link Will. The idea behind baking in JSON support is to make it easy for people with existing "libraries" of RESTful services to be able to quickly wire up a JavaFX GUI, and make a potential transition from HTML/HTML5 to JavaFX as easy as possible. It's a powerful when you can take an HTML UI and quickly put together the JavaFX equivalent and reuse as much of your existing codebase as possible. Cheers, Mark On Tue, Oct 16, 2012 at 9:09 AM, Danno Ferrin wrote: > > > On Mon, Oct 15, 2012 at 4:29 PM, Daniel Zwolenski wrote: > >> > Once the basics are sorted out, it would be good to re-examine how >> > developing JavaFX apps could be made even easier with Maven. For >> example, >> >> it might be nice to autogenerate these "Observable" POJOs from POJOs that >> > already exist and are being used on the server. Imagine having the >> JavaFX >> > version of Spring ROO or Grails where the forms and controllers you need >> > are automatically generated. This would make it easier the prospect of >> > transitioning to a new toolkit less daunting, and make it possible to >> build >> > on the infrastructure and services that you already have in place. >> >> >> Some RAD tools would be awesome. I don't think this is Maven's space >> though >> but definitely within the ROO and Grails space. SceneBuilder is the 'RAD' >> tool of the JFX platform but it is basically an FXML WYSIWYG editor. >> >> > The JavaFX version of Grails is called Griffon. -- > http://griffon-framework.org/ > It is substantially derived from Grails (i.e. the first 0.0 release had > large poritons cut and pasted, I would know). > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > > From hang.vo at oracle.com Tue Oct 16 09:48:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 16 Oct 2012 16:48:20 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121016164824.DEB68473AB@hg.openjdk.java.net> Changeset: 7f6a99c842fd Author: hudson Date: 2012-10-11 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7f6a99c842fd Added tag 8.0-b60 for changeset ea00b638cdd6 ! .hgtags Changeset: a49900764c1d Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-16 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a49900764c1d Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt From hang.vo at oracle.com Tue Oct 16 13:48:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 16 Oct 2012 20:48:45 +0000 Subject: hg: openjfx/8/controls/rt: 9 new changesets Message-ID: <20121016204855.D798C473CD@hg.openjdk.java.net> Changeset: 7f6a99c842fd Author: hudson Date: 2012-10-11 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7f6a99c842fd Added tag 8.0-b60 for changeset ea00b638cdd6 ! .hgtags Changeset: 91c30a8859db Author: rbair Date: 2012-09-20 22:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/91c30a8859db Improved handling of thumb size, from previous patch 81cc13fe6f96 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 408ee6a41174 Author: David Hill Date: 2012-10-09 17:44 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/408ee6a41174 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: 19bdbf3b30ee Author: David Hill Date: 2012-10-12 11:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/19bdbf3b30ee Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: 7831b4f4de86 Author: Martin Sladecek Date: 2012-10-16 14:37 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7831b4f4de86 RT-25147 [FindBugs] GradientUtils$Point - A mutable static field could be changed by malicious code or by accident from another package. ! javafx-ui-common/src/com/sun/javafx/scene/paint/GradientUtils.java Changeset: bae4dedcad85 Author: Martin Sladecek Date: 2012-10-16 14:39 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bae4dedcad85 merge Changeset: 4dd0ce0f750e Author: Lubomir Nerad Date: 2012-10-16 14:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4dd0ce0f750e Fix for RT-25148: [FindBugs] Toolkit.java - A mutable static field could be changed by malicious code or by accident from another package. ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java Changeset: a49900764c1d Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-16 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a49900764c1d Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt Changeset: 97d1312344e8 Author: leifs Date: 2012-10-16 13:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/97d1312344e8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt From tobi at ultramixer.com Tue Oct 16 23:39:02 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 17 Oct 2012 08:39:02 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> Message-ID: Hi Danno, maybe I was missing something... or do you really mean the two sentences of Richard: "I've been watching this thread, of course pleased . To make a positive impact, anybody who has a commercial interest in this (beyond "I'm a Java developer and I think it would be cool", but really money on the line), please send me an email (richard dot bair at oracle dot com)." Tobi Am 16.10.2012 um 18:05 schrieb Danno Ferrin : > On Mon, Oct 15, 2012 at 11:59 PM, Tobias Bley wrote: > [SNIP] > 48posts from the community - 0 official posts from Oracle. What should it tell us? Oracle don't speak to their community - if they don't like. That's not what we need. We, the community need a strong leader with clear positions and statements. > [SNIP] > > Did you completely miss the part where Richard Bair participated in this thread? In the context of his job? To me that constitutes Oracle speaking to their community. > > --Danno From zonski at gmail.com Wed Oct 17 00:49:38 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 17 Oct 2012 18:49:38 +1100 Subject: JavaFX for the Enterprise - Working Group Message-ID: So Oracle as an organization doesn't think JavaFX can be a player in the web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * potential* to be better. But it's a long way behind and gotten off to a rocky start; there's a hell of a lot of work to be done and the current rate, strategy and direction are not going to be nearly enough. Oracle is a big corporation with many different divisions. The left arm doesn't know what the right is doing. So let's put aside 'oracle' for a moment. I want to know: what does the JavaFX team think? Do you want to go up against HTML5 for the client space, or just settle for a spot on the fringe? Below is what I propose. This proposal needs the full backing of the JavaFX team and management. Specifically it needs: 1. Belief that JavaFX can and should be the *number one* client development platform for enterprise. 2. Recognition that the current strategy will not make that happen. 3. Resources (aka people) allocated to the working group outlined below. These people must have enough influence in the JFX platform to legitimately be able to influence the direction as needed. 4. Commitment to supporting this working group fully and implementing the strategies and recommendations that come out of it as a high priority 5. A sense of urgency, and a proactive pursuit of achieving these goals with a well defined timeline (i.e. "resources will be allocated by November 2012" not "we're working on it"). In my opinion, all of these must be met 100%. Otherwise there is no point starting at all and better to let it go and leave the enterprise space to other players like HTML5 as 'Oracle' is suggesting. This is your call. I believe JavaFX can be the best platform for client-side enterprise application development, capitalising-on, and adding-to Java's dominance in server side enterprise development. Do you? *Proposal to form a working group for JavaFX in the enterprise* Mission: - to position JavaFX as *the* dominant client-side development platform for enterprise/business applications Members: - a combination of paid Oracle JavaFX team members, and community participants. The Oracle members must have the ability to access senior JavaFX management and technical decision makers, and as such influence the road map and direction of the JavaFX platform. Community members will be those with a background and experience in the enterprise space and who are committed to making JavaFX the platform of choice in this space. Responsibilities: - Continuously identify improvements to the JavaFX platform that are needed to ensure adoption by enterprise; drive the inclusion of these into the JavaFX platform. - Continuously identify and monitor trends and developments within the enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's long term viability for their needs. - Provide best practices, community/forum support, documentation, examples, tool add-ons, frameworks and other aids for integrating JavaFX into popular enterprise technology stacks - Provide advocacy, publicity and drive general engagement and outreach programs for the adoption of JavaFX in the enterprise. Objectives: Objectives will be determined by the working group once formed, however initial objectives will likely include the following: - Review the current deployment/distribution options for JavaFX and determine ways to improve this to make it competitive with other popular enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise OS' and platforms - Identify the most popular enterprise build and development tools and determine a strategy for making JavaFX integrate into these - Review popular trends and toolkits within competitive platforms and define the ideal frameworks and add-on tools needed by an enterprise client (e.g. form validation). Use this list of high-level requirements to determine the low-level JavaFX enhancements needed (e.g. allow field markers so that a 3rd party validation framework could leverage these). - Create a demonstration enterprise application (along the lines of PetClinic) demonstrating best practice for integrating JavaFX in a full, end-to-end JEE stack. Longer term objectives may include: - Develop (or foster community development of) the high-level frameworks that have been identified as necessary for JavaFX in the enterprise. These will likely be developed as third-party modules external to the JavaFX core framework (i.e. built on top of the features provided by the core JavaFX team). - Provide integration with existing or new Rapid Application Development (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). From knut.arne.vedaa at broadpark.no Wed Oct 17 03:12:41 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Wed, 17 Oct 2012 12:12:41 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <507E8499.7060802@broadpark.no> +1 on the initiative. Knut Arne Vedaa On 17.10.2012 09:49, Daniel Zwolenski wrote: > So Oracle as an organization doesn't think JavaFX can be a player in the > web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * > potential* to be better. But it's a long way behind and gotten off to a > rocky start; there's a hell of a lot of work to be done and the current > rate, strategy and direction are not going to be nearly enough. > > Oracle is a big corporation with many different divisions. The left arm > doesn't know what the right is doing. So let's put aside 'oracle' for a > moment. I want to know: what does the JavaFX team think? Do you want to go > up against HTML5 for the client space, or just settle for a spot on the > fringe? > > Below is what I propose. > > This proposal needs the full backing of the JavaFX team and management. > Specifically it needs: > > 1. Belief that JavaFX can and should be the *number one* client > development platform for enterprise. > 2. Recognition that the current strategy will not make that happen. > 3. Resources (aka people) allocated to the working group outlined below. > These people must have enough influence in the JFX platform to legitimately > be able to influence the direction as needed. > 4. Commitment to supporting this working group fully and implementing > the strategies and recommendations that come out of it as a high priority > 5. A sense of urgency, and a proactive pursuit of achieving these goals > with a well defined timeline (i.e. "resources will be allocated by November > 2012" not "we're working on it"). > > In my opinion, all of these must be met 100%. Otherwise there is no point > starting at all and better to let it go and leave the enterprise space to > other players like HTML5 as 'Oracle' is suggesting. This is your call. > > I believe JavaFX can be the best platform for client-side enterprise > application development, capitalising-on, and adding-to Java's dominance in > server side enterprise development. > > Do you? > > > *Proposal to form a working group for JavaFX in the enterprise* > > Mission: > > - to position JavaFX as *the* dominant client-side development platform > for enterprise/business applications > > > Members: > > - a combination of paid Oracle JavaFX team members, and community > participants. The Oracle members must have the ability to access senior > JavaFX management and technical decision makers, and as such influence the > road map and direction of the JavaFX platform. Community members will be > those with a background and experience in the enterprise space and who are > committed to making JavaFX the platform of choice in this space. > > > Responsibilities: > > - Continuously identify improvements to the JavaFX platform that are > needed to ensure adoption by enterprise; drive the inclusion of these into > the JavaFX platform. > > - Continuously identify and monitor trends and developments within the > enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > long term viability for their needs. > > - Provide best practices, community/forum support, documentation, > examples, tool add-ons, frameworks and other aids for integrating JavaFX > into popular enterprise technology stacks > > - Provide advocacy, publicity and drive general engagement and outreach > programs for the adoption of JavaFX in the enterprise. > > > Objectives: > > Objectives will be determined by the working group once formed, however > initial objectives will likely include the following: > > - Review the current deployment/distribution options for JavaFX and > determine ways to improve this to make it competitive with other popular > enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise > OS' and platforms > > - Identify the most popular enterprise build and development tools and > determine a strategy for making JavaFX integrate into these > > - Review popular trends and toolkits within competitive platforms and > define the ideal frameworks and add-on tools needed by an enterprise client > (e.g. form validation). Use this list of high-level requirements to > determine the low-level JavaFX enhancements needed (e.g. allow field > markers so that a 3rd party validation framework could leverage these). > > - Create a demonstration enterprise application (along the lines of > PetClinic) demonstrating best practice for integrating JavaFX in a full, > end-to-end JEE stack. > > > Longer term objectives may include: > > - Develop (or foster community development of) the high-level frameworks > that have been identified as necessary for JavaFX in the enterprise. These > will likely be developed as third-party modules external to the JavaFX core > framework (i.e. built on top of the features provided by the core JavaFX > team). > > - Provide integration with existing or new Rapid Application Development > (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). > From johan at lodgon.com Wed Oct 17 04:53:15 2012 From: johan at lodgon.com (Johan Vos) Date: Wed, 17 Oct 2012 13:53:15 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: Richard, all, My 2 cents on this: 1. Once the code for the native libraries is open-sourced, I expect the community to jump on it. Without source code, we are complete dependent on what Oracle decides. 2. I hear the message that you want customers, not (only) developers asking for JavaFX on mobile. I understand the motivations behind this. Unfortunately, I'm not a big Oracle customer (I don't even own an Exalogic ;)), so I can't be of much help here. But I doubt there will be many end-customers asking for JavaFX on mobile. I'm active in a number of projects where the customer (and some of them are rather big, like some the biggest media companies in Belgium) require a Desktop application and a Mobile/Tablet application. If the desktop application is targeted towards millions of users, it is hard to convince the customer to do this in something else than HTML. When talking about a limited group of users, JavaFX is absolutely in the picture. For the mobile, the situation is completely different. The mobile/tablet counterpart of a project is often seen as fancy, very important for marketing, should be extremely intuitive,... and most customers I am talking too prefer a native application over a mobile web application. However, at least the people I talk to don't care if it is a JavaFX app, a native iOS app, a native Android app,... As long as the application can be downloaded using the respective appstores (which implicitly indicates the app adheres to some standards), it's all good. So they won't be knocking on Oracle's door easily, I'm afraid. As a developer, I do care about the underlying technology. I want to write a single application and run it on every platform. Speed of development, bug fixing, maintenance, operational cost, abstraction of changes in underlying OS,... those are areas that are very important to me as a developer. As a matter of fact, it makes a HUGE difference for a developer, but a minor difference for the customer. In the end, it will be cheaper for the customer, since development cost will be lower. This will become more important in the future, I believe. But at this relative early stage of "app development" and the premature stage of "JavaFX app development", it is hard to measure the impact of development cost on the willing of customers to talk to Oracle about supporting JavaFX on mobile/tablet. - Johan 2012/10/9 Richard Bair > > > It's blatantly clear that Java developers *crave* JavaFX on mobiles and > yet > > Oracle are waiting for clear commercial interest to justify such support? > > As has been pointed out several times, JavaFX cannot be considered a > success > > if it is limited to the scope of the desktop and perhaps some embedded > > devices. Many predict that the PC in its current form will largely > > disappear in the next 5 years so where would that leave JavaFX? > > > > Java developers are largely passionate about their language and do not > want > > to learn Objective C or C# or whatever language is required on each > device. > > > > In my opinion, being able to code in Java and deploy to Windows, Linux, > > MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as > > the best platform for client side software development on the planet. > > Please Oracle, don't miss this enormous opportunity! What do we have to > do > > to convince you that this REALLY IS A GOOD IDEA? > > The anger and passion exhibited on this thread is very gratifying and very > helpful. > Even more helpful would be to funnel as many developers to me as you find > that > have a demand for FX on smartphones and tablets. You'll not find more > passionate > partisans for JavaFX than here in the Java group. Being able to demonstrate > industry demand and commitment is what we need. Of course, when JavaFX is > open sourced (as Hasan announced at JavaOne we will complete shortly), then > of course anybody could do a port to iOS / Android. The question isn't > about whether > or not JavaFX will be on smart phones -- it will be. The question is who > is funding > it and who is supporting it. Of course many of us feel that supporting iOS > and > Android is at least as important as Windows and Mac. However, it is hard > to fault > the guys paying the bills for asking for some evidence of that viewpoint. > Customers > beating on our doors demanding support for FX on these devices is exactly > that > evidence. > > But in any case, this is an open source project, and regardless of whether > Oracle > foots the bill, I have no doubt that FX will be on iOS, Android, and > Windows Metro. > If you'd like to help, funnel your demands and use cases to me (and they > have all > the more weight when there is a real commercial demand behind them)! > > Richard From danno.ferrin at shemnon.com Wed Oct 17 05:33:07 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Wed, 17 Oct 2012 06:33:07 -0600 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> Message-ID: On Wed, Oct 17, 2012 at 12:39 AM, Tobias Bley wrote: > Hi Danno, > > maybe I was missing something... or do you really mean the two sentences > of Richard: "I've been watching this thread, of course pleased . To make a > positive impact, anybody who has a commercial interest in this (beyond "I'm > a Java developer and I think it would be cool", but really money on the > line), please send me an email (richard dot bair at oracle dot com)." > > > You did miss something, like the four other responses from Richard in this thread, two of them quite lengthy. Including one with this line: > The anger and passion exhibited on this thread is very gratifying and very helpful. --Danno From tobi at ultramixer.com Wed Oct 17 06:38:27 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 17 Oct 2012 15:38:27 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> Message-ID: <625A9516-F83F-4D63-BF4A-6D5BEB4FCBD5@ultramixer.com> Yes ok, you are right. But all what Richard said is 1. "JavaFX on iOS, ..." comes true when JavaFX is open sourced and the community build the port 2. Oracle needs use cases, customers, real demand .... to make a good decision.... So where is the real statement / position? When do you make a descision, Oracle? What is your opinion about "the success of JavaFX without supporting mobile platforms" Oracle??? Tobi Am 17.10.2012 um 14:33 schrieb Danno Ferrin : > > > On Wed, Oct 17, 2012 at 12:39 AM, Tobias Bley wrote: > Hi Danno, > > maybe I was missing something... or do you really mean the two sentences of Richard: "I've been watching this thread, of course pleased . To make a positive impact, anybody who has a commercial interest in this (beyond "I'm a Java developer and I think it would be cool", but really money on the line), please send me an email (richard dot bair at oracle dot com)." > > > > You did miss something, like the four other responses from Richard in this thread, two of them quite lengthy. Including one with this line: > > > The anger and passion exhibited on this thread is very gratifying and very helpful. > > --Danno From omurata at ga2.so-net.ne.jp Wed Oct 17 07:03:50 2012 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Wed, 17 Oct 2012 23:03:50 +0900 Subject: JavaFX for Enterprise use case In-Reply-To: References: Message-ID: <507EBAC6.5060706@ga2.so-net.ne.jp> Hello evaryone (2012/10/17 16:49), Daniel Zwolenski wrote: > This proposal needs the full backing of the JavaFX team and management. > Specifically it needs: > > 1. Belief that JavaFX can and should be the *number one* client > development platform for enterprise. > I agree that JavaFX can and should be the *number one* client development platform for enterprise. I and StellaCorporation heve been developping CAD/CAM system with Java SWing/java2D Plese look at http://www.stellacorp.co.jp/en/products/soft/java/index.htm Now I pay attention to JavaFX for CAD/CAM system platform. Best regards Tadashi Ohmura From tobi at ultramixer.com Wed Oct 17 07:06:34 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 17 Oct 2012 16:06:34 +0200 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <50746021.1090404@media-interactive.de> <135960.15603.48905-10536-470314817-1349805207@seznam.cz> <193FF4ED343AF14F8CDC65B4792C954D13296583@Jeri.osys.ch> <507BF963.6080404@bestsolution.at> <193FF4ED343AF14F8CDC65B4792C954D132966D9@Jeri.osys.ch> <6FA1F1FC-7ADF-447D-B071-C89D3C21B5AE@gmail.com> <4FD97512-47B3-40FC-9BF9-3AED0E2FB18E@gmail.com> <507C53EB.7020006@oracle.com> <507C5605.8000502@jugs.org> <957CDC6E-B8AB-461A-B9D3-B2E3D1117725@gmail.com> <625A9516-F83F-4D63-BF4A-6D5BEB4FCBD5@ultramixer.com> Message-ID: <467C5248-E5DA-47E8-9603-7DD9824BD80E@ultramixer.com> Ok, then Oracle please release a commercial JavaFX for mobile and I pay for that. Am 17.10.2012 um 16:03 schrieb Danno Ferrin : > Oracle needs paying customers. This isn't Sun anymore where they will throw stuff out and hope it sticks. And when Oracle ships they want evidence that 4 years of continuing support won't be a total money drain. The decision has been made, when customers come with cash it will be released and worked on. > > On Wed, Oct 17, 2012 at 7:38 AM, Tobias Bley wrote: > Yes ok, you are right. > > But all what Richard said is > > 1. "JavaFX on iOS, ..." comes true when JavaFX is open sourced and the community build the port > 2. Oracle needs use cases, customers, real demand .... to make a good decision.... > > So where is the real statement / position? When do you make a descision, Oracle? What is your opinion about "the success of JavaFX without supporting mobile platforms" Oracle??? > > > Tobi > > > > > Am 17.10.2012 um 14:33 schrieb Danno Ferrin : > >> >> >> On Wed, Oct 17, 2012 at 12:39 AM, Tobias Bley wrote: >> Hi Danno, >> >> maybe I was missing something... or do you really mean the two sentences of Richard: "I've been watching this thread, of course pleased . To make a positive impact, anybody who has a commercial interest in this (beyond "I'm a Java developer and I think it would be cool", but really money on the line), please send me an email (richard dot bair at oracle dot com)." >> >> >> >> You did miss something, like the four other responses from Richard in this thread, two of them quite lengthy. Including one with this line: >> >> > The anger and passion exhibited on this thread is very gratifying and very helpful. >> >> --Danno > > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > From peter.pilgrim at gmail.com Wed Oct 17 07:20:49 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Wed, 17 Oct 2012 15:20:49 +0100 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <7830944087914512700@unknownmsgid> Hi These proposals some of the item read like demands. Normally, one invites people to discuss proposals. :-) Sent from my iPhone 4S On 17 Oct 2012, at 08:49, Daniel Zwolenski wrote: > So Oracle as an organization doesn't think JavaFX can be a player in the > web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * > potential* to be better. But it's a long way behind and gotten off to a > rocky start; there's a hell of a lot of work to be done and the current > rate, strategy and direction are not going to be nearly enough. > > Oracle is a big corporation with many different divisions. The left arm > doesn't know what the right is doing. So let's put aside 'oracle' for a > moment. I want to know: what does the JavaFX team think? Do you want to go > up against HTML5 for the client space, or just settle for a spot on the > fringe? > > Below is what I propose. > > This proposal needs the full backing of the JavaFX team and management. > Specifically it needs: > > 1. Belief that JavaFX can and should be the *number one* client > development platform for enterprise. > 2. Recognition that the current strategy will not make that happen. > 3. Resources (aka people) allocated to the working group outlined below. > These people must have enough influence in the JFX platform to legitimately > be able to influence the direction as needed. > 4. Commitment to supporting this working group fully and implementing > the strategies and recommendations that come out of it as a high priority > 5. A sense of urgency, and a proactive pursuit of achieving these goals > with a well defined timeline (i.e. "resources will be allocated by November > 2012" not "we're working on it"). > > In my opinion, all of these must be met 100%. Otherwise there is no point > starting at all and better to let it go and leave the enterprise space to > other players like HTML5 as 'Oracle' is suggesting. This is your call. > > I believe JavaFX can be the best platform for client-side enterprise > application development, capitalising-on, and adding-to Java's dominance in > server side enterprise development. > > Do you? > > > *Proposal to form a working group for JavaFX in the enterprise* > > Mission: > > - to position JavaFX as *the* dominant client-side development platform > for enterprise/business applications > > > Members: > > - a combination of paid Oracle JavaFX team members, and community > participants. The Oracle members must have the ability to access senior > JavaFX management and technical decision makers, and as such influence the > road map and direction of the JavaFX platform. Community members will be > those with a background and experience in the enterprise space and who are > committed to making JavaFX the platform of choice in this space. > > > Responsibilities: > > - Continuously identify improvements to the JavaFX platform that are > needed to ensure adoption by enterprise; drive the inclusion of these into > the JavaFX platform. > > - Continuously identify and monitor trends and developments within the > enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > long term viability for their needs. > > - Provide best practices, community/forum support, documentation, > examples, tool add-ons, frameworks and other aids for integrating JavaFX > into popular enterprise technology stacks > > - Provide advocacy, publicity and drive general engagement and outreach > programs for the adoption of JavaFX in the enterprise. > > > Objectives: > > Objectives will be determined by the working group once formed, however > initial objectives will likely include the following: > > - Review the current deployment/distribution options for JavaFX and > determine ways to improve this to make it competitive with other popular > enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise > OS' and platforms > > - Identify the most popular enterprise build and development tools and > determine a strategy for making JavaFX integrate into these > > - Review popular trends and toolkits within competitive platforms and > define the ideal frameworks and add-on tools needed by an enterprise client > (e.g. form validation). Use this list of high-level requirements to > determine the low-level JavaFX enhancements needed (e.g. allow field > markers so that a 3rd party validation framework could leverage these). > > - Create a demonstration enterprise application (along the lines of > PetClinic) demonstrating best practice for integrating JavaFX in a full, > end-to-end JEE stack. > > > Longer term objectives may include: > > - Develop (or foster community development of) the high-level frameworks > that have been identified as necessary for JavaFX in the enterprise. These > will likely be developed as third-party modules external to the JavaFX core > framework (i.e. built on top of the features provided by the core JavaFX > team). > > - Provide integration with existing or new Rapid Application Development > (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). From richard.bair at oracle.com Wed Oct 17 07:23:00 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 17 Oct 2012 07:23:00 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: We are already doing everything on your list (which was pretty void of specifics). Please list specific work projects, linked to specific JIRA issues, and vote for them and for goodness sake contribute! On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: > So Oracle as an organization doesn't think JavaFX can be a player in the > web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * > potential* to be better. But it's a long way behind and gotten off to a > rocky start; there's a hell of a lot of work to be done and the current > rate, strategy and direction are not going to be nearly enough. > > Oracle is a big corporation with many different divisions. The left arm > doesn't know what the right is doing. So let's put aside 'oracle' for a > moment. I want to know: what does the JavaFX team think? Do you want to go > up against HTML5 for the client space, or just settle for a spot on the > fringe? > > Below is what I propose. > > This proposal needs the full backing of the JavaFX team and management. > Specifically it needs: > > 1. Belief that JavaFX can and should be the *number one* client > development platform for enterprise. > 2. Recognition that the current strategy will not make that happen. > 3. Resources (aka people) allocated to the working group outlined below. > These people must have enough influence in the JFX platform to legitimately > be able to influence the direction as needed. > 4. Commitment to supporting this working group fully and implementing > the strategies and recommendations that come out of it as a high priority > 5. A sense of urgency, and a proactive pursuit of achieving these goals > with a well defined timeline (i.e. "resources will be allocated by November > 2012" not "we're working on it"). > > In my opinion, all of these must be met 100%. Otherwise there is no point > starting at all and better to let it go and leave the enterprise space to > other players like HTML5 as 'Oracle' is suggesting. This is your call. > > I believe JavaFX can be the best platform for client-side enterprise > application development, capitalising-on, and adding-to Java's dominance in > server side enterprise development. > > Do you? > > > *Proposal to form a working group for JavaFX in the enterprise* > > Mission: > > - to position JavaFX as *the* dominant client-side development platform > for enterprise/business applications > > > Members: > > - a combination of paid Oracle JavaFX team members, and community > participants. The Oracle members must have the ability to access senior > JavaFX management and technical decision makers, and as such influence the > road map and direction of the JavaFX platform. Community members will be > those with a background and experience in the enterprise space and who are > committed to making JavaFX the platform of choice in this space. > > > Responsibilities: > > - Continuously identify improvements to the JavaFX platform that are > needed to ensure adoption by enterprise; drive the inclusion of these into > the JavaFX platform. > > - Continuously identify and monitor trends and developments within the > enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > long term viability for their needs. > > - Provide best practices, community/forum support, documentation, > examples, tool add-ons, frameworks and other aids for integrating JavaFX > into popular enterprise technology stacks > > - Provide advocacy, publicity and drive general engagement and outreach > programs for the adoption of JavaFX in the enterprise. > > > Objectives: > > Objectives will be determined by the working group once formed, however > initial objectives will likely include the following: > > - Review the current deployment/distribution options for JavaFX and > determine ways to improve this to make it competitive with other popular > enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise > OS' and platforms > > - Identify the most popular enterprise build and development tools and > determine a strategy for making JavaFX integrate into these > > - Review popular trends and toolkits within competitive platforms and > define the ideal frameworks and add-on tools needed by an enterprise client > (e.g. form validation). Use this list of high-level requirements to > determine the low-level JavaFX enhancements needed (e.g. allow field > markers so that a 3rd party validation framework could leverage these). > > - Create a demonstration enterprise application (along the lines of > PetClinic) demonstrating best practice for integrating JavaFX in a full, > end-to-end JEE stack. > > > Longer term objectives may include: > > - Develop (or foster community development of) the high-level frameworks > that have been identified as necessary for JavaFX in the enterprise. These > will likely be developed as third-party modules external to the JavaFX core > framework (i.e. built on top of the features provided by the core JavaFX > team). > > - Provide integration with existing or new Rapid Application Development > (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). From roman at kennke.org Wed Oct 17 07:33:06 2012 From: roman at kennke.org (Roman Kennke) Date: Wed, 17 Oct 2012 16:33:06 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <1350484386.2097.56.camel@mercury> Am Mittwoch, den 17.10.2012, 07:23 -0700 schrieb Richard Bair: > We are already doing everything on your list (which was pretty void of > specifics). Please list specific work projects, linked to specific > JIRA issues, and vote for them and for goodness sake contribute! I was a little puzzled by the proposal. While I generally agree with the points, it reads a little much like 'demands'. I also agree with your sentiment, especially with 'for goodness sake contribute!'. The takeaway from all this is that the number one thing Oracle could do to accelerate JavaFX (both adoption AND contribution) is to open source it. This would make it easier (or feasible at all) to contribute and it would also help developers adopt it and use it for their own projects & products. But I know you know all this already so who am I telling this? ;-) Cheers, Roman From richard.bair at oracle.com Wed Oct 17 07:31:36 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 17 Oct 2012 07:31:36 -0700 Subject: No JavaFX for iOS, Android or WP - why not? In-Reply-To: References: <005101cda5e6$c6d7b960$54872c20$@com.au> <5116F84B-FB3B-493A-B09C-711FE0CC4608@ultramixer.com> <006501cda5f6$9d1ffeb0$d75ffc10$@com.au> Message-ID: <2DC23C11-C1CC-49E9-9D73-C368A691E384@oracle.com> You *definitely* qualify as a customer :-). You don't need to be a name brand, the fact that you are using JavaFX commercially is all that matters for this iOS / Android exercise. On Oct 17, 2012, at 4:53 AM, Johan Vos wrote: > Richard, all, > > My 2 cents on this: > 1. Once the code for the native libraries is open-sourced, I expect the community to jump on it. Without source code, we are complete dependent on what Oracle decides. > 2. I hear the message that you want customers, not (only) developers asking for JavaFX on mobile. I understand the motivations behind this. Unfortunately, I'm not a big Oracle customer (I don't even own an Exalogic ;)), so I can't be of much help here. > > But I doubt there will be many end-customers asking for JavaFX on mobile. I'm active in a number of projects where the customer (and some of them are rather big, like some the biggest media companies in Belgium) require a Desktop application and a Mobile/Tablet application. If the desktop application is targeted towards millions of users, it is hard to convince the customer to do this in something else than HTML. When talking about a limited group of users, JavaFX is absolutely in the picture. > > For the mobile, the situation is completely different. The mobile/tablet counterpart of a project is often seen as fancy, very important for marketing, should be extremely intuitive,... and most customers I am talking too prefer a native application over a mobile web application. However, at least the people I talk to don't care if it is a JavaFX app, a native iOS app, a native Android app,... As long as the application can be downloaded using the respective appstores (which implicitly indicates the app adheres to some standards), it's all good. So they won't be knocking on Oracle's door easily, I'm afraid. > > As a developer, I do care about the underlying technology. I want to write a single application and run it on every platform. Speed of development, bug fixing, maintenance, operational cost, abstraction of changes in underlying OS,... those are areas that are very important to me as a developer. As a matter of fact, it makes a HUGE difference for a developer, but a minor difference for the customer. In the end, it will be cheaper for the customer, since development cost will be lower. This will become more important in the future, I believe. But at this relative early stage of "app development" and the premature stage of "JavaFX app development", it is hard to measure the impact of development cost on the willing of customers to talk to Oracle about supporting JavaFX on mobile/tablet. > > - Johan > > > 2012/10/9 Richard Bair > > > It's blatantly clear that Java developers *crave* JavaFX on mobiles and yet > > Oracle are waiting for clear commercial interest to justify such support? > > As has been pointed out several times, JavaFX cannot be considered a success > > if it is limited to the scope of the desktop and perhaps some embedded > > devices. Many predict that the PC in its current form will largely > > disappear in the next 5 years so where would that leave JavaFX? > > > > Java developers are largely passionate about their language and do not want > > to learn Objective C or C# or whatever language is required on each device. > > > > In my opinion, being able to code in Java and deploy to Windows, Linux, > > MacOS, iOS, Android, Metro etc. could propel JavaFX to amazing heights as > > the best platform for client side software development on the planet. > > Please Oracle, don't miss this enormous opportunity! What do we have to do > > to convince you that this REALLY IS A GOOD IDEA? > > The anger and passion exhibited on this thread is very gratifying and very helpful. > Even more helpful would be to funnel as many developers to me as you find that > have a demand for FX on smartphones and tablets. You'll not find more passionate > partisans for JavaFX than here in the Java group. Being able to demonstrate > industry demand and commitment is what we need. Of course, when JavaFX is > open sourced (as Hasan announced at JavaOne we will complete shortly), then > of course anybody could do a port to iOS / Android. The question isn't about whether > or not JavaFX will be on smart phones -- it will be. The question is who is funding > it and who is supporting it. Of course many of us feel that supporting iOS and > Android is at least as important as Windows and Mac. However, it is hard to fault > the guys paying the bills for asking for some evidence of that viewpoint. Customers > beating on our doors demanding support for FX on these devices is exactly that > evidence. > > But in any case, this is an open source project, and regardless of whether Oracle > foots the bill, I have no doubt that FX will be on iOS, Android, and Windows Metro. > If you'd like to help, funnel your demands and use cases to me (and they have all > the more weight when there is a real commercial demand behind them)! > > Richard > From goddard at seznam.cz Wed Oct 17 07:36:33 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Wed, 17 Oct 2012 16:36:33 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20No=20JavaFX=20for=20iOS=2C=20Android=20or=20WP=20=2D=20why=20not=3F?= In-Reply-To: <625A9516-F83F-4D63-BF4A-6D5BEB4FCBD5@ultramixer.com> Message-ID: <136416.15008.49794-25498-1763940548-1350484593@seznam.cz> This seems to be endless :) Why doesn't just everyone pick up a tablet / device that can actually run Oracle Java / JavaFX, like WeTab, and starts pushing it forward? I can already hear something about market shares, but in reality, applications are what makes the platform attractive. I also bet that there're some people who are working on linux distros for smartphones. That's a great opportunity :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Tobias Bley P?edm?t: Re: No JavaFX for iOS, Android or WP - why not? Datum: 17.10.2012 15:41:37 ---------------------------------------- Yes ok, you are right. But all what Richard said is 1. "JavaFX on iOS, ..." comes true when JavaFX is open sourced and the community build the port 2. Oracle needs use cases, customers, real demand .... to make a good decision.... So where is the real statement / position? When do you make a descision, Oracle? What is your opinion about "the success of JavaFX without supporting mobile platforms" Oracle??? Tobi Am 17.10.2012 um 14:33 schrieb Danno Ferrin : > > > On Wed, Oct 17, 2012 at 12:39 AM, Tobias Bley wrote: > Hi Danno, > > maybe I was missing something... or do you really mean the two sentences of Richard: "I've been watching this thread, of course pleased . To make a positive impact, anybody who has a commercial interest in this (beyond "I'm a Java developer and I think it would be cool", but really money on the line), please send me an email (richard dot bair at oracle dot com)." > > > > You did miss something, like the four other responses from Richard in this thread, two of them quite lengthy. Including one with this line: > > > The anger and passion exhibited on this thread is very gratifying and very helpful. > > --Danno From neugens.limasoftware at gmail.com Wed Oct 17 07:39:54 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 17 Oct 2012 16:39:54 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: 2012/10/17 Daniel Zwolenski : > So Oracle as an organization doesn't think JavaFX can be a player in the > web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * > potential* to be better. But it's a long way behind and gotten off to a > rocky start; there's a hell of a lot of work to be done and the current > rate, strategy and direction are not going to be nearly enough. > > Oracle is a big corporation with many different divisions. The left arm > doesn't know what the right is doing. So let's put aside 'oracle' for a > moment. I want to know: what does the JavaFX team think? Do you want to go > up against HTML5 for the client space, or just settle for a spot on the > fringe? Well, you know, somehow there is people that think HTML 5 has a market and other people that think JavaFX is the future, perhaps those both have a market and a future? It makes a lot of sense to support one product *and* the other, and it especially makes sense to support one over the other in some context at times: if you think rationally there are limited resources even in huge corporations like Oracle; I can see why some management folks make decision like this, they probably go where they think there is money, and I can also see how they piss everybody else off by doing this ;) There is only one solution for this, once the code is out, put your own time in it to get it where nobody else has before. No, really. Seriously. When Richard ask you to contribute, he really means it. And it's not about Oracle being crazy here, every Open Source project works the same way, really. People do choices, somebody doesn't agree, then just grab the code and fix what's wrong... Whoops... now I hear you say it! Where's the code? This is really a question for Richard then :) But really, this is the only thing to worry about and that we need to keep asking aloud, all the rest will come by. [1] Cheers, Mario [1] And to be honest, I love this thread even if I think the questions are all the other way around, because it shows there's a community out there that really wants this code to be out sooner. -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From markclaassenx at gmail.com Wed Oct 17 07:40:17 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Wed, 17 Oct 2012 10:40:17 -0400 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: I joined this list a few days ago because I wanted to start contributing So far, I am not sure it is quite where I should be. I would like to discuss more about the components (table, list boxes, ...). I am not exactly sure where to do that. However, I will add here that I started (a very short-lived) thread on the netbeans user list along these lines. Basically what I was saying was that Netbeans is a wonderful UI built on Swing. Could this same project be done in JavaFX? Maybe not yet, but could it be in the future? It seems like the JavaFX team could get a lot of advice and requirements from the netbeans team. http://forums.netbeans.org/topic51717.html Some of the main data structures, like the ObservableList, make me cringe. I created a similar structure 10 years ago and have since learned the error of my ways. Granted, the JavaFX team has a lot more resources and experience than I did all those years ago, but from my point of view, there are dangerous waters ahead. On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair wrote: > We are already doing everything on your list (which was pretty void of > specifics). Please list specific work projects, linked to specific JIRA > issues, and vote for them and for goodness sake contribute! > > > > > On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: > > > So Oracle as an organization doesn't think JavaFX can be a player in the > > web/enterprise space and is backing HTML5. I don't agree, JavaFX has the > * > > potential* to be better. But it's a long way behind and gotten off to a > > rocky start; there's a hell of a lot of work to be done and the current > > rate, strategy and direction are not going to be nearly enough. > > > > Oracle is a big corporation with many different divisions. The left arm > > doesn't know what the right is doing. So let's put aside 'oracle' for a > > moment. I want to know: what does the JavaFX team think? Do you want to > go > > up against HTML5 for the client space, or just settle for a spot on the > > fringe? > > > > Below is what I propose. > > > > This proposal needs the full backing of the JavaFX team and management. > > Specifically it needs: > > > > 1. Belief that JavaFX can and should be the *number one* client > > development platform for enterprise. > > 2. Recognition that the current strategy will not make that happen. > > 3. Resources (aka people) allocated to the working group outlined > below. > > These people must have enough influence in the JFX platform to > legitimately > > be able to influence the direction as needed. > > 4. Commitment to supporting this working group fully and implementing > > the strategies and recommendations that come out of it as a high > priority > > 5. A sense of urgency, and a proactive pursuit of achieving these goals > > with a well defined timeline (i.e. "resources will be allocated by > November > > 2012" not "we're working on it"). > > > > In my opinion, all of these must be met 100%. Otherwise there is no point > > starting at all and better to let it go and leave the enterprise space to > > other players like HTML5 as 'Oracle' is suggesting. This is your call. > > > > I believe JavaFX can be the best platform for client-side enterprise > > application development, capitalising-on, and adding-to Java's dominance > in > > server side enterprise development. > > > > Do you? > > > > > > *Proposal to form a working group for JavaFX in the enterprise* > > > > Mission: > > > > - to position JavaFX as *the* dominant client-side development platform > > for enterprise/business applications > > > > > > Members: > > > > - a combination of paid Oracle JavaFX team members, and community > > participants. The Oracle members must have the ability to access senior > > JavaFX management and technical decision makers, and as such influence > the > > road map and direction of the JavaFX platform. Community members will > be > > those with a background and experience in the enterprise space and who > are > > committed to making JavaFX the platform of choice in this space. > > > > > > Responsibilities: > > > > - Continuously identify improvements to the JavaFX platform that are > > needed to ensure adoption by enterprise; drive the inclusion of these > into > > the JavaFX platform. > > > > - Continuously identify and monitor trends and developments within the > > enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > > ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > > long term viability for their needs. > > > > - Provide best practices, community/forum support, documentation, > > examples, tool add-ons, frameworks and other aids for integrating > JavaFX > > into popular enterprise technology stacks > > > > - Provide advocacy, publicity and drive general engagement and outreach > > programs for the adoption of JavaFX in the enterprise. > > > > > > Objectives: > > > > Objectives will be determined by the working group once formed, however > > initial objectives will likely include the following: > > > > - Review the current deployment/distribution options for JavaFX and > > determine ways to improve this to make it competitive with other > popular > > enterprise client platforms (e.g. HTML+JavaScript) for primary > enterprise > > OS' and platforms > > > > - Identify the most popular enterprise build and development tools and > > determine a strategy for making JavaFX integrate into these > > > > - Review popular trends and toolkits within competitive platforms and > > define the ideal frameworks and add-on tools needed by an enterprise > client > > (e.g. form validation). Use this list of high-level requirements to > > determine the low-level JavaFX enhancements needed (e.g. allow field > > markers so that a 3rd party validation framework could leverage these). > > > > - Create a demonstration enterprise application (along the lines of > > PetClinic) demonstrating best practice for integrating JavaFX in a > full, > > end-to-end JEE stack. > > > > > > Longer term objectives may include: > > > > - Develop (or foster community development of) the high-level > frameworks > > that have been identified as necessary for JavaFX in the enterprise. > These > > will likely be developed as third-party modules external to the JavaFX > core > > framework (i.e. built on top of the features provided by the core > JavaFX > > team). > > > > - Provide integration with existing or new Rapid Application > Development > > (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). > From neugens.limasoftware at gmail.com Wed Oct 17 07:55:58 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 17 Oct 2012 16:55:58 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: 2012/10/17 Mark Claassen : > I joined this list a few days ago because I wanted to start contributing > So far, I am not sure it is quite where I should be. I would like to > discuss more about the components (table, list boxes, ...). I am not > exactly sure where to do that. You just unfortunately ended up subscribing to this list in the middle of a storm :) But this list has been used in the past to discuss components and details of the implementation, so this is definitely the right place to start discussing those things. @Richard: Perhaps it would be more fun to simply have a list dedicated to flaming Oracle for supporting HTML 5 rather than JavaFX :) > However, I will add here that I started (a very short-lived) thread on the > netbeans user list along these lines. Basically what I was saying was that > Netbeans is a wonderful UI built on Swing. Could this same project be done > in JavaFX? Maybe not yet, but could it be in the future? It seems like > the JavaFX team could get a lot of advice and requirements from the > netbeans team. > > http://forums.netbeans.org/topic51717.html This thread is interesting. I've seen at J1 some tools using JavaFX with the SWT bridge. The Swing one will also work equally well. We also have (we need to put some love to make it work on 2.2 The big trouble is #2, this will only work if: 1. Netbeans can ship JavaFX 2. JavaFX is included in any major OpenJDK/JDK releases (that means, including distribution related IcedTea builds). For both options, JavaFX needs to be fully Open Sourced, or even NetBeans will fall back into non free bits, so I agree with them. > Some of the main data structures, like the ObservableList, make me cringe. > I created a similar structure 10 years ago and have since learned the error > of my ways. Granted, the JavaFX team has a lot more resources and > experience than I did all those years ago, but from my point of view, there > are dangerous waters ahead. I'm sure this is the kind of discussion mostly welcomed on this list, after all, this is what makes it a community project. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From neugens.limasoftware at gmail.com Wed Oct 17 08:21:08 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 17 Oct 2012 17:21:08 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: """ This thread is interesting. I've seen at J1 some tools using JavaFX with the SWT bridge. The Swing one will also work equally well. We also have (we need to put some love to make it work on 2.2 """ Somehow this got cut, I meant: This thread is interesting. I've seen at J1 some tools using JavaFX with the SWT bridge. The Swing one will also work equally well. We also have (we need to put some love to make it work on 2.2) that can be used to embed Swing on top of JavaFX (the other way around). Cheers, Mario 2012/10/17 Mario Torre : > 2012/10/17 Mark Claassen : >> I joined this list a few days ago because I wanted to start contributing >> So far, I am not sure it is quite where I should be. I would like to >> discuss more about the components (table, list boxes, ...). I am not >> exactly sure where to do that. > > You just unfortunately ended up subscribing to this list in the middle > of a storm :) > > But this list has been used in the past to discuss components and > details of the implementation, so this is definitely the right place > to start discussing those things. > > @Richard: Perhaps it would be more fun to simply have a list dedicated > to flaming Oracle for supporting HTML 5 rather than JavaFX :) > >> However, I will add here that I started (a very short-lived) thread on the >> netbeans user list along these lines. Basically what I was saying was that >> Netbeans is a wonderful UI built on Swing. Could this same project be done >> in JavaFX? Maybe not yet, but could it be in the future? It seems like >> the JavaFX team could get a lot of advice and requirements from the >> netbeans team. >> >> http://forums.netbeans.org/topic51717.html > > This thread is interesting. I've seen at J1 some tools using JavaFX > with the SWT bridge. The Swing one will also work equally well. We > also have (we need to put some love to make it work on 2.2 > > The big trouble is #2, this will only work if: > > 1. Netbeans can ship JavaFX > 2. JavaFX is included in any major OpenJDK/JDK releases (that means, > including distribution related IcedTea builds). > > For both options, JavaFX needs to be fully Open Sourced, or even > NetBeans will fall back into non free bits, so I agree with them. > >> Some of the main data structures, like the ObservableList, make me cringe. >> I created a similar structure 10 years ago and have since learned the error >> of my ways. Granted, the JavaFX team has a lot more resources and >> experience than I did all those years ago, but from my point of view, there >> are dangerous waters ahead. > > I'm sure this is the kind of discussion mostly welcomed on this list, > after all, this is what makes it a community project. > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From tom.schindl at bestsolution.at Wed Oct 17 08:32:16 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 17 Oct 2012 17:32:16 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <507ECF80.2010500@bestsolution.at> Well at J1 I showed an "IDE" (well its really a very very simple one so IDE is not the correct word) which is not using SWT nor Swing. It is built upon various eclipse technologies although: * equinox -> component model (=OSGi) * e4 -> application framework (=DI, Command, docking, ...) * jdt-core -> java dev tooling (=compiler, error reporting, auto-complete) * orion -> editor written in JavaScript You can see those in action in this video http://tomsondev.bestsolution.at/2012/10/04/eclipse-techs-on-steroids/ all sources are available as opensource (EPL) from my github repository at https://github.com/tomsontom/fx-ide. The only thing JavaFX misses at the moment to write an IDE is a rich text component which Eclipse (StyledText-Widget) and Netbeans have. Tom Am 17.10.12 17:21, schrieb Mario Torre: > """ > This thread is interesting. I've seen at J1 some tools using JavaFX > with the SWT bridge. The Swing one will also work equally well. We > also have (we need to put some love to make it work on 2.2 > """ > > Somehow this got cut, I meant: > > This thread is interesting. I've seen at J1 some tools using JavaFX > with the SWT bridge. The Swing one will also work equally well. We > also have (we need to put some love to make it work on 2.2) that > can be used to embed Swing on top of JavaFX (the other way around). > > Cheers, > Mario > > 2012/10/17 Mario Torre : >> 2012/10/17 Mark Claassen : >>> I joined this list a few days ago because I wanted to start contributing >>> So far, I am not sure it is quite where I should be. I would like to >>> discuss more about the components (table, list boxes, ...). I am not >>> exactly sure where to do that. >> >> You just unfortunately ended up subscribing to this list in the middle >> of a storm :) >> >> But this list has been used in the past to discuss components and >> details of the implementation, so this is definitely the right place >> to start discussing those things. >> >> @Richard: Perhaps it would be more fun to simply have a list dedicated >> to flaming Oracle for supporting HTML 5 rather than JavaFX :) >> >>> However, I will add here that I started (a very short-lived) thread on the >>> netbeans user list along these lines. Basically what I was saying was that >>> Netbeans is a wonderful UI built on Swing. Could this same project be done >>> in JavaFX? Maybe not yet, but could it be in the future? It seems like >>> the JavaFX team could get a lot of advice and requirements from the >>> netbeans team. >>> >>> http://forums.netbeans.org/topic51717.html >> >> This thread is interesting. I've seen at J1 some tools using JavaFX >> with the SWT bridge. The Swing one will also work equally well. We >> also have (we need to put some love to make it work on 2.2 >> >> The big trouble is #2, this will only work if: >> >> 1. Netbeans can ship JavaFX >> 2. JavaFX is included in any major OpenJDK/JDK releases (that means, >> including distribution related IcedTea builds). >> >> For both options, JavaFX needs to be fully Open Sourced, or even >> NetBeans will fall back into non free bits, so I agree with them. >> >>> Some of the main data structures, like the ObservableList, make me cringe. >>> I created a similar structure 10 years ago and have since learned the error >>> of my ways. Granted, the JavaFX team has a lot more resources and >>> experience than I did all those years ago, but from my point of view, there >>> are dangerous waters ahead. >> >> I'm sure this is the kind of discussion mostly welcomed on this list, >> after all, this is what makes it a community project. >> >> Cheers, >> Mario >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> IcedRobot: www.icedrobot.org >> Proud GNU Classpath developer: http://www.classpath.org/ >> Read About us at: http://planet.classpath.org >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From markclaassenx at gmail.com Wed Oct 17 08:34:58 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Wed, 17 Oct 2012 11:34:58 -0400 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: I am not as concerned in the "bridge" as I am in the framework. Although I agree a bridge is necessary, and would like it to work well. My comment is more about being on a track to where someone could (eventually) build Netbeans from scratch using only JavaFX. The customized window behavior, the Drag and Drop, the little tooltip-like popup windows used in the tree renderers to show the text that is not visible because of the visible bounds of the tree, ... all of it. What about the document model? The Swing javax.swing.text.Document interface is pretty powerful. The way it seems implemented in JavaFX does not seem nearly as powerful, or as pluggable. Mark On Wed, Oct 17, 2012 at 11:21 AM, Mario Torre < neugens.limasoftware at gmail.com> wrote: > """ > This thread is interesting. I've seen at J1 some tools using JavaFX > with the SWT bridge. The Swing one will also work equally well. We > also have (we need to put some love to make it work on 2.2 > """ > > Somehow this got cut, I meant: > > This thread is interesting. I've seen at J1 some tools using JavaFX > with the SWT bridge. The Swing one will also work equally well. We > also have (we need to put some love to make it work on 2.2) that > can be used to embed Swing on top of JavaFX (the other way around). > > Cheers, > Mario > > 2012/10/17 Mario Torre : > > 2012/10/17 Mark Claassen : > >> I joined this list a few days ago because I wanted to start contributing > >> So far, I am not sure it is quite where I should be. I would like to > >> discuss more about the components (table, list boxes, ...). I am not > >> exactly sure where to do that. > > > > You just unfortunately ended up subscribing to this list in the middle > > of a storm :) > > > > But this list has been used in the past to discuss components and > > details of the implementation, so this is definitely the right place > > to start discussing those things. > > > > @Richard: Perhaps it would be more fun to simply have a list dedicated > > to flaming Oracle for supporting HTML 5 rather than JavaFX :) > > > >> However, I will add here that I started (a very short-lived) thread on > the > >> netbeans user list along these lines. Basically what I was saying was > that > >> Netbeans is a wonderful UI built on Swing. Could this same project be > done > >> in JavaFX? Maybe not yet, but could it be in the future? It seems like > >> the JavaFX team could get a lot of advice and requirements from the > >> netbeans team. > >> > >> http://forums.netbeans.org/topic51717.html > > > > This thread is interesting. I've seen at J1 some tools using JavaFX > > with the SWT bridge. The Swing one will also work equally well. We > > also have (we need to put some love to make it work on 2.2 > > > > The big trouble is #2, this will only work if: > > > > 1. Netbeans can ship JavaFX > > 2. JavaFX is included in any major OpenJDK/JDK releases (that means, > > including distribution related IcedTea builds). > > > > For both options, JavaFX needs to be fully Open Sourced, or even > > NetBeans will fall back into non free bits, so I agree with them. > > > >> Some of the main data structures, like the ObservableList, make me > cringe. > >> I created a similar structure 10 years ago and have since learned the > error > >> of my ways. Granted, the JavaFX team has a lot more resources and > >> experience than I did all those years ago, but from my point of view, > there > >> are dangerous waters ahead. > > > > I'm sure this is the kind of discussion mostly welcomed on this list, > > after all, this is what makes it a community project. > > > > Cheers, > > Mario > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > IcedRobot: www.icedrobot.org > > Proud GNU Classpath developer: http://www.classpath.org/ > > Read About us at: http://planet.classpath.org > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > From tobi at ultramixer.com Wed Oct 17 08:35:07 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 17 Oct 2012 17:35:07 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: Why should we reinvent the wheel? Oracle has shown demos for JavaFX on iOS, Android and Windows two years ago on JavaOne 2011. So there seams to be already a solution there! Where are the guys here who created these demos n JavaOne 2011? Best regards, Tobi Am 17.10.2012 um 16:39 schrieb Mario Torre : > 2012/10/17 Daniel Zwolenski : >> So Oracle as an organization doesn't think JavaFX can be a player in the >> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * >> potential* to be better. But it's a long way behind and gotten off to a >> rocky start; there's a hell of a lot of work to be done and the current >> rate, strategy and direction are not going to be nearly enough. >> >> Oracle is a big corporation with many different divisions. The left arm >> doesn't know what the right is doing. So let's put aside 'oracle' for a >> moment. I want to know: what does the JavaFX team think? Do you want to go >> up against HTML5 for the client space, or just settle for a spot on the >> fringe? > > Well, you know, somehow there is people that think HTML 5 has a market > and other people that think JavaFX is the future, perhaps those both > have a market and a future? > > It makes a lot of sense to support one product *and* the other, and it > especially makes sense to support one over the other in some context > at times: if you think rationally there are limited resources even in > huge corporations like Oracle; I can see why some management folks > make decision like this, they probably go where they think there is > money, and I can also see how they piss everybody else off by doing > this ;) > > There is only one solution for this, once the code is out, put your > own time in it to get it where nobody else has before. No, really. > Seriously. When Richard ask you to contribute, he really means it. > > And it's not about Oracle being crazy here, every Open Source project > works the same way, really. People do choices, somebody doesn't agree, > then just grab the code and fix what's wrong... > > Whoops... now I hear you say it! Where's the code? This is really a > question for Richard then :) > > But really, this is the only thing to worry about and that we need to > keep asking aloud, all the rest will come by. [1] > > Cheers, > Mario > > [1] And to be honest, I love this thread even if I think the questions > are all the other way around, because it shows there's a community out > there that really wants this code to be out sooner. > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From peter.pilgrim at gmail.com Wed Oct 17 09:01:36 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Wed, 17 Oct 2012 17:01:36 +0100 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <5983853290558174241@unknownmsgid> Richard Bair gave a presentation on rich text components vis-a-vis TextPane and TextFlow at JavaOne Supporting styles, bidirectional flow, Arabic /Hebrew maybe Chinese?, proper text wrapping and flowing around a defined area. So in affect we should be all able to write IDE in JavaFX If Kim is lurking about still on this list, he will definite understand the verbosity of the old Swing style text document Apis , I expect better with the new FX text Apis in Fx8 Sent from my iPhone 4S On 17 Oct 2012, at 16:34, Mark Claassen wrote: > I am not as concerned in the "bridge" as I am in the framework. Although I > agree a bridge is necessary, and would like it to work well. > > My comment is more about being on a track to where someone could > (eventually) build Netbeans from scratch using only JavaFX. The customized > window behavior, the Drag and Drop, the little tooltip-like popup windows > used in the tree renderers to show the text that is not visible because of > the visible bounds of the tree, ... all of it. > > What about the document model? The Swing javax.swing.text.Document > interface is pretty powerful. The way it seems implemented in JavaFX does > not seem nearly as powerful, or as pluggable. > > Mark > > On Wed, Oct 17, 2012 at 11:21 AM, Mario Torre < > neugens.limasoftware at gmail.com> wrote: > >> """ >> This thread is interesting. I've seen at J1 some tools using JavaFX >> with the SWT bridge. The Swing one will also work equally well. We >> also have (we need to put some love to make it work on 2.2 >> """ >> >> Somehow this got cut, I meant: >> >> This thread is interesting. I've seen at J1 some tools using JavaFX >> with the SWT bridge. The Swing one will also work equally well. We >> also have (we need to put some love to make it work on 2.2) that >> can be used to embed Swing on top of JavaFX (the other way around). >> >> Cheers, >> Mario >> >> 2012/10/17 Mario Torre : >>> 2012/10/17 Mark Claassen : >>>> I joined this list a few days ago because I wanted to start contributing >>>> So far, I am not sure it is quite where I should be. I would like to >>>> discuss more about the components (table, list boxes, ...). I am not >>>> exactly sure where to do that. >>> >>> You just unfortunately ended up subscribing to this list in the middle >>> of a storm :) >>> >>> But this list has been used in the past to discuss components and >>> details of the implementation, so this is definitely the right place >>> to start discussing those things. >>> >>> @Richard: Perhaps it would be more fun to simply have a list dedicated >>> to flaming Oracle for supporting HTML 5 rather than JavaFX :) >>> >>>> However, I will add here that I started (a very short-lived) thread on >> the >>>> netbeans user list along these lines. Basically what I was saying was >> that >>>> Netbeans is a wonderful UI built on Swing. Could this same project be >> done >>>> in JavaFX? Maybe not yet, but could it be in the future? It seems like >>>> the JavaFX team could get a lot of advice and requirements from the >>>> netbeans team. >>>> >>>> http://forums.netbeans.org/topic51717.html >>> >>> This thread is interesting. I've seen at J1 some tools using JavaFX >>> with the SWT bridge. The Swing one will also work equally well. We >>> also have (we need to put some love to make it work on 2.2 >>> >>> The big trouble is #2, this will only work if: >>> >>> 1. Netbeans can ship JavaFX >>> 2. JavaFX is included in any major OpenJDK/JDK releases (that means, >>> including distribution related IcedTea builds). >>> >>> For both options, JavaFX needs to be fully Open Sourced, or even >>> NetBeans will fall back into non free bits, so I agree with them. >>> >>>> Some of the main data structures, like the ObservableList, make me >> cringe. >>>> I created a similar structure 10 years ago and have since learned the >> error >>>> of my ways. Granted, the JavaFX team has a lot more resources and >>>> experience than I did all those years ago, but from my point of view, >> there >>>> are dangerous waters ahead. >>> >>> I'm sure this is the kind of discussion mostly welcomed on this list, >>> after all, this is what makes it a community project. >>> >>> Cheers, >>> Mario >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> IcedRobot: www.icedrobot.org >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> Read About us at: http://planet.classpath.org >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >> >> >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> IcedRobot: www.icedrobot.org >> Proud GNU Classpath developer: http://www.classpath.org/ >> Read About us at: http://planet.classpath.org >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ >> From markclaassenx at gmail.com Wed Oct 17 10:07:56 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Wed, 17 Oct 2012 13:07:56 -0400 Subject: TextField Document model Message-ID: JTextComponents (like JTextField) has a javax.swing.text.Document model that made it pretty easy to create a text field that only allowed a certain number of characters in it. Similarly, it was also easy to make a Document model that took all input, but forced characters to upper case. @Override public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { } What is there going to be in JavaFX to accomplish the same goals? Mark From david.dehaven at oracle.com Wed Oct 17 10:32:08 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 17 Oct 2012 10:32:08 -0700 Subject: Proposed changes to media Track and children In-Reply-To: References: Message-ID: <1E02346F-81D2-417F-AF3C-EB308D7CD956@oracle.com> > Option 1> > Make the following changes to Track and it's subclasses: > Changes to Track: > - Add public final Locale getLocale(), returns a Locale if one is provided by the container or null if not > - Add public final long getTrackId(), returns a unique numeric track ID that will be used by the stack to identify this specific track > - Add public final Map getMetadata(), returns any metadata specific to this Track (returned Map is an UnmodifiableMap for security) > > Changes to AudioTrack: > - getLanguage(): deprecate, "use Track.getLocale() instead." Which is all that method does now anyways. So that's essentially two votes for option 1. My time has been cut short on this project so I will go ahead and commit this change. If there are any objections please bring them up here or in JIRA and the media team can handle it. -DrD- From swpalmer at gmail.com Wed Oct 17 11:05:31 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 17 Oct 2012 14:05:31 -0400 Subject: TextField Document model In-Reply-To: References: Message-ID: <2E5466E3-F28F-47C4-B6D1-E60766CE8A0E@gmail.com> The JavaFX TextField drops the DocumentModel (which generally just gets in the way for a simple one line text field) and just does what it is supposed to. All of the properties like caretPosition and selection are as they should be, and using an event filter you can easily deal with things like making a control that forces everything to uppercase. If you want to insert a String (in this case at the caret position): String text = textField.getText(); int pos = textField.getCaretPosition(); String newString = text.subString(0,pos) + insertedText + text.substring(pos, text.length()); textField.setText(newString); textField.positionCaret(pos+insertedText.length()); In other words - very straightforward. It works simply and as expected. To limit the number of characters use an event filter and consume Key Typed events if the length is too great. I think the model used in JavaFX is a great improvement on Swing. The properties and event model make extending things relatively easy. There are still some rough edges.. but it is moving in the right direction. More importantly it is moving! Bugs submitted are reacted to quickly. Just a couple weeks ago I submitted a bug on a Saturday morning and it was evaluated and assigned within fifteen minutes! It's so encouraging to see activity on the issues I've reported. Scott On 2012-10-17, at 1:07 PM, Mark Claassen wrote: > JTextComponents (like JTextField) has a javax.swing.text.Document model > that made it pretty easy to create a text field that only allowed a certain > number of characters in it. Similarly, it was also easy to make a Document > model that took all input, but forced characters to upper case. > > @Override > public void insertString(int offs, String str, AttributeSet a) throws > BadLocationException { > > } > > What is there going to be in JavaFX to accomplish the same goals? > > Mark From java.whoover at gmail.com Wed Oct 17 11:13:18 2012 From: java.whoover at gmail.com (Will Hoover) Date: Wed, 17 Oct 2012 14:13:18 -0400 Subject: TextField Document model In-Reply-To: References: Message-ID: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> Have you tried: final TextField tf = new TextField() { final String restictTo = "[A-Z\\s]*"; @Override public void replaceText(int start, int end, String text) { if (matchTest(text)) { super.replaceText(start, end, text); } } @Override public void replaceSelection(String text) { if (matchTest(text)) { super.replaceSelection(text); } } private boolean matchTest(String text) { return text.isEmpty() || text.matches(restictTo); } }; -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Claassen Sent: Wednesday, October 17, 2012 1:08 PM To: openjfx-dev at openjdk.java.net Subject: TextField Document model JTextComponents (like JTextField) has a javax.swing.text.Document model that made it pretty easy to create a text field that only allowed a certain number of characters in it. Similarly, it was also easy to make a Document model that took all input, but forced characters to upper case. @Override public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { } What is there going to be in JavaFX to accomplish the same goals? Mark From markclaassenx at gmail.com Wed Oct 17 13:01:51 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Wed, 17 Oct 2012 16:01:51 -0400 Subject: ObservableList vs Models Message-ID: I really like the promise of the ObservableList, but am a bit wary of the current implementation. We have several instances in our code where we rely on unique models wrapping the same data. We can have a large list of items, and show them in a combo box, and list, and a table. Generally, only one of these is visible at a given time, but having a single backing list is very handy. Further, each list can be independently sorted and filtered via a decorator construct in the model. By tweaking the underlying list object (so it fires events) and model (so that it listens to events), we accomplished something similar to an ObservableList: * Changes to the underlying list fires events to the models * Models could then respond as appropriate, add/deleting/changing items as necessary...perhaps triggering the view to re-sort the decorator as necessary However, different from ObservableList, we can manage the side-effects...not sorting and filtering all models in an identical fashion. Is there a mechanism to do this in JavaFX? The Swing methodology seemed a nice way to do it. With ObservableLists, it seems that in the end, I don't get much. The more common / trivial case is handled. However, in the case of a our application, I will need to * Make several ObservableLists, one for each control * Manage the synchronization between these lists programmaticly by myself. Am I missing something? Is there a way to have an ObservableList listening to another ObservableList, so that list #2 can notice the updates without forcing the sort order and filtering on list #1? Or am I just going to end up having to cut through extra/different layers of abstraction to re-implement what I had in Swing. Mark From zonski at gmail.com Wed Oct 17 13:03:18 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 18 Oct 2012 07:03:18 +1100 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <523653E9-E2AC-4FAD-AEAA-7C5169244887@gmail.com> I tried. I'm out. You guys can breathe easy - the 'negative guy' will shut up now and leave you to your own devices. One last thing before I bow out: "For goodness sake contribute?" - I have contributed several 100 hours writing a blog on how to force JavaFX into working in an enterprise stack. All of this on weekends and in late evenings. - I have contributed long, long hours reviewing and discussing JFX on this list. As part of community discussions, many of those things have directly influenced the JFX platform. - I have contributed many hours prototyping Auto Updating code which is open source and available for review and contribution. I had no help and little response from JFX or the community on this. I identified a show stopper feature that I needed to make the solution actually work on the current platform, raised it with JFX to which the response was "I'll think about it". This was months ago - there has been silence on the topic since so little point in continuing with this contribution, making the original effort completely pointless. - I have contributed many hours working out ways to get Maven integration working - critical for enterprise adoption. I worked with other community members to find work arounds and strategies. We identified a DLL load issue. I offered to contribute the code to make this maven friendly (the response was "not our problem"). We identified a legal hurdle and I identified the line in the contract that was the problem (the response was "too hard to fix"). I wrote half the plugin, hacking around the previous issues, and asked for access to some documentation on the packaging tools or assistance in doing this (the response was silence). - I have contributed an open source wrapper around a cross-platform camera capture program that can integrate into jfx while we wait for the jfx platform to include this highly ranked feature in jira - I have contributed hundreds of hours supporting the JFX forum, fostering community growth and uptake. I am still ranked somewhere in the top 10 helpers even after not answering anything for several months. - I have contributed numerous bug submissions and feature enhancements to JIRA and commented on many more. - I have contributed to the advocacy of the JFX platform by giving a talk on it at a local JUG at the request of Jonathon Giles. - I contributed by responding to a direct request from Richard to discuss and prototype a JFX 'browser' for some conference he was doing. After kicking off the discussion with some initial emails, and starting me working on stuff, he then got distracted, failed to respond to emails and generally didn't bother following up, even just to let me know if it was/wasn't useful for his needs and whether to keep going or stop. - I have contributed ways to improve the use of JIRA, including improving the use of the voting mechanism. I contributed a dashboard but jfx couldn't be bothered to enable dashboard sharing. I then contributed the queries needed directly to Richard. (at his request) which was then ignored. - I have contributed my own development reputation with my commercial clients by championing the jfx platform to them. The one client I convinced to use the platform has been severely hampered by deployment and build issues and lack of any significant uptake of the platform (so no skilled developers available and no one interested in making the switch) and are currently evaluating a total rewrite in HTML. I look like a chump. - I have contributed a proposal to address the fact that Oracle is openly backing a competitor platform and not jfx in the enterprise space - the response was "there is no problem" and "raise a jira issue". What exactly is it you want me to "contribute for goodness sake"? Blood? Or do I need to check in to your source tree for it to count? Hot tip: you need to actually provide a clear, well documented way for people to get, build and run your code (preferably in a way that doesn't involve 16 magical steps and putting our local Dev environment at risk of getting munged - we have actual work to do that requires a stable jfx environment) if you want that to happen. "Goodness sake" is a good way of putting it since there is little other incentive for contributing. None of these contributions have had any kind of gain for me, monetary, professional or otherwise. The payoff should have been a platform I could use but that investment hasn't panned out. This dismissive comment about contributing really rams home how you, Richard, personally feel about contributions so far. Nice. Are you feeling like you're not getting enough "contributions"? Maybe you should have a look at how you've responded to the attempts (not just by me) to contribute so far. Do you think you're making it easy or rewarding to contribute? Are you supporting your contributors by clearing obstacles they identify, addressing or even responding to issues they raise (read back through the dozens of maven emails if you really think so). Based on my experiences, I would say your hearts in the right place but this is definitely not translating into anything tangible for contributors. On 18/10/2012, at 1:23 AM, Richard Bair wrote: > We are already doing everything on your list (which was pretty void of specifics). > Please list specific work projects, linked to specific JIRA issues, and vote for them and for goodness sake contribute! > > > > > On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: > >> So Oracle as an organization doesn't think JavaFX can be a player in the >> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the * >> potential* to be better. But it's a long way behind and gotten off to a >> rocky start; there's a hell of a lot of work to be done and the current >> rate, strategy and direction are not going to be nearly enough. >> >> Oracle is a big corporation with many different divisions. The left arm >> doesn't know what the right is doing. So let's put aside 'oracle' for a >> moment. I want to know: what does the JavaFX team think? Do you want to go >> up against HTML5 for the client space, or just settle for a spot on the >> fringe? >> >> Below is what I propose. >> >> This proposal needs the full backing of the JavaFX team and management. >> Specifically it needs: >> >> 1. Belief that JavaFX can and should be the *number one* client >> development platform for enterprise. >> 2. Recognition that the current strategy will not make that happen. >> 3. Resources (aka people) allocated to the working group outlined below. >> These people must have enough influence in the JFX platform to legitimately >> be able to influence the direction as needed. >> 4. Commitment to supporting this working group fully and implementing >> the strategies and recommendations that come out of it as a high priority >> 5. A sense of urgency, and a proactive pursuit of achieving these goals >> with a well defined timeline (i.e. "resources will be allocated by November >> 2012" not "we're working on it"). >> >> In my opinion, all of these must be met 100%. Otherwise there is no point >> starting at all and better to let it go and leave the enterprise space to >> other players like HTML5 as 'Oracle' is suggesting. This is your call. >> >> I believe JavaFX can be the best platform for client-side enterprise >> application development, capitalising-on, and adding-to Java's dominance in >> server side enterprise development. >> >> Do you? >> >> >> *Proposal to form a working group for JavaFX in the enterprise* >> >> Mission: >> >> - to position JavaFX as *the* dominant client-side development platform >> for enterprise/business applications >> >> >> Members: >> >> - a combination of paid Oracle JavaFX team members, and community >> participants. The Oracle members must have the ability to access senior >> JavaFX management and technical decision makers, and as such influence the >> road map and direction of the JavaFX platform. Community members will be >> those with a background and experience in the enterprise space and who are >> committed to making JavaFX the platform of choice in this space. >> >> >> Responsibilities: >> >> - Continuously identify improvements to the JavaFX platform that are >> needed to ensure adoption by enterprise; drive the inclusion of these into >> the JavaFX platform. >> >> - Continuously identify and monitor trends and developments within the >> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's >> long term viability for their needs. >> >> - Provide best practices, community/forum support, documentation, >> examples, tool add-ons, frameworks and other aids for integrating JavaFX >> into popular enterprise technology stacks >> >> - Provide advocacy, publicity and drive general engagement and outreach >> programs for the adoption of JavaFX in the enterprise. >> >> >> Objectives: >> >> Objectives will be determined by the working group once formed, however >> initial objectives will likely include the following: >> >> - Review the current deployment/distribution options for JavaFX and >> determine ways to improve this to make it competitive with other popular >> enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise >> OS' and platforms >> >> - Identify the most popular enterprise build and development tools and >> determine a strategy for making JavaFX integrate into these >> >> - Review popular trends and toolkits within competitive platforms and >> define the ideal frameworks and add-on tools needed by an enterprise client >> (e.g. form validation). Use this list of high-level requirements to >> determine the low-level JavaFX enhancements needed (e.g. allow field >> markers so that a 3rd party validation framework could leverage these). >> >> - Create a demonstration enterprise application (along the lines of >> PetClinic) demonstrating best practice for integrating JavaFX in a full, >> end-to-end JEE stack. >> >> >> Longer term objectives may include: >> >> - Develop (or foster community development of) the high-level frameworks >> that have been identified as necessary for JavaFX in the enterprise. These >> will likely be developed as third-party modules external to the JavaFX core >> framework (i.e. built on top of the features provided by the core JavaFX >> team). >> >> - Provide integration with existing or new Rapid Application Development >> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). From markclaassenx at gmail.com Wed Oct 17 13:41:03 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Wed, 17 Oct 2012 16:41:03 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> Message-ID: Thanks for the tips. The overriding method does not seem very pluggable, so I started with the event filter. I like the idea of an event filter, and I really like the how JavaFX defined the process and the order in which items will receive events. So, I quickly implemented my event filter like this: input.addEventFilter(KeyEvent. KEY_TYPED, new EventHandler() { @Override public void handle(KeyEvent t) { if (input.getText().length() >=10) t.consume(); } }); This works for typing, but, of course, I can paste whatever I wanted. (Perhaps I need to find a second filter for that? How about DnD?) All input events go through the Swing Document, so with that, there was just one method to mess with. Further, I currently have a Document implementation that takes user input and converts it to upper case. (It doesn't force the user to type in an upper case character, it just converts it if it is not.) Since, in the case of a Document, I can control exactly what the data is, this is pretty straightforward. How is that accomplished here? Consume the event, and then first a new modified copy of the original. Or do I need to start overriding various methods? On Wed, Oct 17, 2012 at 4:40 PM, Mark Claassen wrote: > Thanks for the tips. The overriding method does not seem very pluggable, > so I started with the event filter. > > I like the idea of an event filter, and I really like the how JavaFX > defined the process and the order in which items will receive events. > > So, I quickly implemented my event filter like this: > input.addEventFilter(KeyEvent.KEY_TYPED, new > EventHandler() { > @Override > public void handle(KeyEvent t) { > if (input.getText().length() >=10) > t.consume(); > } > }); > > This works for typing, but, of course, I can paste whatever I wanted. > (Perhaps I need to find a second filter for that? How about DnD?) > > All input events go through the Swing Document, so with that, there was > just one method to mess with. > > Further, I currently have a Document implementation that takes user input > and converts it to upper case. (It doesn't force the user to type in an > upper case character, it just converts it if it is not.) Since, in the > case of a Document, I can control exactly what the data is, this is pretty > straightforward. How is that accomplished here? Consume the event, and > then first a new modified copy of the original. Or do I need to start > overriding various methods? > > Mark > > > > > > > On Wed, Oct 17, 2012 at 2:13 PM, Will Hoover wrote: > >> Have you tried: >> >> final TextField tf = new TextField() { >> final String restictTo = "[A-Z\\s]*"; >> @Override >> public void replaceText(int start, int end, String text) { >> if (matchTest(text)) { >> super.replaceText(start, end, text); >> } >> } >> @Override >> public void replaceSelection(String text) { >> if (matchTest(text)) { >> super.replaceSelection(text); >> } >> } >> private boolean matchTest(String text) { >> return text.isEmpty() || text.matches(restictTo); >> } >> }; >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Claassen >> Sent: Wednesday, October 17, 2012 1:08 PM >> To: openjfx-dev at openjdk.java.net >> Subject: TextField Document model >> >> JTextComponents (like JTextField) has a javax.swing.text.Document model >> that >> made it pretty easy to create a text field that only allowed a certain >> number of characters in it. Similarly, it was also easy to make a >> Document >> model that took all input, but forced characters to upper case. >> >> @Override >> public void insertString(int offs, String str, AttributeSet a) throws >> BadLocationException { >> >> } >> >> What is there going to be in JavaFX to accomplish the same goals? >> >> Mark >> >> > From hang.vo at oracle.com Wed Oct 17 13:47:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 17 Oct 2012 20:47:57 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25434 - FindBugs issue Message-ID: <20121017204803.2DA3D473F3@hg.openjdk.java.net> Changeset: 609ede4dbba0 Author: Morris Meyer Date: 2012-10-17 16:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/609ede4dbba0 RT-25434 - FindBugs issue ! javafx-ui-common/src/com/sun/javafx/tk/ImageLoader.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageLoader.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageLoaderFactory.java From swpalmer at gmail.com Wed Oct 17 14:05:13 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 17 Oct 2012 17:05:13 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> Message-ID: Using the override mechanism that Will suggested is probably easier for converting to uppercase. final TextField allCapsTextField = new TextField() { @Override public void replaceText(int start, int end, String text) { super.replaceText(start, end, text.toUppercase()); } @Override public void replaceSelection(String text) { super.replaceSelection(text.toUppercase()); } }; or you could still use the Event Filter and handle the insertion of the characters manually if they are lowercase and then consume the event. I think that will be more work and be more error-prone though. As you mention you would have to handle pasting and drag and drop and all ugly details. Overriding seems cleaner. Perhaps you should take a look at the source code to TextInputControl. Instead of the Document they have a Content interface. Maybe you can do some of what you want by overriding getContent(). Scott On 2012-10-17, at 4:41 PM, Mark Claassen wrote: > Thanks for the tips. The overriding method does not seem very pluggable, > so I started with the event filter. > > I like the idea of an event filter, and I really like the how JavaFX > defined the process and the order in which items will receive events. > > So, I quickly implemented my event filter like this: > input.addEventFilter(KeyEvent. > KEY_TYPED, new EventHandler() { > @Override > public void handle(KeyEvent t) { > if (input.getText().length() >=10) > t.consume(); > } > }); > > This works for typing, but, of course, I can paste whatever I wanted. > (Perhaps I need to find a second filter for that? How about DnD?) > > All input events go through the Swing Document, so with that, there was > just one method to mess with. > > Further, I currently have a Document implementation that takes user input > and converts it to upper case. (It doesn't force the user to type in an > upper case character, it just converts it if it is not.) Since, in the > case of a Document, I can control exactly what the data is, this is pretty > straightforward. How is that accomplished here? Consume the event, and > then first a new modified copy of the original. Or do I need to start > overriding various methods? > > > On Wed, Oct 17, 2012 at 4:40 PM, Mark Claassen wrote: > >> Thanks for the tips. The overriding method does not seem very pluggable, >> so I started with the event filter. >> >> I like the idea of an event filter, and I really like the how JavaFX >> defined the process and the order in which items will receive events. >> >> So, I quickly implemented my event filter like this: >> input.addEventFilter(KeyEvent.KEY_TYPED, new >> EventHandler() { >> @Override >> public void handle(KeyEvent t) { >> if (input.getText().length() >=10) >> t.consume(); >> } >> }); >> >> This works for typing, but, of course, I can paste whatever I wanted. >> (Perhaps I need to find a second filter for that? How about DnD?) >> >> All input events go through the Swing Document, so with that, there was >> just one method to mess with. >> >> Further, I currently have a Document implementation that takes user input >> and converts it to upper case. (It doesn't force the user to type in an >> upper case character, it just converts it if it is not.) Since, in the >> case of a Document, I can control exactly what the data is, this is pretty >> straightforward. How is that accomplished here? Consume the event, and >> then first a new modified copy of the original. Or do I need to start >> overriding various methods? >> >> Mark >> >> >> >> >> >> >> On Wed, Oct 17, 2012 at 2:13 PM, Will Hoover wrote: >> >>> Have you tried: >>> >>> final TextField tf = new TextField() { >>> final String restictTo = "[A-Z\\s]*"; >>> @Override >>> public void replaceText(int start, int end, String text) { >>> if (matchTest(text)) { >>> super.replaceText(start, end, text); >>> } >>> } >>> @Override >>> public void replaceSelection(String text) { >>> if (matchTest(text)) { >>> super.replaceSelection(text); >>> } >>> } >>> private boolean matchTest(String text) { >>> return text.isEmpty() || text.matches(restictTo); >>> } >>> }; >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Claassen >>> Sent: Wednesday, October 17, 2012 1:08 PM >>> To: openjfx-dev at openjdk.java.net >>> Subject: TextField Document model >>> >>> JTextComponents (like JTextField) has a javax.swing.text.Document model >>> that >>> made it pretty easy to create a text field that only allowed a certain >>> number of characters in it. Similarly, it was also easy to make a >>> Document >>> model that took all input, but forced characters to upper case. >>> >>> @Override >>> public void insertString(int offs, String str, AttributeSet a) throws >>> BadLocationException { >>> >>> } >>> >>> What is there going to be in JavaFX to accomplish the same goals? >>> >>> Mark >>> >>> >> From knut.arne.vedaa at broadpark.no Wed Oct 17 14:10:52 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Wed, 17 Oct 2012 23:10:52 +0200 Subject: ObservableList vs Models In-Reply-To: References: Message-ID: <507F1EDC.70006@broadpark.no> So what you want is one single backing list, and any numbers of "views" into that list that can be independently sorted and filtered without changing or making a copy of the backing list, with these views being observable as well? I'm not sure if this would be possible, but probably the implementations of the upcoming SortedList and FilteredList (http://javafx-jira.kenai.com/browse/RT-17053) will shed some light on the issue. Perhaps someone in the know could give some info on the features of those and how and if they relate to OPs question... Knut Arne Vedaa On 17.10.2012 22:01, Mark Claassen wrote: > I really like the promise of the ObservableList, but am a bit wary of the > current implementation. > > We have several instances in our code where we rely on unique models > wrapping the same data. We can have a large list of items, and show them > in a combo box, and list, and a table. Generally, only one of these is > visible at a given time, but having a single backing list is very handy. > > Further, each list can be independently sorted and filtered via a decorator > construct in the model. > > By tweaking the underlying list object (so it fires events) and model (so > that it listens to events), we accomplished something similar to an > ObservableList: > * Changes to the underlying list fires events to the models > * Models could then respond as appropriate, add/deleting/changing items as > necessary...perhaps triggering the view to re-sort the decorator as > necessary > > However, different from ObservableList, we can manage the > side-effects...not sorting and filtering all models in an identical fashion. > > Is there a mechanism to do this in JavaFX? The Swing methodology seemed a > nice way to do it. With ObservableLists, it seems that in the end, I don't > get much. The more common / trivial case is handled. However, in the case > of a our application, I will need to > * Make several ObservableLists, one for each control > * Manage the synchronization between these lists programmaticly by myself. > > Am I missing something? Is there a way to have an ObservableList > listening to another ObservableList, so that list #2 can notice the updates > without forcing the sort order and filtering on list #1? Or am I just > going to end up having to cut through extra/different layers of abstraction > to re-implement what I had in Swing. > > Mark > From mcdonnell.john at gmail.com Wed Oct 17 14:22:02 2012 From: mcdonnell.john at gmail.com (John McDonnell) Date: Wed, 17 Oct 2012 22:22:02 +0100 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <523653E9-E2AC-4FAD-AEAA-7C5169244887@gmail.com> References: <523653E9-E2AC-4FAD-AEAA-7C5169244887@gmail.com> Message-ID: I have to say reading these emails the last week or two have been pretty depressing. I am in the middle of developing in my spare time a JavaFX UI to show as a proof of concept that JavaFX could replace out approx 10 year old swing UI, and I just don't know where I am wasting my time and I should jump ship to investigate HTML 5, or if I should just continue on. There are issues with JavaFX that have been highlighted in the last 2 weeks, and I am really not sure where this technology is going... Dan's original email in this thread pointed out a way forward, a way in which we could actually see some traction in getting things done, but all we got was the response "For goodness sake contribute?", and at the moment that appears to be the company line from Oracle. It seems like they have given us this wonderful tool in one hand but then in the other hand theres obstacles to leap through. There is an active community, as the last few weeks have shown there are plenty of people really interested in JavaFX, but when it doesn't have decent support for enterprise applications, or even proper cross platform support* why bother? * Oracle it is 2012, cross platform is no longer, Windows, Linux and Mac, it now includes handheld OS's like iOS, Android, Windows RT, etc, as a UI framework, handheld devices are no longer second class citizens, they are the core computers in use today... JavaFX 8 will be out in the middle of next year and it just seems to me that the current schedule seems too slow paced. By the time it is out, where/how strong, will other tools like HTML5 be? Will JavaFX8 still be lagging behind? Will it still have known/important problems? - Granted the boot classpath issue will be solved, but then your going to have the problem of trying to get people to return to looking at JavaFX as an alternative to HTML5. The one plus for me at the moment is I am an average Java programmer, ans so for JavaFX I don't have to learn anything too drastic in order to get something up off the ground to demo to my bosses, where as with HTML5 it will take time, theres no question that I need to invest time into learning it, but I know that that will be a skill worth investing in, where as I am starting not to see the benefits of investing time in becoming a JavaFX UI developer. If I look now at indeed.com[1] and I search "JavaFX", 56[2] Job listings, and if I search "HTML5", 9,632... John McDonnell [1] I live in Ireland, so I went with the first America Job site I found. - An Irish job site, jobs.ie has 0 JavaFX jobs :( [2] A lot of those seem to be JavaFX 1.3 jobs.... On 17 October 2012 21:03, Daniel Zwolenski wrote: > I tried. I'm out. You guys can breathe easy - the 'negative guy' will shut > up now and leave you to your own devices. > > One last thing before I bow out: > > "For goodness sake contribute?" > > - I have contributed several 100 hours writing a blog on how to force > JavaFX into working in an enterprise stack. All of this on weekends and in > late evenings. > > - I have contributed long, long hours reviewing and discussing JFX on this > list. As part of community discussions, many of those things have directly > influenced the JFX platform. > > - I have contributed many hours prototyping Auto Updating code which is > open source and available for review and contribution. I had no help and > little response from JFX or the community on this. I identified a show > stopper feature that I needed to make the solution actually work on the > current platform, raised it with JFX to which the response was "I'll think > about it". This was months ago - there has been silence on the topic since > so little point in continuing with this contribution, making the original > effort completely pointless. > > - I have contributed many hours working out ways to get Maven integration > working - critical for enterprise adoption. I worked with other community > members to find work arounds and strategies. We identified a DLL load > issue. I offered to contribute the code to make this maven friendly (the > response was "not our problem"). We identified a legal hurdle and I > identified the line in the contract that was the problem (the response was > "too hard to fix"). I wrote half the plugin, hacking around the previous > issues, and asked for access to some documentation on the packaging tools > or assistance in doing this (the response was silence). > > - I have contributed an open source wrapper around a cross-platform camera > capture program that can integrate into jfx while we wait for the jfx > platform to include this highly ranked feature in jira > > - I have contributed hundreds of hours supporting the JFX forum, fostering > community growth and uptake. I am still ranked somewhere in the top 10 > helpers even after not answering anything for several months. > > - I have contributed numerous bug submissions and feature enhancements to > JIRA and commented on many more. > > - I have contributed to the advocacy of the JFX platform by giving a talk > on it at a local JUG at the request of Jonathon Giles. > > - I contributed by responding to a direct request from Richard to discuss > and prototype a JFX 'browser' for some conference he was doing. After > kicking off the discussion with some initial emails, and starting me > working on stuff, he then got distracted, failed to respond to emails and > generally didn't bother following up, even just to let me know if it > was/wasn't useful for his needs and whether to keep going or stop. > > - I have contributed ways to improve the use of JIRA, including improving > the use of the voting mechanism. I contributed a dashboard but jfx couldn't > be bothered to enable dashboard sharing. I then contributed the queries > needed directly to Richard. (at his request) which was then ignored. > > - I have contributed my own development reputation with my commercial > clients by championing the jfx platform to them. The one client I convinced > to use the platform has been severely hampered by deployment and build > issues and lack of any significant uptake of the platform (so no skilled > developers available and no one interested in making the switch) and are > currently evaluating a total rewrite in HTML. I look like a chump. > > - I have contributed a proposal to address the fact that Oracle is openly > backing a competitor platform and not jfx in the enterprise space - the > response was "there is no problem" and "raise a jira issue". > > What exactly is it you want me to "contribute for goodness sake"? Blood? > Or do I need to check in to your source tree for it to count? Hot tip: you > need to actually provide a clear, well documented way for people to get, > build and run your code (preferably in a way that doesn't involve 16 > magical steps and putting our local Dev environment at risk of getting > munged - we have actual work to do that requires a stable jfx environment) > if you want that to happen. > > "Goodness sake" is a good way of putting it since there is little other > incentive for contributing. None of these contributions have had any kind > of gain for me, monetary, professional or otherwise. The payoff should have > been a platform I could use but that investment hasn't panned out. > > This dismissive comment about contributing really rams home how you, > Richard, personally feel about contributions so far. Nice. > > Are you feeling like you're not getting enough "contributions"? Maybe you > should have a look at how you've responded to the attempts (not just by me) > to contribute so far. Do you think you're making it easy or rewarding to > contribute? Are you supporting your contributors by clearing obstacles they > identify, addressing or even responding to issues they raise (read back > through the dozens of maven emails if you really think so). Based on my > experiences, I would say your hearts in the right place but this is > definitely not translating into anything tangible for contributors. > > > On 18/10/2012, at 1:23 AM, Richard Bair wrote: > > > We are already doing everything on your list (which was pretty void of > specifics). > > Please list specific work projects, linked to specific JIRA issues, and > vote for them and for goodness sake contribute! > > > > > > > > > > On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: > > > >> So Oracle as an organization doesn't think JavaFX can be a player in the > >> web/enterprise space and is backing HTML5. I don't agree, JavaFX has > the * > >> potential* to be better. But it's a long way behind and gotten off to a > >> rocky start; there's a hell of a lot of work to be done and the current > >> rate, strategy and direction are not going to be nearly enough. > >> > >> Oracle is a big corporation with many different divisions. The left arm > >> doesn't know what the right is doing. So let's put aside 'oracle' for a > >> moment. I want to know: what does the JavaFX team think? Do you want to > go > >> up against HTML5 for the client space, or just settle for a spot on the > >> fringe? > >> > >> Below is what I propose. > >> > >> This proposal needs the full backing of the JavaFX team and management. > >> Specifically it needs: > >> > >> 1. Belief that JavaFX can and should be the *number one* client > >> development platform for enterprise. > >> 2. Recognition that the current strategy will not make that happen. > >> 3. Resources (aka people) allocated to the working group outlined > below. > >> These people must have enough influence in the JFX platform to > legitimately > >> be able to influence the direction as needed. > >> 4. Commitment to supporting this working group fully and implementing > >> the strategies and recommendations that come out of it as a high > priority > >> 5. A sense of urgency, and a proactive pursuit of achieving these goals > >> with a well defined timeline (i.e. "resources will be allocated by > November > >> 2012" not "we're working on it"). > >> > >> In my opinion, all of these must be met 100%. Otherwise there is no > point > >> starting at all and better to let it go and leave the enterprise space > to > >> other players like HTML5 as 'Oracle' is suggesting. This is your call. > >> > >> I believe JavaFX can be the best platform for client-side enterprise > >> application development, capitalising-on, and adding-to Java's > dominance in > >> server side enterprise development. > >> > >> Do you? > >> > >> > >> *Proposal to form a working group for JavaFX in the enterprise* > >> > >> Mission: > >> > >> - to position JavaFX as *the* dominant client-side development platform > >> for enterprise/business applications > >> > >> > >> Members: > >> > >> - a combination of paid Oracle JavaFX team members, and community > >> participants. The Oracle members must have the ability to access senior > >> JavaFX management and technical decision makers, and as such influence > the > >> road map and direction of the JavaFX platform. Community members will > be > >> those with a background and experience in the enterprise space and who > are > >> committed to making JavaFX the platform of choice in this space. > >> > >> > >> Responsibilities: > >> > >> - Continuously identify improvements to the JavaFX platform that are > >> needed to ensure adoption by enterprise; drive the inclusion of these > into > >> the JavaFX platform. > >> > >> - Continuously identify and monitor trends and developments within the > >> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > >> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > >> long term viability for their needs. > >> > >> - Provide best practices, community/forum support, documentation, > >> examples, tool add-ons, frameworks and other aids for integrating > JavaFX > >> into popular enterprise technology stacks > >> > >> - Provide advocacy, publicity and drive general engagement and outreach > >> programs for the adoption of JavaFX in the enterprise. > >> > >> > >> Objectives: > >> > >> Objectives will be determined by the working group once formed, however > >> initial objectives will likely include the following: > >> > >> - Review the current deployment/distribution options for JavaFX and > >> determine ways to improve this to make it competitive with other > popular > >> enterprise client platforms (e.g. HTML+JavaScript) for primary > enterprise > >> OS' and platforms > >> > >> - Identify the most popular enterprise build and development tools and > >> determine a strategy for making JavaFX integrate into these > >> > >> - Review popular trends and toolkits within competitive platforms and > >> define the ideal frameworks and add-on tools needed by an enterprise > client > >> (e.g. form validation). Use this list of high-level requirements to > >> determine the low-level JavaFX enhancements needed (e.g. allow field > >> markers so that a 3rd party validation framework could leverage these). > >> > >> - Create a demonstration enterprise application (along the lines of > >> PetClinic) demonstrating best practice for integrating JavaFX in a > full, > >> end-to-end JEE stack. > >> > >> > >> Longer term objectives may include: > >> > >> - Develop (or foster community development of) the high-level > frameworks > >> that have been identified as necessary for JavaFX in the enterprise. > These > >> will likely be developed as third-party modules external to the JavaFX > core > >> framework (i.e. built on top of the features provided by the core > JavaFX > >> team). > >> > >> - Provide integration with existing or new Rapid Application > Development > >> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). > -- John From tom.schindl at bestsolution.at Wed Oct 17 15:00:23 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 18 Oct 2012 00:00:23 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <5983853290558174241@unknownmsgid> References: <5983853290558174241@unknownmsgid> Message-ID: <150ADA31-1C0C-431C-8B02-5786777E5DCF@bestsolution.at> The problem is that we only get a control which is able to render rich text but unfortunately no editor! To get an editor with features you see in todays IDEs is a very long way from what we get with jfx8. Tom Von meinem iPad gesendet Am 17.10.2012 um 18:01 schrieb Peter Pilgrim : > Richard Bair gave a presentation on rich text components vis-a-vis > TextPane and TextFlow at JavaOne > > Supporting styles, bidirectional flow, Arabic /Hebrew maybe Chinese?, > proper text wrapping and flowing around a defined area. > > So in affect we should be all able to write IDE in JavaFX > > If Kim is lurking about still on this list, he will definite > understand the verbosity of the old Swing style text document Apis , > I expect better with the new FX text Apis in Fx8 > > Sent from my iPhone 4S > > On 17 Oct 2012, at 16:34, Mark Claassen wrote: > >> I am not as concerned in the "bridge" as I am in the framework. Although I >> agree a bridge is necessary, and would like it to work well. >> >> My comment is more about being on a track to where someone could >> (eventually) build Netbeans from scratch using only JavaFX. The customized >> window behavior, the Drag and Drop, the little tooltip-like popup windows >> used in the tree renderers to show the text that is not visible because of >> the visible bounds of the tree, ... all of it. >> >> What about the document model? The Swing javax.swing.text.Document >> interface is pretty powerful. The way it seems implemented in JavaFX does >> not seem nearly as powerful, or as pluggable. >> >> Mark >> >> On Wed, Oct 17, 2012 at 11:21 AM, Mario Torre < >> neugens.limasoftware at gmail.com> wrote: >> >>> """ >>> This thread is interesting. I've seen at J1 some tools using JavaFX >>> with the SWT bridge. The Swing one will also work equally well. We >>> also have (we need to put some love to make it work on 2.2 >>> """ >>> >>> Somehow this got cut, I meant: >>> >>> This thread is interesting. I've seen at J1 some tools using JavaFX >>> with the SWT bridge. The Swing one will also work equally well. We >>> also have (we need to put some love to make it work on 2.2) that >>> can be used to embed Swing on top of JavaFX (the other way around). >>> >>> Cheers, >>> Mario >>> >>> 2012/10/17 Mario Torre : >>>> 2012/10/17 Mark Claassen : >>>>> I joined this list a few days ago because I wanted to start contributing >>>>> So far, I am not sure it is quite where I should be. I would like to >>>>> discuss more about the components (table, list boxes, ...). I am not >>>>> exactly sure where to do that. >>>> >>>> You just unfortunately ended up subscribing to this list in the middle >>>> of a storm :) >>>> >>>> But this list has been used in the past to discuss components and >>>> details of the implementation, so this is definitely the right place >>>> to start discussing those things. >>>> >>>> @Richard: Perhaps it would be more fun to simply have a list dedicated >>>> to flaming Oracle for supporting HTML 5 rather than JavaFX :) >>>> >>>>> However, I will add here that I started (a very short-lived) thread on >>> the >>>>> netbeans user list along these lines. Basically what I was saying was >>> that >>>>> Netbeans is a wonderful UI built on Swing. Could this same project be >>> done >>>>> in JavaFX? Maybe not yet, but could it be in the future? It seems like >>>>> the JavaFX team could get a lot of advice and requirements from the >>>>> netbeans team. >>>>> >>>>> http://forums.netbeans.org/topic51717.html >>>> >>>> This thread is interesting. I've seen at J1 some tools using JavaFX >>>> with the SWT bridge. The Swing one will also work equally well. We >>>> also have (we need to put some love to make it work on 2.2 >>>> >>>> The big trouble is #2, this will only work if: >>>> >>>> 1. Netbeans can ship JavaFX >>>> 2. JavaFX is included in any major OpenJDK/JDK releases (that means, >>>> including distribution related IcedTea builds). >>>> >>>> For both options, JavaFX needs to be fully Open Sourced, or even >>>> NetBeans will fall back into non free bits, so I agree with them. >>>> >>>>> Some of the main data structures, like the ObservableList, make me >>> cringe. >>>>> I created a similar structure 10 years ago and have since learned the >>> error >>>>> of my ways. Granted, the JavaFX team has a lot more resources and >>>>> experience than I did all those years ago, but from my point of view, >>> there >>>>> are dangerous waters ahead. >>>> >>>> I'm sure this is the kind of discussion mostly welcomed on this list, >>>> after all, this is what makes it a community project. >>>> >>>> Cheers, >>>> Mario >>>> -- >>>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>>> >>>> IcedRobot: www.icedrobot.org >>>> Proud GNU Classpath developer: http://www.classpath.org/ >>>> Read About us at: http://planet.classpath.org >>>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>>> >>>> Please, support open standards: >>>> http://endsoftpatents.org/ >>> >>> >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> IcedRobot: www.icedrobot.org >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> Read About us at: http://planet.classpath.org >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >>> From richard.bair at oracle.com Wed Oct 17 15:27:14 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 17 Oct 2012 15:27:14 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <523653E9-E2AC-4FAD-AEAA-7C5169244887@gmail.com> References: <523653E9-E2AC-4FAD-AEAA-7C5169244887@gmail.com> Message-ID: > This dismissive comment about contributing really rams home how you, Richard, personally feel about contributions so far. Nice. I'm sorry Dan, I certainly have paid attention over all this time to all the hard work and dedication you have put into JavaFX both on the forums and here. Of course I've been very grateful and very impressed by the shear passion (and length of emails!) that you generate. I certainly did not mean to say that you haven't contributed personally. What I was saying (in my clumsy way) is that we as a team are working hard on every single point you raised, and many, many other points you haven't raised. We definitely don't do everything right, but I feel we have done really very well, and the most productive way to move forward is to do those things which I mentioned (and not to you, but to everybody): file issues, become a contributor, and work with us towards solving these problems. Richard From goddard at seznam.cz Wed Oct 17 18:33:47 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Thu, 18 Oct 2012 03:33:47 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20JavaFX=20for=20the=20Enterprise=20=2D=20Working=20Group?= In-Reply-To: Message-ID: <136495.14935.49922-27526-1998047497-1350524027@seznam.cz> "I tried. I'm out. You guys can breathe easy - the 'negative guy' will shut up now and leave you to your own devices. ..." - there's JFXtras project where interesting things happen and you can actually commit the source code and have it built *and* distributed. - for now, it's better try to run jfx on devices / platforms that can run java already (meego for cells / tablets?). by doing that, one can promote jfx on mobile platforms and devices that actually *can* run it, which has much better impact overall. regards, jiri ------------ P?vodn? zpr?va ------------ Od: Richard Bair P?edm?t: Re: JavaFX for the Enterprise - Working Group Datum: 18.10.2012 00:29:13 ---------------------------------------- > This dismissive comment about contributing really rams home how you, Richard, personally feel about contributions so far. Nice. I'm sorry Dan, I certainly have paid attention over all this time to all the hard work and dedication you have put into JavaFX both on the forums and here. Of course I've been very grateful and very impressed by the shear passion (and length of emails!) that you generate. I certainly did not mean to say that you haven't contributed personally. What I was saying (in my clumsy way) is that we as a team are working hard on every single point you raised, and many, many other points you haven't raised. We definitely don't do everything right, but I feel we have done really very well, and the most productive way to move forward is to do those things which I mentioned (and not to you, but to everybody): file issues, become a contributor, and work with us towards solving these problems. Richard From martin.sladecek at oracle.com Thu Oct 18 01:50:25 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Thu, 18 Oct 2012 10:50:25 +0200 Subject: ObservableList vs Models In-Reply-To: <507F1EDC.70006@broadpark.no> References: <507F1EDC.70006@broadpark.no> Message-ID: <507FC2D1.2070409@oracle.com> Hi, with the FilteredList/SortedList from the JIRA issue below, you should be able to do it independently, as the SortedList and FilteredList will be just wrappers on top of the original list. Both wrappers will maintain the new order / filter internally by listening to it's change notifications and will not touch the original list. Regards, -Martin On 10/17/2012 11:10 PM, Knut Arne Vedaa wrote: > So what you want is one single backing list, and any numbers of > "views" into that list that can be independently sorted and filtered > without changing or making a copy of the backing list, with these > views being observable as well? > > I'm not sure if this would be possible, but probably the > implementations of the upcoming SortedList and FilteredList > (http://javafx-jira.kenai.com/browse/RT-17053) will shed some light on > the issue. > > Perhaps someone in the know could give some info on the features of > those and how and if they relate to OPs question... > > > Knut Arne Vedaa > > > On 17.10.2012 22:01, Mark Claassen wrote: >> I really like the promise of the ObservableList, but am a bit wary of >> the >> current implementation. >> >> We have several instances in our code where we rely on unique models >> wrapping the same data. We can have a large list of items, and show >> them >> in a combo box, and list, and a table. Generally, only one of these is >> visible at a given time, but having a single backing list is very handy. >> >> Further, each list can be independently sorted and filtered via a >> decorator >> construct in the model. >> >> By tweaking the underlying list object (so it fires events) and model >> (so >> that it listens to events), we accomplished something similar to an >> ObservableList: >> * Changes to the underlying list fires events to the models >> * Models could then respond as appropriate, add/deleting/changing >> items as >> necessary...perhaps triggering the view to re-sort the decorator as >> necessary >> >> However, different from ObservableList, we can manage the >> side-effects...not sorting and filtering all models in an identical >> fashion. >> >> Is there a mechanism to do this in JavaFX? The Swing methodology >> seemed a >> nice way to do it. With ObservableLists, it seems that in the end, I >> don't >> get much. The more common / trivial case is handled. However, in >> the case >> of a our application, I will need to >> * Make several ObservableLists, one for each control >> * Manage the synchronization between these lists programmaticly by >> myself. >> >> Am I missing something? Is there a way to have an ObservableList >> listening to another ObservableList, so that list #2 can notice the >> updates >> without forcing the sort order and filtering on list #1? Or am I just >> going to end up having to cut through extra/different layers of >> abstraction >> to re-implement what I had in Swing. >> >> Mark >> > From markclaassenx at gmail.com Thu Oct 18 06:32:51 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Thu, 18 Oct 2012 09:32:51 -0400 Subject: Building from source code Message-ID: I was trying to go through the process of downloading the source code, and it seems the directions are a bit out of date. The specific issue is with the developer preview binary. The instructions say to download it and unzip it. The download link ( http://www.oracle.com/technetwork/java/javafx/downloads/index.html), goes to a page where there is nothing that can be downloaded and "unzipped". Can I use the JDK7 install I already have? Or do I need to find something else? Thanks, Mark http://openjdk.java.net/projects/openjfx/getting-started.html - Download the latest JavaFX Developer Preview binary - Unzip the binary and put it in ~/closed-jfx - [snip] From goddard at seznam.cz Thu Oct 18 07:00:02 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Thu, 18 Oct 2012 16:00:02 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Re=3A=20JavaFX=20for=20the=20Enterprise=20=2D=20Working=20Group?= In-Reply-To: <136495.14935.49922-27526-1998047497-1350524027@seznam.cz> Message-ID: <136540.14885.50022-19097-1198137824-1350568802@seznam.cz> JavaFX running on a table at J1 2012 - https://twitter.com/mittie/status/258876933817896960/photo/1/large ;) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: P?edm?t: Re: Re: JavaFX for the Enterprise - Working Group Datum: 18.10.2012 03:35:55 ---------------------------------------- "I tried. I'm out. You guys can breathe easy - the 'negative guy' will shut up now and leave you to your own devices. ..." - there's JFXtras project where interesting things happen and you can actually commit the source code and have it built *and* distributed. - for now, it's better try to run jfx on devices / platforms that can run java already (meego for cells / tablets?). by doing that, one can promote jfx on mobile platforms and devices that actually *can* run it, which has much better impact overall. regards, jiri ------------ P?vodn? zpr?va ------------ Od: Richard Bair P?edm?t: Re: JavaFX for the Enterprise - Working Group Datum: 18.10.2012 00:29:13 ---------------------------------------- > This dismissive comment about contributing really rams home how you, Richard, personally feel about contributions so far. Nice. I'm sorry Dan, I certainly have paid attention over all this time to all the hard work and dedication you have put into JavaFX both on the forums and here. Of course I've been very grateful and very impressed by the shear passion (and length of emails!) that you generate. I certainly did not mean to say that you haven't contributed personally. What I was saying (in my clumsy way) is that we as a team are working hard on every single point you raised, and many, many other points you haven't raised. We definitely don't do everything right, but I feel we have done really very well, and the most productive way to move forward is to do those things which I mentioned (and not to you, but to everybody): file issues, become a contributor, and work with us towards solving these problems. Richard From kevin.rushforth at oracle.com Thu Oct 18 07:03:31 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Oct 2012 07:03:31 -0700 Subject: Building from source code In-Reply-To: References: Message-ID: <50800C33.3000101@oracle.com> We need to update the instructions, but basically all you need is a way to locate the jfxrt.jar that matches the openjfx version you are trying to build. For FX 8, you need to download the EA version of JDK8 at: http://jdk8.java.net/download.html You can use JDK7 to build openjfx...just point your JFXRT_HOME env variable to the JDK8 jre/lib directory. -- Kevin Mark Claassen wrote: > I was trying to go through the process of downloading the source code, and > it seems the directions are a bit out of date. > > The specific issue is with the developer preview binary. The instructions > say to download it and unzip it. > The download link ( > http://www.oracle.com/technetwork/java/javafx/downloads/index.html), goes > to a page where there is nothing that can be downloaded and "unzipped". > > Can I use the JDK7 install I already have? Or do I need to find something > else? > > Thanks, > Mark > > http://openjdk.java.net/projects/openjfx/getting-started.html > > - Download the latest JavaFX Developer Preview > binary > - Unzip the binary and put it in ~/closed-jfx > - [snip] > From markclaassenx at gmail.com Thu Oct 18 07:26:58 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Thu, 18 Oct 2012 10:26:58 -0400 Subject: Building from source code In-Reply-To: <50800C33.3000101@oracle.com> References: <50800C33.3000101@oracle.com> Message-ID: Thanks for the quick reply. Just to recap: I have JDK 7 on my machine. It sounds like I should be using JDK8 to play with the FX sources (which are for FX8?) Is this more what I should be doing? - *Download the latest JavaFX Developer Preview binary * - *Replace with Download JDK8* - Unzip the binary and put it in ~/closed-jfx - mkdir -p ~/open-jfx - cd ~/open-jfx - hg clone http://hg.openjdk.java.net/openjfx/2.1/master - cd master - mkdir -p artifacts/sdk/rt - *cp -r ~/closed-jfx/javafx-sdk2.1.0-beta/rt artifacts/sdk* - *Replace with cp the jfxrt.jar from JDK8 to articacts/sdk * - hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt - cd rt - Edit build-defs.xml (comment out '') - cd javafx-ui-controls - ant On Thu, Oct 18, 2012 at 10:03 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > We need to update the instructions, but basically all you need is a way to > locate the jfxrt.jar that matches the openjfx version you are trying to > build. > > For FX 8, you need to download the EA version of JDK8 at: > http://jdk8.java.net/download.**html > > You can use JDK7 to build openjfx...just point your JFXRT_HOME env > variable to the JDK8 jre/lib directory. > > -- Kevin > > > Mark Claassen wrote: > >> I was trying to go through the process of downloading the source code, and >> it seems the directions are a bit out of date. >> >> The specific issue is with the developer preview binary. The instructions >> say to download it and unzip it. >> The download link ( >> http://www.oracle.com/**technetwork/java/javafx/**downloads/index.html), >> goes >> to a page where there is nothing that can be downloaded and "unzipped". >> >> Can I use the JDK7 install I already have? Or do I need to find something >> else? >> >> Thanks, >> Mark >> >> http://openjdk.java.net/**projects/openjfx/getting-**started.html >> >> - Download the latest JavaFX Developer Preview >> binary> downloads/index.html >> > >> - Unzip the binary and put it in ~/closed-jfx >> - [snip] >> >> > From danno.ferrin at shemnon.com Thu Oct 18 08:07:16 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 18 Oct 2012 09:07:16 -0600 Subject: Building from source code In-Reply-To: References: <50800C33.3000101@oracle.com> Message-ID: If you are going to be playing with Java 8, use the JavaFX 8 repos, the 2.1 repos don't play well with Java 8 http://hg.openjdk.java.net/openjfx/8/master http://hg.openjdk.java.net/openjfx/8/master/rt If you are using a current Java 7, use the 2.2 or 2.2.4 builds (7u9 or 7u10ea respectively). http://hg.openjdk.java.net/openjfx/2.2/master http://hg.openjdk.java.net/openjfx/2.2/master/rt http://hg.openjdk.java.net/openjfx/2.2.4/master http://hg.openjdk.java.net/openjfx/2.2.4/master/rt I may be wrong on 2.2.4, did that version number get bumped with the 7u7 patch? On Thu, Oct 18, 2012 at 8:26 AM, Mark Claassen wrote: > Thanks for the quick reply. Just to recap: > I have JDK 7 on my machine. > > It sounds like I should be using JDK8 to play with the FX sources (which > are for FX8?) > Is this more what I should be doing? > > - *Download the latest JavaFX Developer Preview > binary > * > - *Replace with Download JDK8* > - Unzip the binary and put it in ~/closed-jfx > - mkdir -p ~/open-jfx > - cd ~/open-jfx > - hg clone http://hg.openjdk.java.net/openjfx/2.1/master > - cd master > - mkdir -p artifacts/sdk/rt > - *cp -r ~/closed-jfx/javafx-sdk2.1.0-beta/rt artifacts/sdk* > - *Replace with cp the jfxrt.jar from JDK8 to articacts/sdk > * > - hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt > - cd rt > - Edit build-defs.xml (comment out ' name="javac.debuglevel" from="${ant.project.name}.javac.debuglevel" > silent="true" override="true"/>') > - cd javafx-ui-controls > - ant > > > > > On Thu, Oct 18, 2012 at 10:03 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > > We need to update the instructions, but basically all you need is a way > to > > locate the jfxrt.jar that matches the openjfx version you are trying to > > build. > > > > For FX 8, you need to download the EA version of JDK8 at: > > http://jdk8.java.net/download.**html > > > > > You can use JDK7 to build openjfx...just point your JFXRT_HOME env > > variable to the JDK8 jre/lib directory. > > > > -- Kevin > > > > > > Mark Claassen wrote: > > > >> I was trying to go through the process of downloading the source code, > and > >> it seems the directions are a bit out of date. > >> > >> The specific issue is with the developer preview binary. The > instructions > >> say to download it and unzip it. > >> The download link ( > >> http://www.oracle.com/**technetwork/java/javafx/**downloads/index.html< > http://www.oracle.com/technetwork/java/javafx/downloads/index.html>), > >> goes > >> to a page where there is nothing that can be downloaded and "unzipped". > >> > >> Can I use the JDK7 install I already have? Or do I need to find > something > >> else? > >> > >> Thanks, > >> Mark > >> > >> http://openjdk.java.net/**projects/openjfx/getting-**started.html< > http://openjdk.java.net/projects/openjfx/getting-started.html> > >> > >> - Download the latest JavaFX Developer Preview > >> binary >> downloads/index.html< > http://www.oracle.com/technetwork/java/javafx/downloads/index.html> > >> > > >> - Unzip the binary and put it in ~/closed-jfx > >> - [snip] > >> > >> > > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From kevin.rushforth at oracle.com Thu Oct 18 08:38:38 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Oct 2012 08:38:38 -0700 Subject: Building from source code In-Reply-To: References: <50800C33.3000101@oracle.com> Message-ID: <5080227E.5050103@oracle.com> Yes, if you use FX 8, you need the jfxrt.jar from JDK8. Most developers should just use this. The JDK 7u10 / FX 2.2.4 release will soon be renamed to 7u12 / 2.2.6. If you download the latest EA build of jdk7u it will contain the corresponding FX bits (which today will be 7u10-b09). -- Kevin Danno Ferrin wrote: > If you are going to be playing with Java 8, use the JavaFX 8 repos, the 2.1 > repos don't play well with Java 8 > > http://hg.openjdk.java.net/openjfx/8/master > http://hg.openjdk.java.net/openjfx/8/master/rt > > If you are using a current Java 7, use the 2.2 or 2.2.4 builds (7u9 or > 7u10ea respectively). > > http://hg.openjdk.java.net/openjfx/2.2/master > http://hg.openjdk.java.net/openjfx/2.2/master/rt > > http://hg.openjdk.java.net/openjfx/2.2.4/master > http://hg.openjdk.java.net/openjfx/2.2.4/master/rt > > I may be wrong on 2.2.4, did that version number get bumped with the 7u7 > patch? > > On Thu, Oct 18, 2012 at 8:26 AM, Mark Claassen wrote: > > >> Thanks for the quick reply. Just to recap: >> I have JDK 7 on my machine. >> >> It sounds like I should be using JDK8 to play with the FX sources (which >> are for FX8?) >> Is this more what I should be doing? >> >> - *Download the latest JavaFX Developer Preview >> binary >> * >> - *Replace with Download JDK8* >> - Unzip the binary and put it in ~/closed-jfx >> - mkdir -p ~/open-jfx >> - cd ~/open-jfx >> - hg clone http://hg.openjdk.java.net/openjfx/2.1/master >> - cd master >> - mkdir -p artifacts/sdk/rt >> - *cp -r ~/closed-jfx/javafx-sdk2.1.0-beta/rt artifacts/sdk* >> - *Replace with cp the jfxrt.jar from JDK8 to articacts/sdk >> * >> - hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt >> - cd rt >> - Edit build-defs.xml (comment out '> name="javac.debuglevel" from="${ant.project.name}.javac.debuglevel" >> silent="true" override="true"/>') >> - cd javafx-ui-controls >> - ant >> >> >> >> >> On Thu, Oct 18, 2012 at 10:03 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >> >>> We need to update the instructions, but basically all you need is a way >>> >> to >> >>> locate the jfxrt.jar that matches the openjfx version you are trying to >>> build. >>> >>> For FX 8, you need to download the EA version of JDK8 at: >>> http://jdk8.java.net/download.**html >> >>> >>> You can use JDK7 to build openjfx...just point your JFXRT_HOME env >>> variable to the JDK8 jre/lib directory. >>> >>> -- Kevin >>> >>> >>> Mark Claassen wrote: >>> >>> >>>> I was trying to go through the process of downloading the source code, >>>> >> and >> >>>> it seems the directions are a bit out of date. >>>> >>>> The specific issue is with the developer preview binary. The >>>> >> instructions >> >>>> say to download it and unzip it. >>>> The download link ( >>>> http://www.oracle.com/**technetwork/java/javafx/**downloads/index.html< >>>> >> http://www.oracle.com/technetwork/java/javafx/downloads/index.html>), >> >>>> goes >>>> to a page where there is nothing that can be downloaded and "unzipped". >>>> >>>> Can I use the JDK7 install I already have? Or do I need to find >>>> >> something >> >>>> else? >>>> >>>> Thanks, >>>> Mark >>>> >>>> http://openjdk.java.net/**projects/openjfx/getting-**started.html< >>>> >> http://openjdk.java.net/projects/openjfx/getting-started.html> >> >>>> - Download the latest JavaFX Developer Preview >>>> binary>>> downloads/index.html< >>>> >> http://www.oracle.com/technetwork/java/javafx/downloads/index.html> >> >>>> - Unzip the binary and put it in ~/closed-jfx >>>> - [snip] >>>> >>>> >>>> > > > > From richard.bair at oracle.com Thu Oct 18 09:05:35 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 09:05:35 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <03667C4B-28A1-4322-871A-8D504BBD8101@oracle.com> Dan's email deserves more than a flippant response, for which I apologize. That's what I get for trying to respond while on the train (and having only a phone as an input device). I quickly mentioned, in essence "hey, we're on it". I'm sorry for the misunderstanding, I know passions are running high at this time, and I don't want to be misunderstood. > Oracle is a big corporation with many different divisions. The left arm > doesn't know what the right is doing. So let's put aside 'oracle' for a > moment. I want to know: what does the JavaFX team think? Do you want to go > up against HTML5 for the client space, or just settle for a spot on the > fringe? This is true. Oracle is a big company, and sometimes the way things are phrased in a press release are not to the liking of each constituency. That is to be expected. It goes without saying that the Java Team (not just the JavaFX Team) wants to see Java client be successful. It also goes without saying that an "official Oracle spokesperson" (I would be one of those) should be very careful about making any public statement regarding strategy or position that hasn't been previously vetted by one's senior management. We just had a JavaOne conference, in which we clearly stated that JavaFX for enterprise application client development, and for embedded consumer device development, are areas that we think we can compete and win in, and which also offer a lot of value to developers above and beyond current options. > 1. Belief that JavaFX can and should be the *number one* client > development platform for enterprise. > 2. Recognition that the current strategy will not make that happen. > 3. Resources (aka people) allocated to the working group outlined below. > These people must have enough influence in the JFX platform to legitimately > be able to influence the direction as needed. A working group is neither needed nor would it be productive. The reality is, the JavaFX team is devoted to producing the best platform that exists. It is the sole reason that Jasper and I work on this project. We are not in this for money (banking is much more lucrative), neither are we in it for job security (Android would have been a better bet, and we've had numerous opportunities to work for Google). We're doing this because we believe that all other client application development options stink, and we want to create the very best platform available. Creating a working group would be pointless. That group already exists, and it is this mailing list. I see no value is creating a separate group to go off and brainstorm solutions. We know the problems, we (like any other development project in the history of the world) have multiple competing constraints and resourcing limitations (or limitations on the ability to manage large numbers of production teams). Jasper and I have complete influence within the JavaFX team. But within a company like Oracle (or Sun, or IBM, or HP, Microsoft, or any other large company), certain functions (like Legal, Security, etc) are housed in cross-cutting branches at Oracle, not under the direction of this, or any other team. As such, there are limitations in what we can do. People have asked for legal assurance that this usage or that usage of JavaFX with Maven isn't going to run afoul of Oracle legal. It is not in the power of this team to answer that question. Does that cause us difficulties -- yes of course it does, but such things are a fact of life in a large organization. > 4. Commitment to supporting this working group fully and implementing > the strategies and recommendations that come out of it as a high priority > 5. A sense of urgency, and a proactive pursuit of achieving these goals > with a well defined timeline (i.e. "resources will be allocated by November > 2012" not "we're working on it"). You will not find anybody who has a higher sense of urgency than I do, either inside or outside Oracle. The problem is, the list of things that any one individual feels is P1 priority is going to be different. I also have the benefit of knowing a number of commercial operations that are using JavaFX and what their needs are, along with the existing set of Swing / SWT customers and what their needs are for JavaFX to be useful for them. It is not possible to have everything be a P1. I undoubtedly have, and will continue to, make decisions and priority calls that people don't agree with. That is the nature of the job, I cannot please everybody. > - Continuously identify improvements to the JavaFX platform that are > needed to ensure adoption by enterprise; drive the inclusion of these into > the JavaFX platform. We do this all the time. In fact, we have an entire team paid to do nothing but "inbound marketing", where they engage customers and help develop the roadmap. In addition, we have this list where anybody can express their needs, and many of these are incorporated into our plans. There is also my own oracle email address, through which many contacts are made (and as a result, my ability to parse and respond to everything is very difficult). Jasper and I are both enterprise app developers (although it has been nigh unto 7 years since we were doing other than toolkit development, a fact we both are keenly aware of). And let me reiterate -- we have this list. We have twitter. There's no lack of input from all across the spectrum. I am opposed to having a working group of exclusive membership. I believe in keeping this open for everybody's input. As a result, we're going to have a lot of choices to make, some you will like, some you won't. > - Continuously identify and monitor trends and developments within the > enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > long term viability for their needs. We do this on a daily basis. We look at a heck of a lot more than just HTML5 and .NET. We're aware of all the latest fads in development on the EE side, we've even built prototypes to compare how this works relative to FX. > - Provide best practices, community/forum support, documentation, > examples, tool add-ons, frameworks and other aids for integrating JavaFX > into popular enterprise technology stacks We have a documentation team devoted to writing documentation. Is there specific documentation you want that isn't provided? I can hook you up with the doc writers and you can work with them. We'll link to your blogs (which we've done!) or anything else. > - Provide advocacy, publicity and drive general engagement and outreach > programs for the adoption of JavaFX in the enterprise. Here again, we have a whole "outbound marketing" and evangelism group who is devoted to this. Stephen Chin and Jim Weaver among them. Stephen is now on a motor-bike across Europe tour hitting ever JUG and gathering of Java developers he can find. Like I said, we're doing all this stuff, with paid people, who's full time job it is to do these things. And they're good at it. > - Review the current deployment/distribution options for JavaFX and > determine ways to improve this to make it competitive with other popular > enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise > OS' and platforms We could (and should) have a whole thread on this subject. > - Review popular trends and toolkits within competitive platforms and > define the ideal frameworks and add-on tools needed by an enterprise client > (e.g. form validation). Use this list of high-level requirements to > determine the low-level JavaFX enhancements needed (e.g. allow field > markers so that a 3rd party validation framework could leverage these). We've already had threads on validation, but again, the right way to do this is to have such conversations in a thread on this mailing list, it is not required that we have a separate working group to identify these things. The issue that I think sometimes we run into, is that although all these things are good and perhaps even critical, there are other things that are also good and critical that we are working on, such as accessibility and internationalization. So sometimes threads on a mailing list don't end in concrete work being done, when that thread is not related to one of the things we're signed up to deliver on. This is natural and to be expected. The way to move forward when it isn't on our list for the next release, is to have the discussion; produce the APIs, tests, and implementation; sign the contributor agreement and attach to JIRA. > - Create a demonstration enterprise application (along the lines of > PetClinic) demonstrating best practice for integrating JavaFX in a full, > end-to-end JEE stack. In fact, we released the "DataApp" also known as "Henley Car Sales" with JavaFX 2.0 for exactly this reason. It uses EE 6 on the backend, Jersey Client on the backend and frontend, and JavaFX on the front end. There is a lot of scope to extend and work on this. In fact, it is BSD. As I mentioned in my poorly worded and perhaps flippant response, we're already engaged in each of these areas, and forming a new working group is neither necessary nor would it actually help move the ball forward. The best things to do are to discuss issues on this mailing list, add issues to JIRA and lobby other developers to support those items, and if possible contribute complete solutions for things that we don't have on our deliverable list. Richard From phidias51 at gmail.com Thu Oct 18 10:03:45 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 18 Oct 2012 10:03:45 -0700 Subject: Maven support In-Reply-To: References: Message-ID: I created the following issue based on this discussion: http://javafx-jira.kenai.com/browse/RT-25723 Feel free to leave your comments on it, and please vote for it, and watch it. Cheers, Mark From roman at kennke.org Thu Oct 18 10:12:52 2012 From: roman at kennke.org (Roman Kennke) Date: Thu, 18 Oct 2012 19:12:52 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <03667C4B-28A1-4322-871A-8D504BBD8101@oracle.com> References: <03667C4B-28A1-4322-871A-8D504BBD8101@oracle.com> Message-ID: <1350580372.2097.111.camel@mercury> And 'we' in this context means (should mean... that's the goal we need to strive for) 'we the JavaFX community', not 'we Oracle' or 'we non-Oracle'. Roman Am Donnerstag, den 18.10.2012, 09:05 -0700 schrieb Richard Bair: > Dan's email deserves more than a flippant response, for which I apologize. That's what I get for trying to respond while on the train (and having only a phone as an input device). I quickly mentioned, in essence "hey, we're on it". I'm sorry for the misunderstanding, I know passions are running high at this time, and I don't want to be misunderstood. > > > Oracle is a big corporation with many different divisions. The left arm > > doesn't know what the right is doing. So let's put aside 'oracle' for a > > moment. I want to know: what does the JavaFX team think? Do you want to go > > up against HTML5 for the client space, or just settle for a spot on the > > fringe? > > This is true. Oracle is a big company, and sometimes the way things are phrased in a press release are not to the liking of each constituency. That is to be expected. It goes without saying that the Java Team (not just the JavaFX Team) wants to see Java client be successful. It also goes without saying that an "official Oracle spokesperson" (I would be one of those) should be very careful about making any public statement regarding strategy or position that hasn't been previously vetted by one's senior management. We just had a JavaOne conference, in which we clearly stated that JavaFX for enterprise application client development, and for embedded consumer device development, are areas that we think we can compete and win in, and which also offer a lot of value to developers above and beyond current options. > > > 1. Belief that JavaFX can and should be the *number one* client > > development platform for enterprise. > > 2. Recognition that the current strategy will not make that happen. > > 3. Resources (aka people) allocated to the working group outlined below. > > These people must have enough influence in the JFX platform to legitimately > > be able to influence the direction as needed. > > A working group is neither needed nor would it be productive. The reality is, the JavaFX team is devoted to producing the best platform that exists. It is the sole reason that Jasper and I work on this project. We are not in this for money (banking is much more lucrative), neither are we in it for job security (Android would have been a better bet, and we've had numerous opportunities to work for Google). We're doing this because we believe that all other client application development options stink, and we want to create the very best platform available. > > Creating a working group would be pointless. That group already exists, and it is this mailing list. I see no value is creating a separate group to go off and brainstorm solutions. We know the problems, we (like any other development project in the history of the world) have multiple competing constraints and resourcing limitations (or limitations on the ability to manage large numbers of production teams). Jasper and I have complete influence within the JavaFX team. But within a company like Oracle (or Sun, or IBM, or HP, Microsoft, or any other large company), certain functions (like Legal, Security, etc) are housed in cross-cutting branches at Oracle, not under the direction of this, or any other team. As such, there are limitations in what we can do. People have asked for legal assurance that this usage or that usage of JavaFX with Maven isn't going to run afoul of Oracle legal. It is not in the power of this team to answer that question. Does that cause us difficulties -- yes of course it does, but such things are a fact of life in a large organization. > > > 4. Commitment to supporting this working group fully and implementing > > the strategies and recommendations that come out of it as a high priority > > 5. A sense of urgency, and a proactive pursuit of achieving these goals > > with a well defined timeline (i.e. "resources will be allocated by November > > 2012" not "we're working on it"). > > You will not find anybody who has a higher sense of urgency than I do, either inside or outside Oracle. The problem is, the list of things that any one individual feels is P1 priority is going to be different. I also have the benefit of knowing a number of commercial operations that are using JavaFX and what their needs are, along with the existing set of Swing / SWT customers and what their needs are for JavaFX to be useful for them. It is not possible to have everything be a P1. I undoubtedly have, and will continue to, make decisions and priority calls that people don't agree with. That is the nature of the job, I cannot please everybody. > > > - Continuously identify improvements to the JavaFX platform that are > > needed to ensure adoption by enterprise; drive the inclusion of these into > > the JavaFX platform. > > We do this all the time. In fact, we have an entire team paid to do nothing but "inbound marketing", where they engage customers and help develop the roadmap. In addition, we have this list where anybody can express their needs, and many of these are incorporated into our plans. There is also my own oracle email address, through which many contacts are made (and as a result, my ability to parse and respond to everything is very difficult). Jasper and I are both enterprise app developers (although it has been nigh unto 7 years since we were doing other than toolkit development, a fact we both are keenly aware of). And let me reiterate -- we have this list. We have twitter. There's no lack of input from all across the spectrum. > > I am opposed to having a working group of exclusive membership. I believe in keeping this open for everybody's input. As a result, we're going to have a lot of choices to make, some you will like, some you won't. > > > - Continuously identify and monitor trends and developments within the > > enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > > ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's > > long term viability for their needs. > > We do this on a daily basis. We look at a heck of a lot more than just HTML5 and .NET. We're aware of all the latest fads in development on the EE side, we've even built prototypes to compare how this works relative to FX. > > > - Provide best practices, community/forum support, documentation, > > examples, tool add-ons, frameworks and other aids for integrating JavaFX > > into popular enterprise technology stacks > > We have a documentation team devoted to writing documentation. Is there specific documentation you want that isn't provided? I can hook you up with the doc writers and you can work with them. We'll link to your blogs (which we've done!) or anything else. > > > - Provide advocacy, publicity and drive general engagement and outreach > > programs for the adoption of JavaFX in the enterprise. > > Here again, we have a whole "outbound marketing" and evangelism group who is devoted to this. Stephen Chin and Jim Weaver among them. Stephen is now on a motor-bike across Europe tour hitting ever JUG and gathering of Java developers he can find. Like I said, we're doing all this stuff, with paid people, who's full time job it is to do these things. And they're good at it. > > > - Review the current deployment/distribution options for JavaFX and > > determine ways to improve this to make it competitive with other popular > > enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise > > OS' and platforms > > We could (and should) have a whole thread on this subject. > > > - Review popular trends and toolkits within competitive platforms and > > define the ideal frameworks and add-on tools needed by an enterprise client > > (e.g. form validation). Use this list of high-level requirements to > > determine the low-level JavaFX enhancements needed (e.g. allow field > > markers so that a 3rd party validation framework could leverage these). > > We've already had threads on validation, but again, the right way to do this is to have such conversations in a thread on this mailing list, it is not required that we have a separate working group to identify these things. The issue that I think sometimes we run into, is that although all these things are good and perhaps even critical, there are other things that are also good and critical that we are working on, such as accessibility and internationalization. So sometimes threads on a mailing list don't end in concrete work being done, when that thread is not related to one of the things we're signed up to deliver on. This is natural and to be expected. The way to move forward when it isn't on our list for the next release, is to have the discussion; produce the APIs, tests, and implementation; sign the contributor agreement and attach to JIRA. > > > - Create a demonstration enterprise application (along the lines of > > PetClinic) demonstrating best practice for integrating JavaFX in a full, > > end-to-end JEE stack. > > In fact, we released the "DataApp" also known as "Henley Car Sales" with JavaFX 2.0 for exactly this reason. It uses EE 6 on the backend, Jersey Client on the backend and frontend, and JavaFX on the front end. There is a lot of scope to extend and work on this. In fact, it is BSD. > > As I mentioned in my poorly worded and perhaps flippant response, we're already engaged in each of these areas, and forming a new working group is neither necessary nor would it actually help move the ball forward. The best things to do are to discuss issues on this mailing list, add issues to JIRA and lobby other developers to support those items, and if possible contribute complete solutions for things that we don't have on our deliverable list. > > Richard From richard.bair at oracle.com Thu Oct 18 10:30:43 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 10:30:43 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <1350580372.2097.111.camel@mercury> References: <03667C4B-28A1-4322-871A-8D504BBD8101@oracle.com> <1350580372.2097.111.camel@mercury> Message-ID: Absolutely. On Oct 18, 2012, at 10:12 AM, Roman Kennke wrote: > And 'we' in this context means (should mean... that's the goal we need > to strive for) 'we the JavaFX community', not 'we Oracle' or 'we > non-Oracle'. > > Roman > > Am Donnerstag, den 18.10.2012, 09:05 -0700 schrieb Richard Bair: >> Dan's email deserves more than a flippant response, for which I apologize. That's what I get for trying to respond while on the train (and having only a phone as an input device). I quickly mentioned, in essence "hey, we're on it". I'm sorry for the misunderstanding, I know passions are running high at this time, and I don't want to be misunderstood. >> >>> Oracle is a big corporation with many different divisions. The left arm >>> doesn't know what the right is doing. So let's put aside 'oracle' for a >>> moment. I want to know: what does the JavaFX team think? Do you want to go >>> up against HTML5 for the client space, or just settle for a spot on the >>> fringe? >> >> This is true. Oracle is a big company, and sometimes the way things are phrased in a press release are not to the liking of each constituency. That is to be expected. It goes without saying that the Java Team (not just the JavaFX Team) wants to see Java client be successful. It also goes without saying that an "official Oracle spokesperson" (I would be one of those) should be very careful about making any public statement regarding strategy or position that hasn't been previously vetted by one's senior management. We just had a JavaOne conference, in which we clearly stated that JavaFX for enterprise application client development, and for embedded consumer device development, are areas that we think we can compete and win in, and which also offer a lot of value to developers above and beyond current options. >> >>> 1. Belief that JavaFX can and should be the *number one* client >>> development platform for enterprise. >>> 2. Recognition that the current strategy will not make that happen. >>> 3. Resources (aka people) allocated to the working group outlined below. >>> These people must have enough influence in the JFX platform to legitimately >>> be able to influence the direction as needed. >> >> A working group is neither needed nor would it be productive. The reality is, the JavaFX team is devoted to producing the best platform that exists. It is the sole reason that Jasper and I work on this project. We are not in this for money (banking is much more lucrative), neither are we in it for job security (Android would have been a better bet, and we've had numerous opportunities to work for Google). We're doing this because we believe that all other client application development options stink, and we want to create the very best platform available. >> >> Creating a working group would be pointless. That group already exists, and it is this mailing list. I see no value is creating a separate group to go off and brainstorm solutions. We know the problems, we (like any other development project in the history of the world) have multiple competing constraints and resourcing limitations (or limitations on the ability to manage large numbers of production teams). Jasper and I have complete influence within the JavaFX team. But within a company like Oracle (or Sun, or IBM, or HP, Microsoft, or any other large company), certain functions (like Legal, Security, etc) are housed in cross-cutting branches at Oracle, not under the direction of this, or any other team. As such, there are limitations in what we can do. People have asked for legal assurance that this usage or that usage of JavaFX with Maven isn't going to run afoul of Oracle legal. It is not in the power of this team to answer that question. Does that cause us difficulties -- yes of course it does, but such things are a fact of life in a large organization. >> >>> 4. Commitment to supporting this working group fully and implementing >>> the strategies and recommendations that come out of it as a high priority >>> 5. A sense of urgency, and a proactive pursuit of achieving these goals >>> with a well defined timeline (i.e. "resources will be allocated by November >>> 2012" not "we're working on it"). >> >> You will not find anybody who has a higher sense of urgency than I do, either inside or outside Oracle. The problem is, the list of things that any one individual feels is P1 priority is going to be different. I also have the benefit of knowing a number of commercial operations that are using JavaFX and what their needs are, along with the existing set of Swing / SWT customers and what their needs are for JavaFX to be useful for them. It is not possible to have everything be a P1. I undoubtedly have, and will continue to, make decisions and priority calls that people don't agree with. That is the nature of the job, I cannot please everybody. >> >>> - Continuously identify improvements to the JavaFX platform that are >>> needed to ensure adoption by enterprise; drive the inclusion of these into >>> the JavaFX platform. >> >> We do this all the time. In fact, we have an entire team paid to do nothing but "inbound marketing", where they engage customers and help develop the roadmap. In addition, we have this list where anybody can express their needs, and many of these are incorporated into our plans. There is also my own oracle email address, through which many contacts are made (and as a result, my ability to parse and respond to everything is very difficult). Jasper and I are both enterprise app developers (although it has been nigh unto 7 years since we were doing other than toolkit development, a fact we both are keenly aware of). And let me reiterate -- we have this list. We have twitter. There's no lack of input from all across the spectrum. >> >> I am opposed to having a working group of exclusive membership. I believe in keeping this open for everybody's input. As a result, we're going to have a lot of choices to make, some you will like, some you won't. >> >>> - Continuously identify and monitor trends and developments within the >>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >>> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's >>> long term viability for their needs. >> >> We do this on a daily basis. We look at a heck of a lot more than just HTML5 and .NET. We're aware of all the latest fads in development on the EE side, we've even built prototypes to compare how this works relative to FX. >> >>> - Provide best practices, community/forum support, documentation, >>> examples, tool add-ons, frameworks and other aids for integrating JavaFX >>> into popular enterprise technology stacks >> >> We have a documentation team devoted to writing documentation. Is there specific documentation you want that isn't provided? I can hook you up with the doc writers and you can work with them. We'll link to your blogs (which we've done!) or anything else. >> >>> - Provide advocacy, publicity and drive general engagement and outreach >>> programs for the adoption of JavaFX in the enterprise. >> >> Here again, we have a whole "outbound marketing" and evangelism group who is devoted to this. Stephen Chin and Jim Weaver among them. Stephen is now on a motor-bike across Europe tour hitting ever JUG and gathering of Java developers he can find. Like I said, we're doing all this stuff, with paid people, who's full time job it is to do these things. And they're good at it. >> >>> - Review the current deployment/distribution options for JavaFX and >>> determine ways to improve this to make it competitive with other popular >>> enterprise client platforms (e.g. HTML+JavaScript) for primary enterprise >>> OS' and platforms >> >> We could (and should) have a whole thread on this subject. >> >>> - Review popular trends and toolkits within competitive platforms and >>> define the ideal frameworks and add-on tools needed by an enterprise client >>> (e.g. form validation). Use this list of high-level requirements to >>> determine the low-level JavaFX enhancements needed (e.g. allow field >>> markers so that a 3rd party validation framework could leverage these). >> >> We've already had threads on validation, but again, the right way to do this is to have such conversations in a thread on this mailing list, it is not required that we have a separate working group to identify these things. The issue that I think sometimes we run into, is that although all these things are good and perhaps even critical, there are other things that are also good and critical that we are working on, such as accessibility and internationalization. So sometimes threads on a mailing list don't end in concrete work being done, when that thread is not related to one of the things we're signed up to deliver on. This is natural and to be expected. The way to move forward when it isn't on our list for the next release, is to have the discussion; produce the APIs, tests, and implementation; sign the contributor agreement and attach to JIRA. >> >>> - Create a demonstration enterprise application (along the lines of >>> PetClinic) demonstrating best practice for integrating JavaFX in a full, >>> end-to-end JEE stack. >> >> In fact, we released the "DataApp" also known as "Henley Car Sales" with JavaFX 2.0 for exactly this reason. It uses EE 6 on the backend, Jersey Client on the backend and frontend, and JavaFX on the front end. There is a lot of scope to extend and work on this. In fact, it is BSD. >> >> As I mentioned in my poorly worded and perhaps flippant response, we're already engaged in each of these areas, and forming a new working group is neither necessary nor would it actually help move the ball forward. The best things to do are to discuss issues on this mailing list, add issues to JIRA and lobby other developers to support those items, and if possible contribute complete solutions for things that we don't have on our deliverable list. >> >> Richard > > From richard.bair at oracle.com Thu Oct 18 10:35:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 10:35:29 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: Message-ID: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> From talking with the NB team, one feature they really need is to be able to embed Swing within JavaFX. Hopefully we can deliver on that for 8. On Oct 17, 2012, at 7:40 AM, Mark Claassen wrote: > I joined this list a few days ago because I wanted to start contributing > So far, I am not sure it is quite where I should be. I would like to > discuss more about the components (table, list boxes, ...). I am not > exactly sure where to do that. > > However, I will add here that I started (a very short-lived) thread on the > netbeans user list along these lines. Basically what I was saying was that > Netbeans is a wonderful UI built on Swing. Could this same project be done > in JavaFX? Maybe not yet, but could it be in the future? It seems like > the JavaFX team could get a lot of advice and requirements from the > netbeans team. > > http://forums.netbeans.org/topic51717.html > > Some of the main data structures, like the ObservableList, make me cringe. > I created a similar structure 10 years ago and have since learned the error > of my ways. Granted, the JavaFX team has a lot more resources and > experience than I did all those years ago, but from my point of view, there > are dangerous waters ahead. > > > On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair wrote: > >> We are already doing everything on your list (which was pretty void of >> specifics). Please list specific work projects, linked to specific JIRA >> issues, and vote for them and for goodness sake contribute! >> >> >> >> >> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: >> >>> So Oracle as an organization doesn't think JavaFX can be a player in the >>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the >> * >>> potential* to be better. But it's a long way behind and gotten off to a >>> rocky start; there's a hell of a lot of work to be done and the current >>> rate, strategy and direction are not going to be nearly enough. >>> >>> Oracle is a big corporation with many different divisions. The left arm >>> doesn't know what the right is doing. So let's put aside 'oracle' for a >>> moment. I want to know: what does the JavaFX team think? Do you want to >> go >>> up against HTML5 for the client space, or just settle for a spot on the >>> fringe? >>> >>> Below is what I propose. >>> >>> This proposal needs the full backing of the JavaFX team and management. >>> Specifically it needs: >>> >>> 1. Belief that JavaFX can and should be the *number one* client >>> development platform for enterprise. >>> 2. Recognition that the current strategy will not make that happen. >>> 3. Resources (aka people) allocated to the working group outlined >> below. >>> These people must have enough influence in the JFX platform to >> legitimately >>> be able to influence the direction as needed. >>> 4. Commitment to supporting this working group fully and implementing >>> the strategies and recommendations that come out of it as a high >> priority >>> 5. A sense of urgency, and a proactive pursuit of achieving these goals >>> with a well defined timeline (i.e. "resources will be allocated by >> November >>> 2012" not "we're working on it"). >>> >>> In my opinion, all of these must be met 100%. Otherwise there is no point >>> starting at all and better to let it go and leave the enterprise space to >>> other players like HTML5 as 'Oracle' is suggesting. This is your call. >>> >>> I believe JavaFX can be the best platform for client-side enterprise >>> application development, capitalising-on, and adding-to Java's dominance >> in >>> server side enterprise development. >>> >>> Do you? >>> >>> >>> *Proposal to form a working group for JavaFX in the enterprise* >>> >>> Mission: >>> >>> - to position JavaFX as *the* dominant client-side development platform >>> for enterprise/business applications >>> >>> >>> Members: >>> >>> - a combination of paid Oracle JavaFX team members, and community >>> participants. The Oracle members must have the ability to access senior >>> JavaFX management and technical decision makers, and as such influence >> the >>> road map and direction of the JavaFX platform. Community members will >> be >>> those with a background and experience in the enterprise space and who >> are >>> committed to making JavaFX the platform of choice in this space. >>> >>> >>> Responsibilities: >>> >>> - Continuously identify improvements to the JavaFX platform that are >>> needed to ensure adoption by enterprise; drive the inclusion of these >> into >>> the JavaFX platform. >>> >>> - Continuously identify and monitor trends and developments within the >>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >>> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's >>> long term viability for their needs. >>> >>> - Provide best practices, community/forum support, documentation, >>> examples, tool add-ons, frameworks and other aids for integrating >> JavaFX >>> into popular enterprise technology stacks >>> >>> - Provide advocacy, publicity and drive general engagement and outreach >>> programs for the adoption of JavaFX in the enterprise. >>> >>> >>> Objectives: >>> >>> Objectives will be determined by the working group once formed, however >>> initial objectives will likely include the following: >>> >>> - Review the current deployment/distribution options for JavaFX and >>> determine ways to improve this to make it competitive with other >> popular >>> enterprise client platforms (e.g. HTML+JavaScript) for primary >> enterprise >>> OS' and platforms >>> >>> - Identify the most popular enterprise build and development tools and >>> determine a strategy for making JavaFX integrate into these >>> >>> - Review popular trends and toolkits within competitive platforms and >>> define the ideal frameworks and add-on tools needed by an enterprise >> client >>> (e.g. form validation). Use this list of high-level requirements to >>> determine the low-level JavaFX enhancements needed (e.g. allow field >>> markers so that a 3rd party validation framework could leverage these). >>> >>> - Create a demonstration enterprise application (along the lines of >>> PetClinic) demonstrating best practice for integrating JavaFX in a >> full, >>> end-to-end JEE stack. >>> >>> >>> Longer term objectives may include: >>> >>> - Develop (or foster community development of) the high-level >> frameworks >>> that have been identified as necessary for JavaFX in the enterprise. >> These >>> will likely be developed as third-party modules external to the JavaFX >> core >>> framework (i.e. built on top of the features provided by the core >> JavaFX >>> team). >>> >>> - Provide integration with existing or new Rapid Application >> Development >>> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). >> From peter.pilgrim at gmail.com Thu Oct 18 10:37:49 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Thu, 18 Oct 2012 18:37:49 +0100 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: <5983853290558174241@unknownmsgid> <150ADA31-1C0C-431C-8B02-5786777E5DCF@bestsolution.at> Message-ID: fwd On 18 October 2012 15:21, Peter Pilgrim wrote: > On 17 October 2012 23:00, Tom Schindl wrote: >> The problem is that we only get a control which is able to render rich text but unfortunately no editor! To get an editor with features you see in todays IDEs is a very long way from what we get with jfx8. > > Tom > > I agree it is render mode. > > Maybe that is something that could be part of jfxtra project. > > The poor's editor component would be in my head a version of the > gang-of-four Flyweight Pattern. You need some sort of Cursor and > Document types. You need also some way of calculating Text Character > extents. Horrible and complicated I know and agree, but those HTML5 > and JavaScript people did something like this years ago with the > editor that was written inside a browser (Dion Almear and Ben > Galbreath the Ajaxian unrelated brothers with ``Bespin'') > > Well Jeremy Clarkson (BBC Top Gear fame, UK) might exclaim, "How hard > can it be?" (all you do keep a record or row and column of cursor). > Agree the devil is in the details. Fixed font versus proportional > font. > > On the hand, I cannot remember seeing such a component listed in the > roadmap at this year's JavaOne. > >> >> Tom >> >> Von meinem iPad gesendet >> >> Am 17.10.2012 um 18:01 schrieb Peter Pilgrim : >> >>> Richard Bair gave a presentation on rich text components vis-a-vis >>> TextPane and TextFlow at JavaOne >>> >>> Supporting styles, bidirectional flow, Arabic /Hebrew maybe Chinese?, >>> proper text wrapping and flowing around a defined area. >>> >>> So in affect we should be all able to write IDE in JavaFX >>> >>> If Kim is lurking about still on this list, he will definite >>> understand the verbosity of the old Swing style text document Apis , >>> I expect better with the new FX text Apis in Fx8 >>> >>> Sent from my iPhone 4S > ==////== > > > -- > Peter Pilgrim, -- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for financial services, London, UK JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim :: :: Skype Call peter_pilgrim :: :: http://java-champions.java.net/ :: From phidias51 at gmail.com Thu Oct 18 10:39:54 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 18 Oct 2012 10:39:54 -0700 Subject: Making JavaFX Development Faster Message-ID: One of the big timewasters when it comes to JavaFX projects taking your server-side POJOs, creating Observable versions of them, and creating forms, and controllers for them. If you've been doing JEE development in the past 5 years then you're probably already using Spring ROO, Grails, or some other RAD tooling that makes this type of work trivial in the web world. All of these artifacts are usually generated directly from the POJOs. So I'm curious if anyone knows of any tools that make that process easier and faster? Cheers, Mark From neugens.limasoftware at gmail.com Thu Oct 18 10:43:48 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 18 Oct 2012 19:43:48 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> Message-ID: Hi Richard, You should probably look at this old mail, since this may be what you need. http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000021.html We need to port this code to 2.2, I'll try to give it some love this week, it should give us also some good performances. Cheers, Mario 2012/10/18 Richard Bair : > From talking with the NB team, one feature they really need is to be able to embed Swing within JavaFX. Hopefully we can deliver on that for 8. > > On Oct 17, 2012, at 7:40 AM, Mark Claassen wrote: > >> I joined this list a few days ago because I wanted to start contributing >> So far, I am not sure it is quite where I should be. I would like to >> discuss more about the components (table, list boxes, ...). I am not >> exactly sure where to do that. >> >> However, I will add here that I started (a very short-lived) thread on the >> netbeans user list along these lines. Basically what I was saying was that >> Netbeans is a wonderful UI built on Swing. Could this same project be done >> in JavaFX? Maybe not yet, but could it be in the future? It seems like >> the JavaFX team could get a lot of advice and requirements from the >> netbeans team. >> >> http://forums.netbeans.org/topic51717.html >> >> Some of the main data structures, like the ObservableList, make me cringe. >> I created a similar structure 10 years ago and have since learned the error >> of my ways. Granted, the JavaFX team has a lot more resources and >> experience than I did all those years ago, but from my point of view, there >> are dangerous waters ahead. >> >> >> On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair wrote: >> >>> We are already doing everything on your list (which was pretty void of >>> specifics). Please list specific work projects, linked to specific JIRA >>> issues, and vote for them and for goodness sake contribute! >>> >>> >>> >>> >>> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: >>> >>>> So Oracle as an organization doesn't think JavaFX can be a player in the >>>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the >>> * >>>> potential* to be better. But it's a long way behind and gotten off to a >>>> rocky start; there's a hell of a lot of work to be done and the current >>>> rate, strategy and direction are not going to be nearly enough. >>>> >>>> Oracle is a big corporation with many different divisions. The left arm >>>> doesn't know what the right is doing. So let's put aside 'oracle' for a >>>> moment. I want to know: what does the JavaFX team think? Do you want to >>> go >>>> up against HTML5 for the client space, or just settle for a spot on the >>>> fringe? >>>> >>>> Below is what I propose. >>>> >>>> This proposal needs the full backing of the JavaFX team and management. >>>> Specifically it needs: >>>> >>>> 1. Belief that JavaFX can and should be the *number one* client >>>> development platform for enterprise. >>>> 2. Recognition that the current strategy will not make that happen. >>>> 3. Resources (aka people) allocated to the working group outlined >>> below. >>>> These people must have enough influence in the JFX platform to >>> legitimately >>>> be able to influence the direction as needed. >>>> 4. Commitment to supporting this working group fully and implementing >>>> the strategies and recommendations that come out of it as a high >>> priority >>>> 5. A sense of urgency, and a proactive pursuit of achieving these goals >>>> with a well defined timeline (i.e. "resources will be allocated by >>> November >>>> 2012" not "we're working on it"). >>>> >>>> In my opinion, all of these must be met 100%. Otherwise there is no point >>>> starting at all and better to let it go and leave the enterprise space to >>>> other players like HTML5 as 'Oracle' is suggesting. This is your call. >>>> >>>> I believe JavaFX can be the best platform for client-side enterprise >>>> application development, capitalising-on, and adding-to Java's dominance >>> in >>>> server side enterprise development. >>>> >>>> Do you? >>>> >>>> >>>> *Proposal to form a working group for JavaFX in the enterprise* >>>> >>>> Mission: >>>> >>>> - to position JavaFX as *the* dominant client-side development platform >>>> for enterprise/business applications >>>> >>>> >>>> Members: >>>> >>>> - a combination of paid Oracle JavaFX team members, and community >>>> participants. The Oracle members must have the ability to access senior >>>> JavaFX management and technical decision makers, and as such influence >>> the >>>> road map and direction of the JavaFX platform. Community members will >>> be >>>> those with a background and experience in the enterprise space and who >>> are >>>> committed to making JavaFX the platform of choice in this space. >>>> >>>> >>>> Responsibilities: >>>> >>>> - Continuously identify improvements to the JavaFX platform that are >>>> needed to ensure adoption by enterprise; drive the inclusion of these >>> into >>>> the JavaFX platform. >>>> >>>> - Continuously identify and monitor trends and developments within the >>>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >>>> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's >>>> long term viability for their needs. >>>> >>>> - Provide best practices, community/forum support, documentation, >>>> examples, tool add-ons, frameworks and other aids for integrating >>> JavaFX >>>> into popular enterprise technology stacks >>>> >>>> - Provide advocacy, publicity and drive general engagement and outreach >>>> programs for the adoption of JavaFX in the enterprise. >>>> >>>> >>>> Objectives: >>>> >>>> Objectives will be determined by the working group once formed, however >>>> initial objectives will likely include the following: >>>> >>>> - Review the current deployment/distribution options for JavaFX and >>>> determine ways to improve this to make it competitive with other >>> popular >>>> enterprise client platforms (e.g. HTML+JavaScript) for primary >>> enterprise >>>> OS' and platforms >>>> >>>> - Identify the most popular enterprise build and development tools and >>>> determine a strategy for making JavaFX integrate into these >>>> >>>> - Review popular trends and toolkits within competitive platforms and >>>> define the ideal frameworks and add-on tools needed by an enterprise >>> client >>>> (e.g. form validation). Use this list of high-level requirements to >>>> determine the low-level JavaFX enhancements needed (e.g. allow field >>>> markers so that a 3rd party validation framework could leverage these). >>>> >>>> - Create a demonstration enterprise application (along the lines of >>>> PetClinic) demonstrating best practice for integrating JavaFX in a >>> full, >>>> end-to-end JEE stack. >>>> >>>> >>>> Longer term objectives may include: >>>> >>>> - Develop (or foster community development of) the high-level >>> frameworks >>>> that have been identified as necessary for JavaFX in the enterprise. >>> These >>>> will likely be developed as third-party modules external to the JavaFX >>> core >>>> framework (i.e. built on top of the features provided by the core >>> JavaFX >>>> team). >>>> >>>> - Provide integration with existing or new Rapid Application >>> Development >>>> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). >>> > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From tom.schindl at bestsolution.at Thu Oct 18 10:47:16 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 18 Oct 2012 19:47:16 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: <5983853290558174241@unknownmsgid> <150ADA31-1C0C-431C-8B02-5786777E5DCF@bestsolution.at> Message-ID: <508040A4.50707@bestsolution.at> Am 18.10.12 19:37, schrieb Peter Pilgrim: > fwd > > On 18 October 2012 15:21, Peter Pilgrim wrote: >> On 17 October 2012 23:00, Tom Schindl wrote: >>> The problem is that we only get a control which is able to render rich text but unfortunately no editor! To get an editor with features you see in todays IDEs is a very long way from what we get with jfx8. >> >> Tom >> >> I agree it is render mode. >> >> Maybe that is something that could be part of jfxtra project. >> Sure. >> The poor's editor component would be in my head a version of the >> gang-of-four Flyweight Pattern. You need some sort of Cursor and >> Document types. You need also some way of calculating Text Character >> extents. Horrible and complicated I know and agree, but those HTML5 >> and JavaScript people did something like this years ago with the >> editor that was written inside a browser (Dion Almear and Ben >> Galbreath the Ajaxian unrelated brothers with ``Bespin'') Well the last information I have from Felipe on this is that he already has all the picking, ... stuff implemented but I need to play with it. The JavaScript guys you mention is exactly what I'm doing. I simply use an embedded webview to provide me a structured editor. Did you look at my blog to see it in action? I'm going to look into the rich text control after EclipseCon Europe and I'll try to get in touch with Felipe - maybe with a bit we could get something going. I only know the stuff we have at Eclipse and all the parsing infrastructure e.g. to split of source code into segments does not depend at all on SWT so we can reuse it without problems! Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From roman at kennke.org Thu Oct 18 10:49:12 2012 From: roman at kennke.org (Roman Kennke) Date: Thu, 18 Oct 2012 19:49:12 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> Message-ID: <1350582552.2097.115.camel@mercury> > From talking with the NB team, one feature they really need is to be > able to embed Swing within JavaFX. Hopefully we can deliver on that > for 8. Interesting! We (Mario and I) found the same thing when we tried out JavaFX in a corporate/banking environment last year. There are just so many custom components that in some cases took years to build, which are not going to easily be replaced by JavaFX counterparts (although they would probably take much less time to do in JavaFX). That is why we started our SwingView back then. Unfortunately, we did not follow up with it though, due to a lack of support from JavaFX (API-wise). Now, with the new image/pixel APIs, would be a good time to revisit this effort. Unless you already have something in the pipe for that, that is. On the other hand, if you have not already started on this, we might be more than willing to work on it and contribute it to JavaFX mainline. (Some somewhat old info on our SwingView is here: http://thingsfx.com/) Cheers, Roman From richard.bair at oracle.com Thu Oct 18 10:54:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 10:54:31 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> Message-ID: <4A67C2BA-6B04-4DB3-A6A4-3166DAA47B52@oracle.com> The AWT / Glass guys actually have a prototype of all of SwingSet running in JavaFX. I think most of the technical hurdles have been resolved (? Artem would know better), but it is just a matter of resourcing (there were some changes in AWT to get the best performance / integration). Richard On Oct 18, 2012, at 10:43 AM, Mario Torre wrote: > Hi Richard, > > You should probably look at this old mail, since this may be what you need. > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000021.html > > We need to port this code to 2.2, I'll try to give it some love this > week, it should give us also some good performances. > > Cheers, > Mario > > 2012/10/18 Richard Bair : >> From talking with the NB team, one feature they really need is to be able to embed Swing within JavaFX. Hopefully we can deliver on that for 8. >> >> On Oct 17, 2012, at 7:40 AM, Mark Claassen wrote: >> >>> I joined this list a few days ago because I wanted to start contributing >>> So far, I am not sure it is quite where I should be. I would like to >>> discuss more about the components (table, list boxes, ...). I am not >>> exactly sure where to do that. >>> >>> However, I will add here that I started (a very short-lived) thread on the >>> netbeans user list along these lines. Basically what I was saying was that >>> Netbeans is a wonderful UI built on Swing. Could this same project be done >>> in JavaFX? Maybe not yet, but could it be in the future? It seems like >>> the JavaFX team could get a lot of advice and requirements from the >>> netbeans team. >>> >>> http://forums.netbeans.org/topic51717.html >>> >>> Some of the main data structures, like the ObservableList, make me cringe. >>> I created a similar structure 10 years ago and have since learned the error >>> of my ways. Granted, the JavaFX team has a lot more resources and >>> experience than I did all those years ago, but from my point of view, there >>> are dangerous waters ahead. >>> >>> >>> On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair wrote: >>> >>>> We are already doing everything on your list (which was pretty void of >>>> specifics). Please list specific work projects, linked to specific JIRA >>>> issues, and vote for them and for goodness sake contribute! >>>> >>>> >>>> >>>> >>>> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: >>>> >>>>> So Oracle as an organization doesn't think JavaFX can be a player in the >>>>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the >>>> * >>>>> potential* to be better. But it's a long way behind and gotten off to a >>>>> rocky start; there's a hell of a lot of work to be done and the current >>>>> rate, strategy and direction are not going to be nearly enough. >>>>> >>>>> Oracle is a big corporation with many different divisions. The left arm >>>>> doesn't know what the right is doing. So let's put aside 'oracle' for a >>>>> moment. I want to know: what does the JavaFX team think? Do you want to >>>> go >>>>> up against HTML5 for the client space, or just settle for a spot on the >>>>> fringe? >>>>> >>>>> Below is what I propose. >>>>> >>>>> This proposal needs the full backing of the JavaFX team and management. >>>>> Specifically it needs: >>>>> >>>>> 1. Belief that JavaFX can and should be the *number one* client >>>>> development platform for enterprise. >>>>> 2. Recognition that the current strategy will not make that happen. >>>>> 3. Resources (aka people) allocated to the working group outlined >>>> below. >>>>> These people must have enough influence in the JFX platform to >>>> legitimately >>>>> be able to influence the direction as needed. >>>>> 4. Commitment to supporting this working group fully and implementing >>>>> the strategies and recommendations that come out of it as a high >>>> priority >>>>> 5. A sense of urgency, and a proactive pursuit of achieving these goals >>>>> with a well defined timeline (i.e. "resources will be allocated by >>>> November >>>>> 2012" not "we're working on it"). >>>>> >>>>> In my opinion, all of these must be met 100%. Otherwise there is no point >>>>> starting at all and better to let it go and leave the enterprise space to >>>>> other players like HTML5 as 'Oracle' is suggesting. This is your call. >>>>> >>>>> I believe JavaFX can be the best platform for client-side enterprise >>>>> application development, capitalising-on, and adding-to Java's dominance >>>> in >>>>> server side enterprise development. >>>>> >>>>> Do you? >>>>> >>>>> >>>>> *Proposal to form a working group for JavaFX in the enterprise* >>>>> >>>>> Mission: >>>>> >>>>> - to position JavaFX as *the* dominant client-side development platform >>>>> for enterprise/business applications >>>>> >>>>> >>>>> Members: >>>>> >>>>> - a combination of paid Oracle JavaFX team members, and community >>>>> participants. The Oracle members must have the ability to access senior >>>>> JavaFX management and technical decision makers, and as such influence >>>> the >>>>> road map and direction of the JavaFX platform. Community members will >>>> be >>>>> those with a background and experience in the enterprise space and who >>>> are >>>>> committed to making JavaFX the platform of choice in this space. >>>>> >>>>> >>>>> Responsibilities: >>>>> >>>>> - Continuously identify improvements to the JavaFX platform that are >>>>> needed to ensure adoption by enterprise; drive the inclusion of these >>>> into >>>>> the JavaFX platform. >>>>> >>>>> - Continuously identify and monitor trends and developments within the >>>>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >>>>> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's >>>>> long term viability for their needs. >>>>> >>>>> - Provide best practices, community/forum support, documentation, >>>>> examples, tool add-ons, frameworks and other aids for integrating >>>> JavaFX >>>>> into popular enterprise technology stacks >>>>> >>>>> - Provide advocacy, publicity and drive general engagement and outreach >>>>> programs for the adoption of JavaFX in the enterprise. >>>>> >>>>> >>>>> Objectives: >>>>> >>>>> Objectives will be determined by the working group once formed, however >>>>> initial objectives will likely include the following: >>>>> >>>>> - Review the current deployment/distribution options for JavaFX and >>>>> determine ways to improve this to make it competitive with other >>>> popular >>>>> enterprise client platforms (e.g. HTML+JavaScript) for primary >>>> enterprise >>>>> OS' and platforms >>>>> >>>>> - Identify the most popular enterprise build and development tools and >>>>> determine a strategy for making JavaFX integrate into these >>>>> >>>>> - Review popular trends and toolkits within competitive platforms and >>>>> define the ideal frameworks and add-on tools needed by an enterprise >>>> client >>>>> (e.g. form validation). Use this list of high-level requirements to >>>>> determine the low-level JavaFX enhancements needed (e.g. allow field >>>>> markers so that a 3rd party validation framework could leverage these). >>>>> >>>>> - Create a demonstration enterprise application (along the lines of >>>>> PetClinic) demonstrating best practice for integrating JavaFX in a >>>> full, >>>>> end-to-end JEE stack. >>>>> >>>>> >>>>> Longer term objectives may include: >>>>> >>>>> - Develop (or foster community development of) the high-level >>>> frameworks >>>>> that have been identified as necessary for JavaFX in the enterprise. >>>> These >>>>> will likely be developed as third-party modules external to the JavaFX >>>> core >>>>> framework (i.e. built on top of the features provided by the core >>>> JavaFX >>>>> team). >>>>> >>>>> - Provide integration with existing or new Rapid Application >>>> Development >>>>> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). >>>> >> > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From richard.bair at oracle.com Thu Oct 18 11:00:53 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 11:00:53 -0700 Subject: Swing in FX In-Reply-To: <1350582552.2097.115.camel@mercury> References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <1350582552.2097.115.camel@mercury> Message-ID: Ya, the stuff you guys did was awesome and got the ball rolling. Without that we'd have had a much harder time getting something production worthy put together! I will check with the team and see what the likelihood is that they can deliver their solution, and also where it would go. Right now my main focus is on getting everything open sourced as quickly as possible, and rewriting the build system to something simple and sensible for the modules that we really have (whereas now we have many micro-modules). My main focus for the next month or so is to fulfill the promise we made way back last year that we'd open source JavaFX and run like a real open source project. On Oct 18, 2012, at 10:49 AM, Roman Kennke wrote: >> From talking with the NB team, one feature they really need is to be >> able to embed Swing within JavaFX. Hopefully we can deliver on that >> for 8. > > Interesting! We (Mario and I) found the same thing when we tried out > JavaFX in a corporate/banking environment last year. There are just so > many custom components that in some cases took years to build, which are > not going to easily be replaced by JavaFX counterparts (although they > would probably take much less time to do in JavaFX). That is why we > started our SwingView back then. Unfortunately, we did not follow up > with it though, due to a lack of support from JavaFX (API-wise). Now, > with the new image/pixel APIs, would be a good time to revisit this > effort. Unless you already have something in the pipe for that, that is. > On the other hand, if you have not already started on this, we might be > more than willing to work on it and contribute it to JavaFX mainline. > > (Some somewhat old info on our SwingView is here: http://thingsfx.com/) > > Cheers, > Roman > From phidias51 at gmail.com Thu Oct 18 11:06:21 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 18 Oct 2012 11:06:21 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <4A67C2BA-6B04-4DB3-A6A4-3166DAA47B52@oracle.com> References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <4A67C2BA-6B04-4DB3-A6A4-3166DAA47B52@oracle.com> Message-ID: Richard, This is pretty critical in order to get Swing applications ported over to JavaFX. There are a lot of libraries out there that probably will never be ported to JavaFX, and for which there are no JavaFX equivalents. This kind of embedding makes is possible for people to at least entertain the idea of transitioning to JavaFX. Is there a JIRA issue for this? Cheers, Mark On Thu, Oct 18, 2012 at 10:54 AM, Richard Bair wrote: > The AWT / Glass guys actually have a prototype of all of SwingSet running > in JavaFX. I think most of the technical hurdles have been resolved (? > Artem would know better), but it is just a matter of resourcing (there were > some changes in AWT to get the best performance / integration). > > Richard > > On Oct 18, 2012, at 10:43 AM, Mario Torre wrote: > > > Hi Richard, > > > > You should probably look at this old mail, since this may be what you > need. > > > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000021.html > > > > We need to port this code to 2.2, I'll try to give it some love this > > week, it should give us also some good performances. > > > > Cheers, > > Mario > > > > 2012/10/18 Richard Bair : > >> From talking with the NB team, one feature they really need is to be > able to embed Swing within JavaFX. Hopefully we can deliver on that for 8. > >> > >> On Oct 17, 2012, at 7:40 AM, Mark Claassen wrote: > >> > >>> I joined this list a few days ago because I wanted to start > contributing > >>> So far, I am not sure it is quite where I should be. I would like to > >>> discuss more about the components (table, list boxes, ...). I am not > >>> exactly sure where to do that. > >>> > >>> However, I will add here that I started (a very short-lived) thread on > the > >>> netbeans user list along these lines. Basically what I was saying was > that > >>> Netbeans is a wonderful UI built on Swing. Could this same project be > done > >>> in JavaFX? Maybe not yet, but could it be in the future? It seems > like > >>> the JavaFX team could get a lot of advice and requirements from the > >>> netbeans team. > >>> > >>> http://forums.netbeans.org/topic51717.html > >>> > >>> Some of the main data structures, like the ObservableList, make me > cringe. > >>> I created a similar structure 10 years ago and have since learned the > error > >>> of my ways. Granted, the JavaFX team has a lot more resources and > >>> experience than I did all those years ago, but from my point of view, > there > >>> are dangerous waters ahead. > >>> > >>> > >>> On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair < > richard.bair at oracle.com>wrote: > >>> > >>>> We are already doing everything on your list (which was pretty void of > >>>> specifics). Please list specific work projects, linked to specific > JIRA > >>>> issues, and vote for them and for goodness sake contribute! > >>>> > >>>> > >>>> > >>>> > >>>> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski > wrote: > >>>> > >>>>> So Oracle as an organization doesn't think JavaFX can be a player in > the > >>>>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has > the > >>>> * > >>>>> potential* to be better. But it's a long way behind and gotten off > to a > >>>>> rocky start; there's a hell of a lot of work to be done and the > current > >>>>> rate, strategy and direction are not going to be nearly enough. > >>>>> > >>>>> Oracle is a big corporation with many different divisions. The left > arm > >>>>> doesn't know what the right is doing. So let's put aside 'oracle' > for a > >>>>> moment. I want to know: what does the JavaFX team think? Do you want > to > >>>> go > >>>>> up against HTML5 for the client space, or just settle for a spot on > the > >>>>> fringe? > >>>>> > >>>>> Below is what I propose. > >>>>> > >>>>> This proposal needs the full backing of the JavaFX team and > management. > >>>>> Specifically it needs: > >>>>> > >>>>> 1. Belief that JavaFX can and should be the *number one* client > >>>>> development platform for enterprise. > >>>>> 2. Recognition that the current strategy will not make that happen. > >>>>> 3. Resources (aka people) allocated to the working group outlined > >>>> below. > >>>>> These people must have enough influence in the JFX platform to > >>>> legitimately > >>>>> be able to influence the direction as needed. > >>>>> 4. Commitment to supporting this working group fully and implementing > >>>>> the strategies and recommendations that come out of it as a high > >>>> priority > >>>>> 5. A sense of urgency, and a proactive pursuit of achieving these > goals > >>>>> with a well defined timeline (i.e. "resources will be allocated by > >>>> November > >>>>> 2012" not "we're working on it"). > >>>>> > >>>>> In my opinion, all of these must be met 100%. Otherwise there is no > point > >>>>> starting at all and better to let it go and leave the enterprise > space to > >>>>> other players like HTML5 as 'Oracle' is suggesting. This is your > call. > >>>>> > >>>>> I believe JavaFX can be the best platform for client-side enterprise > >>>>> application development, capitalising-on, and adding-to Java's > dominance > >>>> in > >>>>> server side enterprise development. > >>>>> > >>>>> Do you? > >>>>> > >>>>> > >>>>> *Proposal to form a working group for JavaFX in the enterprise* > >>>>> > >>>>> Mission: > >>>>> > >>>>> - to position JavaFX as *the* dominant client-side development > platform > >>>>> for enterprise/business applications > >>>>> > >>>>> > >>>>> Members: > >>>>> > >>>>> - a combination of paid Oracle JavaFX team members, and community > >>>>> participants. The Oracle members must have the ability to access > senior > >>>>> JavaFX management and technical decision makers, and as such > influence > >>>> the > >>>>> road map and direction of the JavaFX platform. Community members will > >>>> be > >>>>> those with a background and experience in the enterprise space and > who > >>>> are > >>>>> committed to making JavaFX the platform of choice in this space. > >>>>> > >>>>> > >>>>> Responsibilities: > >>>>> > >>>>> - Continuously identify improvements to the JavaFX platform that are > >>>>> needed to ensure adoption by enterprise; drive the inclusion of these > >>>> into > >>>>> the JavaFX platform. > >>>>> > >>>>> - Continuously identify and monitor trends and developments within > the > >>>>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and > >>>>> ensure the JavaFX roadmap provides confidence to enterprise of > JavaFX's > >>>>> long term viability for their needs. > >>>>> > >>>>> - Provide best practices, community/forum support, documentation, > >>>>> examples, tool add-ons, frameworks and other aids for integrating > >>>> JavaFX > >>>>> into popular enterprise technology stacks > >>>>> > >>>>> - Provide advocacy, publicity and drive general engagement and > outreach > >>>>> programs for the adoption of JavaFX in the enterprise. > >>>>> > >>>>> > >>>>> Objectives: > >>>>> > >>>>> Objectives will be determined by the working group once formed, > however > >>>>> initial objectives will likely include the following: > >>>>> > >>>>> - Review the current deployment/distribution options for JavaFX and > >>>>> determine ways to improve this to make it competitive with other > >>>> popular > >>>>> enterprise client platforms (e.g. HTML+JavaScript) for primary > >>>> enterprise > >>>>> OS' and platforms > >>>>> > >>>>> - Identify the most popular enterprise build and development tools > and > >>>>> determine a strategy for making JavaFX integrate into these > >>>>> > >>>>> - Review popular trends and toolkits within competitive platforms and > >>>>> define the ideal frameworks and add-on tools needed by an enterprise > >>>> client > >>>>> (e.g. form validation). Use this list of high-level requirements to > >>>>> determine the low-level JavaFX enhancements needed (e.g. allow field > >>>>> markers so that a 3rd party validation framework could leverage > these). > >>>>> > >>>>> - Create a demonstration enterprise application (along the lines of > >>>>> PetClinic) demonstrating best practice for integrating JavaFX in a > >>>> full, > >>>>> end-to-end JEE stack. > >>>>> > >>>>> > >>>>> Longer term objectives may include: > >>>>> > >>>>> - Develop (or foster community development of) the high-level > >>>> frameworks > >>>>> that have been identified as necessary for JavaFX in the enterprise. > >>>> These > >>>>> will likely be developed as third-party modules external to the > JavaFX > >>>> core > >>>>> framework (i.e. built on top of the features provided by the core > >>>> JavaFX > >>>>> team). > >>>>> > >>>>> - Provide integration with existing or new Rapid Application > >>>> Development > >>>>> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). > >>>> > >> > > > > > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > IcedRobot: www.icedrobot.org > > Proud GNU Classpath developer: http://www.classpath.org/ > > Read About us at: http://planet.classpath.org > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > From neugens.limasoftware at gmail.com Thu Oct 18 11:06:44 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 18 Oct 2012 20:06:44 +0200 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: <4A67C2BA-6B04-4DB3-A6A4-3166DAA47B52@oracle.com> References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <4A67C2BA-6B04-4DB3-A6A4-3166DAA47B52@oracle.com> Message-ID: Ah, like this, you mean? ;) http://rkennke.wordpress.com/2011/11/16/swing-in-javafx-demo/ Cheers, Mario 2012/10/18 Richard Bair : > The AWT / Glass guys actually have a prototype of all of SwingSet running in JavaFX. I think most of the technical hurdles have been resolved (? Artem would know better), but it is just a matter of resourcing (there were some changes in AWT to get the best performance / integration). > > Richard > > On Oct 18, 2012, at 10:43 AM, Mario Torre wrote: > >> Hi Richard, >> >> You should probably look at this old mail, since this may be what you need. >> >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000021.html >> >> We need to port this code to 2.2, I'll try to give it some love this >> week, it should give us also some good performances. >> >> Cheers, >> Mario >> >> 2012/10/18 Richard Bair : >>> From talking with the NB team, one feature they really need is to be able to embed Swing within JavaFX. Hopefully we can deliver on that for 8. >>> >>> On Oct 17, 2012, at 7:40 AM, Mark Claassen wrote: >>> >>>> I joined this list a few days ago because I wanted to start contributing >>>> So far, I am not sure it is quite where I should be. I would like to >>>> discuss more about the components (table, list boxes, ...). I am not >>>> exactly sure where to do that. >>>> >>>> However, I will add here that I started (a very short-lived) thread on the >>>> netbeans user list along these lines. Basically what I was saying was that >>>> Netbeans is a wonderful UI built on Swing. Could this same project be done >>>> in JavaFX? Maybe not yet, but could it be in the future? It seems like >>>> the JavaFX team could get a lot of advice and requirements from the >>>> netbeans team. >>>> >>>> http://forums.netbeans.org/topic51717.html >>>> >>>> Some of the main data structures, like the ObservableList, make me cringe. >>>> I created a similar structure 10 years ago and have since learned the error >>>> of my ways. Granted, the JavaFX team has a lot more resources and >>>> experience than I did all those years ago, but from my point of view, there >>>> are dangerous waters ahead. >>>> >>>> >>>> On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair wrote: >>>> >>>>> We are already doing everything on your list (which was pretty void of >>>>> specifics). Please list specific work projects, linked to specific JIRA >>>>> issues, and vote for them and for goodness sake contribute! >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski wrote: >>>>> >>>>>> So Oracle as an organization doesn't think JavaFX can be a player in the >>>>>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has the >>>>> * >>>>>> potential* to be better. But it's a long way behind and gotten off to a >>>>>> rocky start; there's a hell of a lot of work to be done and the current >>>>>> rate, strategy and direction are not going to be nearly enough. >>>>>> >>>>>> Oracle is a big corporation with many different divisions. The left arm >>>>>> doesn't know what the right is doing. So let's put aside 'oracle' for a >>>>>> moment. I want to know: what does the JavaFX team think? Do you want to >>>>> go >>>>>> up against HTML5 for the client space, or just settle for a spot on the >>>>>> fringe? >>>>>> >>>>>> Below is what I propose. >>>>>> >>>>>> This proposal needs the full backing of the JavaFX team and management. >>>>>> Specifically it needs: >>>>>> >>>>>> 1. Belief that JavaFX can and should be the *number one* client >>>>>> development platform for enterprise. >>>>>> 2. Recognition that the current strategy will not make that happen. >>>>>> 3. Resources (aka people) allocated to the working group outlined >>>>> below. >>>>>> These people must have enough influence in the JFX platform to >>>>> legitimately >>>>>> be able to influence the direction as needed. >>>>>> 4. Commitment to supporting this working group fully and implementing >>>>>> the strategies and recommendations that come out of it as a high >>>>> priority >>>>>> 5. A sense of urgency, and a proactive pursuit of achieving these goals >>>>>> with a well defined timeline (i.e. "resources will be allocated by >>>>> November >>>>>> 2012" not "we're working on it"). >>>>>> >>>>>> In my opinion, all of these must be met 100%. Otherwise there is no point >>>>>> starting at all and better to let it go and leave the enterprise space to >>>>>> other players like HTML5 as 'Oracle' is suggesting. This is your call. >>>>>> >>>>>> I believe JavaFX can be the best platform for client-side enterprise >>>>>> application development, capitalising-on, and adding-to Java's dominance >>>>> in >>>>>> server side enterprise development. >>>>>> >>>>>> Do you? >>>>>> >>>>>> >>>>>> *Proposal to form a working group for JavaFX in the enterprise* >>>>>> >>>>>> Mission: >>>>>> >>>>>> - to position JavaFX as *the* dominant client-side development platform >>>>>> for enterprise/business applications >>>>>> >>>>>> >>>>>> Members: >>>>>> >>>>>> - a combination of paid Oracle JavaFX team members, and community >>>>>> participants. The Oracle members must have the ability to access senior >>>>>> JavaFX management and technical decision makers, and as such influence >>>>> the >>>>>> road map and direction of the JavaFX platform. Community members will >>>>> be >>>>>> those with a background and experience in the enterprise space and who >>>>> are >>>>>> committed to making JavaFX the platform of choice in this space. >>>>>> >>>>>> >>>>>> Responsibilities: >>>>>> >>>>>> - Continuously identify improvements to the JavaFX platform that are >>>>>> needed to ensure adoption by enterprise; drive the inclusion of these >>>>> into >>>>>> the JavaFX platform. >>>>>> >>>>>> - Continuously identify and monitor trends and developments within the >>>>>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >>>>>> ensure the JavaFX roadmap provides confidence to enterprise of JavaFX's >>>>>> long term viability for their needs. >>>>>> >>>>>> - Provide best practices, community/forum support, documentation, >>>>>> examples, tool add-ons, frameworks and other aids for integrating >>>>> JavaFX >>>>>> into popular enterprise technology stacks >>>>>> >>>>>> - Provide advocacy, publicity and drive general engagement and outreach >>>>>> programs for the adoption of JavaFX in the enterprise. >>>>>> >>>>>> >>>>>> Objectives: >>>>>> >>>>>> Objectives will be determined by the working group once formed, however >>>>>> initial objectives will likely include the following: >>>>>> >>>>>> - Review the current deployment/distribution options for JavaFX and >>>>>> determine ways to improve this to make it competitive with other >>>>> popular >>>>>> enterprise client platforms (e.g. HTML+JavaScript) for primary >>>>> enterprise >>>>>> OS' and platforms >>>>>> >>>>>> - Identify the most popular enterprise build and development tools and >>>>>> determine a strategy for making JavaFX integrate into these >>>>>> >>>>>> - Review popular trends and toolkits within competitive platforms and >>>>>> define the ideal frameworks and add-on tools needed by an enterprise >>>>> client >>>>>> (e.g. form validation). Use this list of high-level requirements to >>>>>> determine the low-level JavaFX enhancements needed (e.g. allow field >>>>>> markers so that a 3rd party validation framework could leverage these). >>>>>> >>>>>> - Create a demonstration enterprise application (along the lines of >>>>>> PetClinic) demonstrating best practice for integrating JavaFX in a >>>>> full, >>>>>> end-to-end JEE stack. >>>>>> >>>>>> >>>>>> Longer term objectives may include: >>>>>> >>>>>> - Develop (or foster community development of) the high-level >>>>> frameworks >>>>>> that have been identified as necessary for JavaFX in the enterprise. >>>>> These >>>>>> will likely be developed as third-party modules external to the JavaFX >>>>> core >>>>>> framework (i.e. built on top of the features provided by the core >>>>> JavaFX >>>>>> team). >>>>>> >>>>>> - Provide integration with existing or new Rapid Application >>>>> Development >>>>>> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). >>>>> >>> >> >> >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> IcedRobot: www.icedrobot.org >> Proud GNU Classpath developer: http://www.classpath.org/ >> Read About us at: http://planet.classpath.org >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From java.whoover at gmail.com Thu Oct 18 11:09:27 2012 From: java.whoover at gmail.com (Will Hoover) Date: Thu, 18 Oct 2012 14:09:27 -0400 Subject: Making JavaFX Development Faster In-Reply-To: References: Message-ID: <508045d8.e9b6ec0a.4c98.01bb@mx.google.com> As mentioned in an earlier thread of yours, you can save a lot of time creating Observable versions of your POJOs by using http://wp.me/p2rLDc-1c It will auto-generate all of your POJO Observable properties for you as you bind them (provided you don't need any fancy expressions ;) -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Thursday, October 18, 2012 1:40 PM To: openjfx-dev at openjdk.java.net Subject: Making JavaFX Development Faster One of the big timewasters when it comes to JavaFX projects taking your server-side POJOs, creating Observable versions of them, and creating forms, and controllers for them. If you've been doing JEE development in the past 5 years then you're probably already using Spring ROO, Grails, or some other RAD tooling that makes this type of work trivial in the web world. All of these artifacts are usually generated directly from the POJOs. So I'm curious if anyone knows of any tools that make that process easier and faster? Cheers, Mark From lehmann at media-interactive.de Thu Oct 18 11:09:15 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 18 Oct 2012 20:09:15 +0200 Subject: Making JavaFX Development Faster In-Reply-To: References: Message-ID: <508045CB.2040207@media-interactive.de> Mark, the latest links collection on the FX Experience blog includes this: > DooApp have announced an updated release of their FXForm2 project > (which can automatically generate forms from Java beans). http://blog.dooapp.com/fxml-fxform2-developing-forms-has-never-been Sounds like part of what you asked about (creating forms). I did not look into it though. About auto-generating observable versions of server-side pojos: I am sure this could be done with a code generator. However, I am not sure this is the best approach. I don't want to come up with a new name for my domain bean, and copy data back and forth just so that I can use it with controls requiring observable values. Recently I needed to display a few pojos in a TableView. Getting the data in was not difficult with the help of a PropertyValueFactory, as described in the TableView JavaDoc. But what if the pojo properties change? That's the hard part because TableView won't pick up the changes, not even after a repaint. Obviously the reflected value is cached. I had to jump through quite some hoops to provide TableView with observable property wrappers for pojo properties in a somewhat generic way. If there only was a method to force an update of a row or cell... Rgds Werner On 18.10.2012 19:39, Mark Fortner wrote: > One of the big timewasters when it comes to JavaFX projects taking > your server-side POJOs, creating Observable versions of them, and > creating forms, and controllers for them. If you've been doing JEE > development in the past 5 years then you're probably already using > Spring ROO, Grails, or some other RAD tooling that makes this type of > work trivial in the web world. All of these artifacts are usually > generated directly from the POJOs. > > So I'm curious if anyone knows of any tools that make that process > easier and faster? > > > Cheers, > > Mark From neugens.limasoftware at gmail.com Thu Oct 18 11:17:54 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 18 Oct 2012 20:17:54 +0200 Subject: Swing in FX In-Reply-To: References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <1350582552.2097.115.camel@mercury> Message-ID: 2012/10/18 Richard Bair : > Ya, the stuff you guys did was awesome and got the ball rolling. Without that we'd have had a much harder time getting something production worthy put together! I will check with the team and see what the likelihood is that they can deliver their solution, and also where it would go. Right now my main focus is on getting everything open sourced as quickly as possible, and rewriting the build system to something simple and sensible for the modules that we really have (whereas now we have many micro-modules). My main focus for the next month or so is to fulfill the promise we made way back last year that we'd open source JavaFX and run like a real open source project. Btw, speaking about the build system, since once open sourced we will need to package this thing for Linux distribution, it may make sense to discuss this in the open (I know, I know, I'm being pedantic here, sorry!). This could help also in releasing everything quicker. What do you think? Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From richard.bair at oracle.com Thu Oct 18 11:20:08 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 11:20:08 -0700 Subject: JavaFX for the Enterprise - Working Group In-Reply-To: References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <4A67C2BA-6B04-4DB3-A6A4-3166DAA47B52@oracle.com> Message-ID: http://javafx-jira.kenai.com/browse/RT-12100 It even references Mario & Roman's work ;-) On Oct 18, 2012, at 11:06 AM, Mark Fortner wrote: > Richard, > This is pretty critical in order to get Swing applications ported over to > JavaFX. There are a lot of libraries out there that probably will never be > ported to JavaFX, and for which there are no JavaFX equivalents. This kind > of embedding makes is possible for people to at least entertain the idea of > transitioning to JavaFX. > > Is there a JIRA issue for this? > > Cheers, > > Mark > > > > > On Thu, Oct 18, 2012 at 10:54 AM, Richard Bair wrote: > >> The AWT / Glass guys actually have a prototype of all of SwingSet running >> in JavaFX. I think most of the technical hurdles have been resolved (? >> Artem would know better), but it is just a matter of resourcing (there were >> some changes in AWT to get the best performance / integration). >> >> Richard >> >> On Oct 18, 2012, at 10:43 AM, Mario Torre wrote: >> >>> Hi Richard, >>> >>> You should probably look at this old mail, since this may be what you >> need. >>> >>> >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000021.html >>> >>> We need to port this code to 2.2, I'll try to give it some love this >>> week, it should give us also some good performances. >>> >>> Cheers, >>> Mario >>> >>> 2012/10/18 Richard Bair : >>>> From talking with the NB team, one feature they really need is to be >> able to embed Swing within JavaFX. Hopefully we can deliver on that for 8. >>>> >>>> On Oct 17, 2012, at 7:40 AM, Mark Claassen wrote: >>>> >>>>> I joined this list a few days ago because I wanted to start >> contributing >>>>> So far, I am not sure it is quite where I should be. I would like to >>>>> discuss more about the components (table, list boxes, ...). I am not >>>>> exactly sure where to do that. >>>>> >>>>> However, I will add here that I started (a very short-lived) thread on >> the >>>>> netbeans user list along these lines. Basically what I was saying was >> that >>>>> Netbeans is a wonderful UI built on Swing. Could this same project be >> done >>>>> in JavaFX? Maybe not yet, but could it be in the future? It seems >> like >>>>> the JavaFX team could get a lot of advice and requirements from the >>>>> netbeans team. >>>>> >>>>> http://forums.netbeans.org/topic51717.html >>>>> >>>>> Some of the main data structures, like the ObservableList, make me >> cringe. >>>>> I created a similar structure 10 years ago and have since learned the >> error >>>>> of my ways. Granted, the JavaFX team has a lot more resources and >>>>> experience than I did all those years ago, but from my point of view, >> there >>>>> are dangerous waters ahead. >>>>> >>>>> >>>>> On Wed, Oct 17, 2012 at 10:23 AM, Richard Bair < >> richard.bair at oracle.com>wrote: >>>>> >>>>>> We are already doing everything on your list (which was pretty void of >>>>>> specifics). Please list specific work projects, linked to specific >> JIRA >>>>>> issues, and vote for them and for goodness sake contribute! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Oct 17, 2012, at 12:49 AM, Daniel Zwolenski >> wrote: >>>>>> >>>>>>> So Oracle as an organization doesn't think JavaFX can be a player in >> the >>>>>>> web/enterprise space and is backing HTML5. I don't agree, JavaFX has >> the >>>>>> * >>>>>>> potential* to be better. But it's a long way behind and gotten off >> to a >>>>>>> rocky start; there's a hell of a lot of work to be done and the >> current >>>>>>> rate, strategy and direction are not going to be nearly enough. >>>>>>> >>>>>>> Oracle is a big corporation with many different divisions. The left >> arm >>>>>>> doesn't know what the right is doing. So let's put aside 'oracle' >> for a >>>>>>> moment. I want to know: what does the JavaFX team think? Do you want >> to >>>>>> go >>>>>>> up against HTML5 for the client space, or just settle for a spot on >> the >>>>>>> fringe? >>>>>>> >>>>>>> Below is what I propose. >>>>>>> >>>>>>> This proposal needs the full backing of the JavaFX team and >> management. >>>>>>> Specifically it needs: >>>>>>> >>>>>>> 1. Belief that JavaFX can and should be the *number one* client >>>>>>> development platform for enterprise. >>>>>>> 2. Recognition that the current strategy will not make that happen. >>>>>>> 3. Resources (aka people) allocated to the working group outlined >>>>>> below. >>>>>>> These people must have enough influence in the JFX platform to >>>>>> legitimately >>>>>>> be able to influence the direction as needed. >>>>>>> 4. Commitment to supporting this working group fully and implementing >>>>>>> the strategies and recommendations that come out of it as a high >>>>>> priority >>>>>>> 5. A sense of urgency, and a proactive pursuit of achieving these >> goals >>>>>>> with a well defined timeline (i.e. "resources will be allocated by >>>>>> November >>>>>>> 2012" not "we're working on it"). >>>>>>> >>>>>>> In my opinion, all of these must be met 100%. Otherwise there is no >> point >>>>>>> starting at all and better to let it go and leave the enterprise >> space to >>>>>>> other players like HTML5 as 'Oracle' is suggesting. This is your >> call. >>>>>>> >>>>>>> I believe JavaFX can be the best platform for client-side enterprise >>>>>>> application development, capitalising-on, and adding-to Java's >> dominance >>>>>> in >>>>>>> server side enterprise development. >>>>>>> >>>>>>> Do you? >>>>>>> >>>>>>> >>>>>>> *Proposal to form a working group for JavaFX in the enterprise* >>>>>>> >>>>>>> Mission: >>>>>>> >>>>>>> - to position JavaFX as *the* dominant client-side development >> platform >>>>>>> for enterprise/business applications >>>>>>> >>>>>>> >>>>>>> Members: >>>>>>> >>>>>>> - a combination of paid Oracle JavaFX team members, and community >>>>>>> participants. The Oracle members must have the ability to access >> senior >>>>>>> JavaFX management and technical decision makers, and as such >> influence >>>>>> the >>>>>>> road map and direction of the JavaFX platform. Community members will >>>>>> be >>>>>>> those with a background and experience in the enterprise space and >> who >>>>>> are >>>>>>> committed to making JavaFX the platform of choice in this space. >>>>>>> >>>>>>> >>>>>>> Responsibilities: >>>>>>> >>>>>>> - Continuously identify improvements to the JavaFX platform that are >>>>>>> needed to ensure adoption by enterprise; drive the inclusion of these >>>>>> into >>>>>>> the JavaFX platform. >>>>>>> >>>>>>> - Continuously identify and monitor trends and developments within >> the >>>>>>> enterprise space and competitor platforms (e.g. HTML5, .NET, etc) and >>>>>>> ensure the JavaFX roadmap provides confidence to enterprise of >> JavaFX's >>>>>>> long term viability for their needs. >>>>>>> >>>>>>> - Provide best practices, community/forum support, documentation, >>>>>>> examples, tool add-ons, frameworks and other aids for integrating >>>>>> JavaFX >>>>>>> into popular enterprise technology stacks >>>>>>> >>>>>>> - Provide advocacy, publicity and drive general engagement and >> outreach >>>>>>> programs for the adoption of JavaFX in the enterprise. >>>>>>> >>>>>>> >>>>>>> Objectives: >>>>>>> >>>>>>> Objectives will be determined by the working group once formed, >> however >>>>>>> initial objectives will likely include the following: >>>>>>> >>>>>>> - Review the current deployment/distribution options for JavaFX and >>>>>>> determine ways to improve this to make it competitive with other >>>>>> popular >>>>>>> enterprise client platforms (e.g. HTML+JavaScript) for primary >>>>>> enterprise >>>>>>> OS' and platforms >>>>>>> >>>>>>> - Identify the most popular enterprise build and development tools >> and >>>>>>> determine a strategy for making JavaFX integrate into these >>>>>>> >>>>>>> - Review popular trends and toolkits within competitive platforms and >>>>>>> define the ideal frameworks and add-on tools needed by an enterprise >>>>>> client >>>>>>> (e.g. form validation). Use this list of high-level requirements to >>>>>>> determine the low-level JavaFX enhancements needed (e.g. allow field >>>>>>> markers so that a 3rd party validation framework could leverage >> these). >>>>>>> >>>>>>> - Create a demonstration enterprise application (along the lines of >>>>>>> PetClinic) demonstrating best practice for integrating JavaFX in a >>>>>> full, >>>>>>> end-to-end JEE stack. >>>>>>> >>>>>>> >>>>>>> Longer term objectives may include: >>>>>>> >>>>>>> - Develop (or foster community development of) the high-level >>>>>> frameworks >>>>>>> that have been identified as necessary for JavaFX in the enterprise. >>>>>> These >>>>>>> will likely be developed as third-party modules external to the >> JavaFX >>>>>> core >>>>>>> framework (i.e. built on top of the features provided by the core >>>>>> JavaFX >>>>>>> team). >>>>>>> >>>>>>> - Provide integration with existing or new Rapid Application >>>>>> Development >>>>>>> (RAD) tools popular within the enterprise Java space (e.g. ROO, etc). >>>>>> >>>> >>> >>> >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> IcedRobot: www.icedrobot.org >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> Read About us at: http://planet.classpath.org >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >> >> From richard.bair at oracle.com Thu Oct 18 11:20:44 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 11:20:44 -0700 Subject: Swing in FX In-Reply-To: References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <1350582552.2097.115.camel@mercury> Message-ID: <1663C947-65A5-40D4-A194-0C2C868086C7@oracle.com> In fact, I am working on a post to describe the basics for the idea! On Oct 18, 2012, at 11:17 AM, Mario Torre wrote: > 2012/10/18 Richard Bair : >> Ya, the stuff you guys did was awesome and got the ball rolling. Without that we'd have had a much harder time getting something production worthy put together! I will check with the team and see what the likelihood is that they can deliver their solution, and also where it would go. Right now my main focus is on getting everything open sourced as quickly as possible, and rewriting the build system to something simple and sensible for the modules that we really have (whereas now we have many micro-modules). My main focus for the next month or so is to fulfill the promise we made way back last year that we'd open source JavaFX and run like a real open source project. > > Btw, speaking about the build system, since once open sourced we will > need to package this thing for Linux distribution, it may make sense > to discuss this in the open (I know, I know, I'm being pedantic here, > sorry!). This could help also in releasing everything quicker. > > What do you think? > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From richard.bair at oracle.com Thu Oct 18 11:21:59 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 11:21:59 -0700 Subject: Making JavaFX Development Faster In-Reply-To: References: Message-ID: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> Another option I would guess is to not use observable objects at all, but you can still use binding (the property adapters should work with that). Even with a list view, which has an ObservableList, you can add items form a normal list and vice versa. On Oct 18, 2012, at 10:39 AM, Mark Fortner wrote: > One of the big timewasters when it comes to JavaFX projects taking your > server-side POJOs, creating Observable versions of them, and creating > forms, and controllers for them. If you've been doing JEE development in > the past 5 years then you're probably already using Spring ROO, Grails, or > some other RAD tooling that makes this type of work trivial in the web > world. All of these artifacts are usually generated directly from the > POJOs. > > So I'm curious if anyone knows of any tools that make that process easier > and faster? > > > Cheers, > > Mark From markclaassenx at gmail.com Thu Oct 18 11:37:35 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Thu, 18 Oct 2012 14:37:35 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> Message-ID: I got the source and figured it out...or at least found a problem. The TextInputControl.Content seems to be exactly what I need. However, it is not public. Further, the instance variable is a final member in TextInputControl. First, Content, and the default implementations, need to be public so they can be easily extended. I have feeling these were intended to be public when the time was right. Second, there needs to be some way to plug this behavior. If it is going to remain final, then there needs to be a way to specify the Content class in the FXML. The SceneBuilder is clearly the way most UIs are supposed to be designed, so, therefore, it needs to be pretty all-encompassing. Mark On Wed, Oct 17, 2012 at 5:05 PM, Scott Palmer wrote: > Using the override mechanism that Will suggested is probably easier for > converting to uppercase. > > final TextField allCapsTextField = new TextField() { > @Override > public void replaceText(int start, int end, String text) { > super.replaceText(start, end, text.toUppercase()); > } > @Override > public void replaceSelection(String text) { > super.replaceSelection(text.toUppercase()); > } > }; > > or you could still use the Event Filter and handle the insertion of the > characters manually if they are lowercase > and then consume the event. I think that will be more work and be more > error-prone though. As you mention you would have to handle pasting and > drag and drop and all ugly details. Overriding seems cleaner. > > Perhaps you should take a look at the source code to TextInputControl. > Instead of the Document they have a Content interface. Maybe you can do > some of what you want by overriding getContent(). > > Scott > > On 2012-10-17, at 4:41 PM, Mark Claassen wrote: > > > Thanks for the tips. The overriding method does not seem very pluggable, > > so I started with the event filter. > > > > I like the idea of an event filter, and I really like the how JavaFX > > defined the process and the order in which items will receive events. > > > > So, I quickly implemented my event filter like this: > > input.addEventFilter(KeyEvent. > > KEY_TYPED, new EventHandler() { > > @Override > > public void handle(KeyEvent t) { > > if (input.getText().length() >=10) > > t.consume(); > > } > > }); > > > > This works for typing, but, of course, I can paste whatever I wanted. > > (Perhaps I need to find a second filter for that? How about DnD?) > > > > All input events go through the Swing Document, so with that, there was > > just one method to mess with. > > > > Further, I currently have a Document implementation that takes user input > > and converts it to upper case. (It doesn't force the user to type in an > > upper case character, it just converts it if it is not.) Since, in the > > case of a Document, I can control exactly what the data is, this is > pretty > > straightforward. How is that accomplished here? Consume the event, and > > then first a new modified copy of the original. Or do I need to start > > overriding various methods? > > > > > > On Wed, Oct 17, 2012 at 4:40 PM, Mark Claassen >wrote: > > > >> Thanks for the tips. The overriding method does not seem very > pluggable, > >> so I started with the event filter. > >> > >> I like the idea of an event filter, and I really like the how JavaFX > >> defined the process and the order in which items will receive events. > >> > >> So, I quickly implemented my event filter like this: > >> input.addEventFilter(KeyEvent.KEY_TYPED, new > >> EventHandler() { > >> @Override > >> public void handle(KeyEvent t) { > >> if (input.getText().length() >=10) > >> t.consume(); > >> } > >> }); > >> > >> This works for typing, but, of course, I can paste whatever I wanted. > >> (Perhaps I need to find a second filter for that? How about DnD?) > >> > >> All input events go through the Swing Document, so with that, there was > >> just one method to mess with. > >> > >> Further, I currently have a Document implementation that takes user > input > >> and converts it to upper case. (It doesn't force the user to type in an > >> upper case character, it just converts it if it is not.) Since, in the > >> case of a Document, I can control exactly what the data is, this is > pretty > >> straightforward. How is that accomplished here? Consume the event, and > >> then first a new modified copy of the original. Or do I need to start > >> overriding various methods? > >> > >> Mark > >> > >> > >> > >> > >> > >> > >> On Wed, Oct 17, 2012 at 2:13 PM, Will Hoover >wrote: > >> > >>> Have you tried: > >>> > >>> final TextField tf = new TextField() { > >>> final String restictTo = "[A-Z\\s]*"; > >>> @Override > >>> public void replaceText(int start, int end, String text) { > >>> if (matchTest(text)) { > >>> super.replaceText(start, end, text); > >>> } > >>> } > >>> @Override > >>> public void replaceSelection(String text) { > >>> if (matchTest(text)) { > >>> super.replaceSelection(text); > >>> } > >>> } > >>> private boolean matchTest(String text) { > >>> return text.isEmpty() || text.matches(restictTo); > >>> } > >>> }; > >>> > >>> -----Original Message----- > >>> From: openjfx-dev-bounces at openjdk.java.net > >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark > Claassen > >>> Sent: Wednesday, October 17, 2012 1:08 PM > >>> To: openjfx-dev at openjdk.java.net > >>> Subject: TextField Document model > >>> > >>> JTextComponents (like JTextField) has a javax.swing.text.Document model > >>> that > >>> made it pretty easy to create a text field that only allowed a certain > >>> number of characters in it. Similarly, it was also easy to make a > >>> Document > >>> model that took all input, but forced characters to upper case. > >>> > >>> @Override > >>> public void insertString(int offs, String str, AttributeSet a) throws > >>> BadLocationException { > >>> > >>> } > >>> > >>> What is there going to be in JavaFX to accomplish the same goals? > >>> > >>> Mark > >>> > >>> > >> > > From neugens.limasoftware at gmail.com Thu Oct 18 11:38:06 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 18 Oct 2012 20:38:06 +0200 Subject: Swing in FX In-Reply-To: <1663C947-65A5-40D4-A194-0C2C868086C7@oracle.com> References: <1F084963-FE21-4E4D-BE27-5F7A19AD8CC1@oracle.com> <1350582552.2097.115.camel@mercury> <1663C947-65A5-40D4-A194-0C2C868086C7@oracle.com> Message-ID: 2012/10/18 Richard Bair : > In fact, I am working on a post to describe the basics for the idea! \o/ And thanks for all the patience! Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From richard.bair at oracle.com Thu Oct 18 11:42:04 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 11:42:04 -0700 Subject: Open Sourcing Status Report Message-ID: <65D94E2E-335A-478F-BA27-B22308CD6BE0@oracle.com> I wanted to give a status report on where we're at in the process of open sourcing JavaFX. Obviously we started this process earlier this year or late last year (UI Controls went out either last December or this January, I don't remember exactly), but it stalled awaiting internal approvals, but now that those have been cleared, we're moving forward as quickly as we can. For each chunk of code that we open source, we need to perform the following work: - Update the build system to build the open source bits - Review for Security - Sanity check headers - Review rights (some parts like T2K are licensed and cannot be open sourced) The long pole in this process is the "review for security". In some parts of the code, as we audit we may find a potential security hole. Much of the code we will be able to simply fix and then release (or may have no issues anyway in which case it can just be released after audit), but there will likely be some parts that need to wait until the next security release in February 2013 before we can even apply the patches to the workspace, let alone open source the code. I'm hoping this latter category will be small and that most if not all of our code will be clean and we can push before next February. But just a heads-up that it may take until February for the process to complete. In addition, I'm engaged in a proposal for revamping the project structure and build infrastructure. My main goals are: 1) Make it trivial to develop JavaFX using an IDE 2) Allow for partial builds, cross builds (especially speaking of native compilation. Compiling WebKit can take an hour on my system) 3) Download dependencies dynamically 4) Reduce the number of lines in our build script(s) 5) Simplify the project structure Over the last 4 years things have grown to be quite difficult and cumbersome, and on embedded David Hill said he is spending upwards of 40% of his time wrestling with the build system. Further, only a few of us use IDE's to their maximum potential, and only after wrestling quite hard with the system and coming up with our own "magic sauce" for how to build JavaFX. Clearly this isn't scalable or desirable. To declare success, the process needs to be as simple as: 1) Download the Sources 2) Use your favorite IDE to open the project 3) Hit run If I have to concede defeat, then there might be a 2b) 2b) execute a build step to download dependencies I'll send a separate email in a moment discussing what I want to do around project structure (ie: source file layout etc) and the build. Most of our time at present is spent on Security audits, and as soon as we get those done for some chunk of code, we'll move it into the open. Richard From markclaassenx at gmail.com Thu Oct 18 12:03:15 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Thu, 18 Oct 2012 15:03:15 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> Message-ID: My initial proof of concept worked perfectly... limited to 10 characters, forced upper case Altering the source I did the following: Made TextInputControl.Content public Made a setContent(Content content) method in TextInputControl Made the member variable "content" in TextInputControl to be non-final Made TextFieldContent in TextField public Made TextFieldContent in TextField non-static In my source code, I then did: TextInputControl.Content content = new TextField.TextFieldContent() { @Override public void insert(int i, String string, boolean bln) { if (10 - length() => string.length()) super.insert(i, string.toUpperCase(), bln); } }; I don't know why the designers made these things final and private/protected. I would imagine they had a reason, so my JFX source changes would probably need to be more carefully considered. I just wanted tom show it was possible. Mark On Thu, Oct 18, 2012 at 2:37 PM, Mark Claassen wrote: > I got the source and figured it out...or at least found a problem. > > The TextInputControl.Content seems to be exactly what I need. However, it > is not public. Further, the instance variable is a final member in > TextInputControl. > > First, Content, and the default implementations, need to be public so they > can be easily extended. I have feeling these were intended to be public > when the time was right. > > Second, there needs to be some way to plug this behavior. If it is going > to remain final, then there needs to be a way to specify the Content class > in the FXML. The SceneBuilder is clearly the way most UIs are supposed to > be designed, so, therefore, it needs to be pretty all-encompassing. > > Mark > > > On Wed, Oct 17, 2012 at 5:05 PM, Scott Palmer wrote: > >> Using the override mechanism that Will suggested is probably easier for >> converting to uppercase. >> >> final TextField allCapsTextField = new TextField() { >> @Override >> public void replaceText(int start, int end, String text) { >> super.replaceText(start, end, text.toUppercase()); >> } >> @Override >> public void replaceSelection(String text) { >> super.replaceSelection(text.toUppercase()); >> } >> }; >> >> or you could still use the Event Filter and handle the insertion of the >> characters manually if they are lowercase >> and then consume the event. I think that will be more work and be more >> error-prone though. As you mention you would have to handle pasting and >> drag and drop and all ugly details. Overriding seems cleaner. >> >> Perhaps you should take a look at the source code to TextInputControl. >> Instead of the Document they have a Content interface. Maybe you can do >> some of what you want by overriding getContent(). >> >> Scott >> >> On 2012-10-17, at 4:41 PM, Mark Claassen wrote: >> >> > Thanks for the tips. The overriding method does not seem very >> pluggable, >> > so I started with the event filter. >> > >> > I like the idea of an event filter, and I really like the how JavaFX >> > defined the process and the order in which items will receive events. >> > >> > So, I quickly implemented my event filter like this: >> > input.addEventFilter(KeyEvent. >> > KEY_TYPED, new EventHandler() { >> > @Override >> > public void handle(KeyEvent t) { >> > if (input.getText().length() >=10) >> > t.consume(); >> > } >> > }); >> > >> > This works for typing, but, of course, I can paste whatever I wanted. >> > (Perhaps I need to find a second filter for that? How about DnD?) >> > >> > All input events go through the Swing Document, so with that, there was >> > just one method to mess with. >> > >> > Further, I currently have a Document implementation that takes user >> input >> > and converts it to upper case. (It doesn't force the user to type in an >> > upper case character, it just converts it if it is not.) Since, in the >> > case of a Document, I can control exactly what the data is, this is >> pretty >> > straightforward. How is that accomplished here? Consume the event, and >> > then first a new modified copy of the original. Or do I need to start >> > overriding various methods? >> > >> > >> > On Wed, Oct 17, 2012 at 4:40 PM, Mark Claassen > >wrote: >> > >> >> Thanks for the tips. The overriding method does not seem very >> pluggable, >> >> so I started with the event filter. >> >> >> >> I like the idea of an event filter, and I really like the how JavaFX >> >> defined the process and the order in which items will receive events. >> >> >> >> So, I quickly implemented my event filter like this: >> >> input.addEventFilter(KeyEvent.KEY_TYPED, new >> >> EventHandler() { >> >> @Override >> >> public void handle(KeyEvent t) { >> >> if (input.getText().length() >=10) >> >> t.consume(); >> >> } >> >> }); >> >> >> >> This works for typing, but, of course, I can paste whatever I wanted. >> >> (Perhaps I need to find a second filter for that? How about DnD?) >> >> >> >> All input events go through the Swing Document, so with that, there was >> >> just one method to mess with. >> >> >> >> Further, I currently have a Document implementation that takes user >> input >> >> and converts it to upper case. (It doesn't force the user to type in >> an >> >> upper case character, it just converts it if it is not.) Since, in the >> >> case of a Document, I can control exactly what the data is, this is >> pretty >> >> straightforward. How is that accomplished here? Consume the event, >> and >> >> then first a new modified copy of the original. Or do I need to start >> >> overriding various methods? >> >> >> >> Mark >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Oct 17, 2012 at 2:13 PM, Will Hoover > >wrote: >> >> >> >>> Have you tried: >> >>> >> >>> final TextField tf = new TextField() { >> >>> final String restictTo = "[A-Z\\s]*"; >> >>> @Override >> >>> public void replaceText(int start, int end, String text) { >> >>> if (matchTest(text)) { >> >>> super.replaceText(start, end, text); >> >>> } >> >>> } >> >>> @Override >> >>> public void replaceSelection(String text) { >> >>> if (matchTest(text)) { >> >>> super.replaceSelection(text); >> >>> } >> >>> } >> >>> private boolean matchTest(String text) { >> >>> return text.isEmpty() || text.matches(restictTo); >> >>> } >> >>> }; >> >>> >> >>> -----Original Message----- >> >>> From: openjfx-dev-bounces at openjdk.java.net >> >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark >> Claassen >> >>> Sent: Wednesday, October 17, 2012 1:08 PM >> >>> To: openjfx-dev at openjdk.java.net >> >>> Subject: TextField Document model >> >>> >> >>> JTextComponents (like JTextField) has a javax.swing.text.Document >> model >> >>> that >> >>> made it pretty easy to create a text field that only allowed a certain >> >>> number of characters in it. Similarly, it was also easy to make a >> >>> Document >> >>> model that took all input, but forced characters to upper case. >> >>> >> >>> @Override >> >>> public void insertString(int offs, String str, AttributeSet a) throws >> >>> BadLocationException { >> >>> >> >>> } >> >>> >> >>> What is there going to be in JavaFX to accomplish the same goals? >> >>> >> >>> Mark >> >>> >> >>> >> >> >> >> > From richard.bair at oracle.com Thu Oct 18 12:16:13 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 12:16:13 -0700 Subject: Refactoring JavaFX Builds & Sources Message-ID: I've spent a couple days (spread out over the last week and a half or so) looking at our build system and what we can do to improve it. As I have mentioned in other threads, my test for success in the build system is if a developer wanting to change Java code simply had to: 1) Download (or Clone) the sources 2) Open the JavaFX project in their IDE of choice (IntelliJ IDEA, Eclipse, Netbeans) 3) Hit "run" and it runs Ensemble. And likewise, hitting "test" should run all the automatic tests and hitting "coverage" should generate code coverage stats, and "debug" should work -- exactly as one might hope. Today, in order to make this work, Steve has a carefully constructed Eclipse project setup and I have a carefully (laboriously) constructed IDEA setup and nobody has a very good NetBeans setup. This is bad. Further more, you should be able to do "find usages" in your IDE and get EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't have enough information about the 160 other projects in our system to be able to do this. This is bad. Right now we build with ant. Many of you have suggested Maven. Some of you at JavaOne suggested Gradle. I am presently looking into Gradle. The key things I like about Gradle are: 1) It isn't XML 2) Like Ivy & Maven, it handles dependencies well We presently have a pile of XML files and nasty build logic for downloading dependencies (this is all in the closed repo, but you would be exposed to the horror if we just made it all public). I wanted instead to use Ivy at the very least, but rather if I can get better build happiness from another setup entirely (like Gradle) then I might as well give it a try. Of course, I'm hoping Danno & Andres will help maintain the build scripts :-D I have two different scripts, one which is to be used during transition, and will generate the "new world" from the old, and another which will be the build file going forward. I want to emphasize that this is at the moment only a prototype. Also, there will be no loss in functionality migrating from the current system to any future system. In particular: 1) I'll make sure cross builds all continue to work 2) Partial builds (for native code particularly) will continue to work such that you don't HAVE to build native code 3) It will produce bit-for-bit compatible output in the artifacts/ directory, so all our RE (Release Engineering) scripts continue to work with little or no modification Also, in my tests so far the speed of the build is dramatically faster -- but then I don't have everything in yet so that might just be wishful thinking. I hope and expect it to be faster though. We generate code in our build system for the following reasons: 1) We have a VersionInfo class which the build system will update with version information. It is a com.sun.something class 2) We have an annotation processor which generates all of the builders 3) We have two grammars that Antlr has process to produce parsers -- one for JSL (for our shaders) and one for CSS 4) We have a "decora compiler" which takes JSL files and feeds it through the JSL parser and produces code / shaders In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. Also, testing. We have a variety of tests that we need to organize better. At the moment we have basically two types of tests: JUnit tests and SQE has visual tests (using Jemmy). The unit tests are all going open source along with the code projects they belong to. We have not yet got complete clearance for all of the SQE tests, although I firmly believe it is the right thing to do, and will push on it again once the rest of our "homework" (fixing the build system etc) is taken care of. I have found that some of our unit tests are written such that they require more of the platform, rather than just one class. So for example, there are tests in the scene graph which might want to use a UI control for some purpose. I'm thinking the easiest thing to do is to have a test directory at the top level which houses all the tests, and break them up based on whether they are part of the smoke test, integration test, or manual test suite. Smoke tests are those that are run continuously. They must be headless, and they must be completely automated, and they must execute within some reasonable amount of time (since hudson is going to be doing it continuously). The integration tests are the rest of the automated tests that need to be run between every integration with "master". Finally the manual tests are not run as part of the integration / smoke tests, but really are just little "toys" or apps we've written that are useful when developing a feature or whatnot. We've got a ton of these little guys (mostly of the "HelloWorld" variety), and these would go into "manual". We also will have an apps directory, where we will place all the samples (like Ensemble) and experiments (like the JavaOne Schedule Builder). And I want to have a "benchmarks" directory where all of our benchmarks will live. The only problem with this one is that we have a dependency on JRockit benchmark harness, and I'm not sure how to resolve that with the open source bits. Maybe the JRockit benchmark harness is already open source, I haven't dug into it yet to find out. However I believe we *must* have benchmarks open, as well as the SQE tests. My goal is to run OpenJFX in the open and to have meaningful contributions -- how can that happen if we're keeping back essential verification tools? How can somebody submit a patch and not know whether it is going to impact performance? So I want to get the benchmarks all out, but we need to figure out what to do about this dependency. Another option is to replace this dependency with one of the other open source benchmark harnesses, but this would need to be carefully considered as it would disrupt our benchmark reporting for some period of time. But ultimately having public numbers and public tests would, I think, be very beneficial across the board. So, I am proposing a project structure something like: javafx/ apps experiments samples build-tools src/java (annotation stuff) modules base (javafx.beans, javafx.collections, etc) graphics (scene graph, prism, glass) controls (controls, charts) src/ decora-d3d prism-egl ... java swing (javafx.embed.swing) swt (javafx.embed.swt) media web tests smoke integration manual Each module directory is basically just a home for the sources. All native sources are right there along with the Java sources, and we pick the right natives to use depending on what the build target is (for all the cross-compile stuff). Thoughts? Richard From richard.bair at oracle.com Thu Oct 18 12:28:33 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 12:28:33 -0700 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> Message-ID: <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> I think Greg did make it all mutable initially, and I probably made them final. This was likely due to the fact that the text controls were being rewritten only weeks before the 2.0 release and it was easier to prove correctness when the Content wasn't changing. Note that "Content" is protected already, so from our perspective it is public API, so making it public isn't a big change for us. The question is whether Content should be pluggable on a given TextInputControl, or whether it should require subclassing. I think I remember at one point the theory being, just subclass and provide your own Content in the call to super's constructor. However there was a problem with this, because TextInputControlSkin wasn't public, and TextFieldSkin etc require a specific subtype of TextInputControl, and as such, you couldn't realistically create any subclass of TextInputControl (crap!). I discovered that problem after we shipped 2.0. I think if we want to make content mutable, then we need to do a comprehensive review to see where it might fail in the control & in the skin. That is, does the skin get a reference to the content and hold on to it? Or does it always call getContent() when it needs a reference? If the content changes, do we need to clean any state on the skin or on the control? In your case I'm guessing the content is set before the skin is, and never thereafter changed, and so it acts as though it is an immutable property still, so things work great. I'm guessing though that dynamically changing the content at runtime might cause some issues? I don't have any philosophical reason for not having content be mutable. My only concern here is that having it mutable introduces some additional complexity in the class / skin -- or at least it might. BTW, if you find that changing it dynamically works perfect, I'd be happy to do the code review (including Jonathan). Thanks Richard On Oct 18, 2012, at 12:03 PM, Mark Claassen wrote: > My initial proof of concept worked perfectly... limited to 10 characters, > forced upper case > > Altering the source I did the following: > Made TextInputControl.Content public > Made a setContent(Content content) method in TextInputControl > Made the member variable "content" in TextInputControl to be non-final > Made TextFieldContent in TextField public > Made TextFieldContent in TextField non-static > > In my source code, I then did: > TextInputControl.Content content = new TextField.TextFieldContent() > { > @Override > public void insert(int i, String string, boolean bln) { > if (10 - length() => string.length()) > super.insert(i, string.toUpperCase(), bln); > } > }; > > I don't know why the designers made these things final and > private/protected. I would imagine they had a reason, so my JFX source > changes would probably need to be more carefully considered. I just wanted > tom show it was possible. > > Mark > > > On Thu, Oct 18, 2012 at 2:37 PM, Mark Claassen wrote: > >> I got the source and figured it out...or at least found a problem. >> >> The TextInputControl.Content seems to be exactly what I need. However, it >> is not public. Further, the instance variable is a final member in >> TextInputControl. >> >> First, Content, and the default implementations, need to be public so they >> can be easily extended. I have feeling these were intended to be public >> when the time was right. >> >> Second, there needs to be some way to plug this behavior. If it is going >> to remain final, then there needs to be a way to specify the Content class >> in the FXML. The SceneBuilder is clearly the way most UIs are supposed to >> be designed, so, therefore, it needs to be pretty all-encompassing. >> >> Mark >> >> >> On Wed, Oct 17, 2012 at 5:05 PM, Scott Palmer wrote: >> >>> Using the override mechanism that Will suggested is probably easier for >>> converting to uppercase. >>> >>> final TextField allCapsTextField = new TextField() { >>> @Override >>> public void replaceText(int start, int end, String text) { >>> super.replaceText(start, end, text.toUppercase()); >>> } >>> @Override >>> public void replaceSelection(String text) { >>> super.replaceSelection(text.toUppercase()); >>> } >>> }; >>> >>> or you could still use the Event Filter and handle the insertion of the >>> characters manually if they are lowercase >>> and then consume the event. I think that will be more work and be more >>> error-prone though. As you mention you would have to handle pasting and >>> drag and drop and all ugly details. Overriding seems cleaner. >>> >>> Perhaps you should take a look at the source code to TextInputControl. >>> Instead of the Document they have a Content interface. Maybe you can do >>> some of what you want by overriding getContent(). >>> >>> Scott >>> >>> On 2012-10-17, at 4:41 PM, Mark Claassen wrote: >>> >>>> Thanks for the tips. The overriding method does not seem very >>> pluggable, >>>> so I started with the event filter. >>>> >>>> I like the idea of an event filter, and I really like the how JavaFX >>>> defined the process and the order in which items will receive events. >>>> >>>> So, I quickly implemented my event filter like this: >>>> input.addEventFilter(KeyEvent. >>>> KEY_TYPED, new EventHandler() { >>>> @Override >>>> public void handle(KeyEvent t) { >>>> if (input.getText().length() >=10) >>>> t.consume(); >>>> } >>>> }); >>>> >>>> This works for typing, but, of course, I can paste whatever I wanted. >>>> (Perhaps I need to find a second filter for that? How about DnD?) >>>> >>>> All input events go through the Swing Document, so with that, there was >>>> just one method to mess with. >>>> >>>> Further, I currently have a Document implementation that takes user >>> input >>>> and converts it to upper case. (It doesn't force the user to type in an >>>> upper case character, it just converts it if it is not.) Since, in the >>>> case of a Document, I can control exactly what the data is, this is >>> pretty >>>> straightforward. How is that accomplished here? Consume the event, and >>>> then first a new modified copy of the original. Or do I need to start >>>> overriding various methods? >>>> >>>> >>>> On Wed, Oct 17, 2012 at 4:40 PM, Mark Claassen >>> wrote: >>>> >>>>> Thanks for the tips. The overriding method does not seem very >>> pluggable, >>>>> so I started with the event filter. >>>>> >>>>> I like the idea of an event filter, and I really like the how JavaFX >>>>> defined the process and the order in which items will receive events. >>>>> >>>>> So, I quickly implemented my event filter like this: >>>>> input.addEventFilter(KeyEvent.KEY_TYPED, new >>>>> EventHandler() { >>>>> @Override >>>>> public void handle(KeyEvent t) { >>>>> if (input.getText().length() >=10) >>>>> t.consume(); >>>>> } >>>>> }); >>>>> >>>>> This works for typing, but, of course, I can paste whatever I wanted. >>>>> (Perhaps I need to find a second filter for that? How about DnD?) >>>>> >>>>> All input events go through the Swing Document, so with that, there was >>>>> just one method to mess with. >>>>> >>>>> Further, I currently have a Document implementation that takes user >>> input >>>>> and converts it to upper case. (It doesn't force the user to type in >>> an >>>>> upper case character, it just converts it if it is not.) Since, in the >>>>> case of a Document, I can control exactly what the data is, this is >>> pretty >>>>> straightforward. How is that accomplished here? Consume the event, >>> and >>>>> then first a new modified copy of the original. Or do I need to start >>>>> overriding various methods? >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Oct 17, 2012 at 2:13 PM, Will Hoover >>> wrote: >>>>> >>>>>> Have you tried: >>>>>> >>>>>> final TextField tf = new TextField() { >>>>>> final String restictTo = "[A-Z\\s]*"; >>>>>> @Override >>>>>> public void replaceText(int start, int end, String text) { >>>>>> if (matchTest(text)) { >>>>>> super.replaceText(start, end, text); >>>>>> } >>>>>> } >>>>>> @Override >>>>>> public void replaceSelection(String text) { >>>>>> if (matchTest(text)) { >>>>>> super.replaceSelection(text); >>>>>> } >>>>>> } >>>>>> private boolean matchTest(String text) { >>>>>> return text.isEmpty() || text.matches(restictTo); >>>>>> } >>>>>> }; >>>>>> >>>>>> -----Original Message----- >>>>>> From: openjfx-dev-bounces at openjdk.java.net >>>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark >>> Claassen >>>>>> Sent: Wednesday, October 17, 2012 1:08 PM >>>>>> To: openjfx-dev at openjdk.java.net >>>>>> Subject: TextField Document model >>>>>> >>>>>> JTextComponents (like JTextField) has a javax.swing.text.Document >>> model >>>>>> that >>>>>> made it pretty easy to create a text field that only allowed a certain >>>>>> number of characters in it. Similarly, it was also easy to make a >>>>>> Document >>>>>> model that took all input, but forced characters to upper case. >>>>>> >>>>>> @Override >>>>>> public void insertString(int offs, String str, AttributeSet a) throws >>>>>> BadLocationException { >>>>>> >>>>>> } >>>>>> >>>>>> What is there going to be in JavaFX to accomplish the same goals? >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>> >>> >>> >> From markclaassenx at gmail.com Thu Oct 18 13:00:48 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Thu, 18 Oct 2012 16:00:48 -0400 Subject: TextField Document model In-Reply-To: <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> Message-ID: > BTW, if you find that changing it dynamically works perfect, I'd be happy to do the code review (including Jonathan). Sure. How do I proceed with this? Create a Jira issue and then submit the changes that way? > Content should be pluggable on a given TextInputControl, or whether it should require subclassing. Subclassing seems a bit inconvenient. To control the input on every text field on a form, all the fields would need to be custom components. This would mean that there would be very few TextFields in my app, I would have just MyTextField everywhere. Also, how would I code it? If I was just using setContent() I would do something like: firstField.setContent(new RestrictedLengthContent(Person.FIRST_NAME_LENGTH)); lastField.setContent(new RestrictedLengthContent(Person.LAST_NAME_LENGTH)); How would I do that in subclasses and still use SceneBuilder? Maybe there would be a way in SceneBuilder to allow the use of a parameterized constructor with a custom parameter, but that seems pretty complex. > In your case I'm guessing the content is set before... I just provided you with one easy case. In reality, we try to be far more clever. ;-) However, that is mostly right, and with all these new tools in FX, I think we will make different choices when that time comes. > might fail in the control & in the skin I am pretty new to this, and I have not really addressed the Skin and Behavior aspects of everything. Is there a good place to learn how this all is intended to work together? It sounds like this is to break apart the PLAF Look and the PLAF Feel. (Also, a FX skin is more about how things are painted, and is not the definition that some products use where a different skin completely rearranges the UI.) Mark On Thu, Oct 18, 2012 at 3:28 PM, Richard Bair wrote: > I think Greg did make it all mutable initially, and I probably made them > final. This was likely due to the fact that the text controls were being > rewritten only weeks before the 2.0 release and it was easier to prove > correctness when the Content wasn't changing. Note that "Content" is > protected already, so from our perspective it is public API, so making it > public isn't a big change for us. The question is whether Content should be > pluggable on a given TextInputControl, or whether it should require > subclassing. > > I think I remember at one point the theory being, just subclass and > provide your own Content in the call to super's constructor. However there > was a problem with this, because TextInputControlSkin wasn't public, and > TextFieldSkin etc require a specific subtype of TextInputControl, and as > such, you couldn't realistically create any subclass of TextInputControl > (crap!). I discovered that problem after we shipped 2.0. > > I think if we want to make content mutable, then we need to do a > comprehensive review to see where it might fail in the control & in the > skin. That is, does the skin get a reference to the content and hold on to > it? Or does it always call getContent() when it needs a reference? If the > content changes, do we need to clean any state on the skin or on the > control? In your case I'm guessing the content is set before the skin is, > and never thereafter changed, and so it acts as though it is an immutable > property still, so things work great. I'm guessing though that dynamically > changing the content at runtime might cause some issues? > > I don't have any philosophical reason for not having content be mutable. > My only concern here is that having it mutable introduces some additional > complexity in the class / skin -- or at least it might. > > BTW, if you find that changing it dynamically works perfect, I'd be happy > to do the code review (including Jonathan). > > Thanks > Richard > > On Oct 18, 2012, at 12:03 PM, Mark Claassen wrote: > > > My initial proof of concept worked perfectly... limited to 10 characters, > > forced upper case > > > > Altering the source I did the following: > > Made TextInputControl.Content public > > Made a setContent(Content content) method in TextInputControl > > Made the member variable "content" in TextInputControl to be non-final > > Made TextFieldContent in TextField public > > Made TextFieldContent in TextField non-static > > > > In my source code, I then did: > > TextInputControl.Content content = new > TextField.TextFieldContent() > > { > > @Override > > public void insert(int i, String string, boolean bln) { > > if (10 - length() => string.length()) > > super.insert(i, string.toUpperCase(), bln); > > } > > }; > > > > I don't know why the designers made these things final and > > private/protected. I would imagine they had a reason, so my JFX source > > changes would probably need to be more carefully considered. I just > wanted > > tom show it was possible. > > > > Mark > > > > > > On Thu, Oct 18, 2012 at 2:37 PM, Mark Claassen >wrote: > > > >> I got the source and figured it out...or at least found a problem. > >> > >> The TextInputControl.Content seems to be exactly what I need. However, > it > >> is not public. Further, the instance variable is a final member in > >> TextInputControl. > >> > >> First, Content, and the default implementations, need to be public so > they > >> can be easily extended. I have feeling these were intended to be public > >> when the time was right. > >> > >> Second, there needs to be some way to plug this behavior. If it is > going > >> to remain final, then there needs to be a way to specify the Content > class > >> in the FXML. The SceneBuilder is clearly the way most UIs are supposed > to > >> be designed, so, therefore, it needs to be pretty all-encompassing. > >> > >> Mark > >> > >> > >> On Wed, Oct 17, 2012 at 5:05 PM, Scott Palmer > wrote: > >> > >>> Using the override mechanism that Will suggested is probably easier for > >>> converting to uppercase. > >>> > >>> final TextField allCapsTextField = new TextField() { > >>> @Override > >>> public void replaceText(int start, int end, String text) { > >>> super.replaceText(start, end, text.toUppercase()); > >>> } > >>> @Override > >>> public void replaceSelection(String text) { > >>> super.replaceSelection(text.toUppercase()); > >>> } > >>> }; > >>> > >>> or you could still use the Event Filter and handle the insertion of the > >>> characters manually if they are lowercase > >>> and then consume the event. I think that will be more work and be more > >>> error-prone though. As you mention you would have to handle pasting > and > >>> drag and drop and all ugly details. Overriding seems cleaner. > >>> > >>> Perhaps you should take a look at the source code to TextInputControl. > >>> Instead of the Document they have a Content interface. Maybe you can > do > >>> some of what you want by overriding getContent(). > >>> > >>> Scott > >>> > >>> On 2012-10-17, at 4:41 PM, Mark Claassen > wrote: > >>> > >>>> Thanks for the tips. The overriding method does not seem very > >>> pluggable, > >>>> so I started with the event filter. > >>>> > >>>> I like the idea of an event filter, and I really like the how JavaFX > >>>> defined the process and the order in which items will receive events. > >>>> > >>>> So, I quickly implemented my event filter like this: > >>>> input.addEventFilter(KeyEvent. > >>>> KEY_TYPED, new EventHandler() { > >>>> @Override > >>>> public void handle(KeyEvent t) { > >>>> if (input.getText().length() >=10) > >>>> t.consume(); > >>>> } > >>>> }); > >>>> > >>>> This works for typing, but, of course, I can paste whatever I wanted. > >>>> (Perhaps I need to find a second filter for that? How about DnD?) > >>>> > >>>> All input events go through the Swing Document, so with that, there > was > >>>> just one method to mess with. > >>>> > >>>> Further, I currently have a Document implementation that takes user > >>> input > >>>> and converts it to upper case. (It doesn't force the user to type in > an > >>>> upper case character, it just converts it if it is not.) Since, in > the > >>>> case of a Document, I can control exactly what the data is, this is > >>> pretty > >>>> straightforward. How is that accomplished here? Consume the event, > and > >>>> then first a new modified copy of the original. Or do I need to start > >>>> overriding various methods? > >>>> > >>>> > >>>> On Wed, Oct 17, 2012 at 4:40 PM, Mark Claassen < > markclaassenx at gmail.com > >>>> wrote: > >>>> > >>>>> Thanks for the tips. The overriding method does not seem very > >>> pluggable, > >>>>> so I started with the event filter. > >>>>> > >>>>> I like the idea of an event filter, and I really like the how JavaFX > >>>>> defined the process and the order in which items will receive events. > >>>>> > >>>>> So, I quickly implemented my event filter like this: > >>>>> input.addEventFilter(KeyEvent.KEY_TYPED, new > >>>>> EventHandler() { > >>>>> @Override > >>>>> public void handle(KeyEvent t) { > >>>>> if (input.getText().length() >=10) > >>>>> t.consume(); > >>>>> } > >>>>> }); > >>>>> > >>>>> This works for typing, but, of course, I can paste whatever I wanted. > >>>>> (Perhaps I need to find a second filter for that? How about DnD?) > >>>>> > >>>>> All input events go through the Swing Document, so with that, there > was > >>>>> just one method to mess with. > >>>>> > >>>>> Further, I currently have a Document implementation that takes user > >>> input > >>>>> and converts it to upper case. (It doesn't force the user to type in > >>> an > >>>>> upper case character, it just converts it if it is not.) Since, in > the > >>>>> case of a Document, I can control exactly what the data is, this is > >>> pretty > >>>>> straightforward. How is that accomplished here? Consume the event, > >>> and > >>>>> then first a new modified copy of the original. Or do I need to > start > >>>>> overriding various methods? > >>>>> > >>>>> Mark > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Oct 17, 2012 at 2:13 PM, Will Hoover >>>> wrote: > >>>>> > >>>>>> Have you tried: > >>>>>> > >>>>>> final TextField tf = new TextField() { > >>>>>> final String restictTo = "[A-Z\\s]*"; > >>>>>> @Override > >>>>>> public void replaceText(int start, int end, String text) { > >>>>>> if (matchTest(text)) { > >>>>>> super.replaceText(start, end, text); > >>>>>> } > >>>>>> } > >>>>>> @Override > >>>>>> public void replaceSelection(String text) { > >>>>>> if (matchTest(text)) { > >>>>>> super.replaceSelection(text); > >>>>>> } > >>>>>> } > >>>>>> private boolean matchTest(String text) { > >>>>>> return text.isEmpty() || text.matches(restictTo); > >>>>>> } > >>>>>> }; > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: openjfx-dev-bounces at openjdk.java.net > >>>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark > >>> Claassen > >>>>>> Sent: Wednesday, October 17, 2012 1:08 PM > >>>>>> To: openjfx-dev at openjdk.java.net > >>>>>> Subject: TextField Document model > >>>>>> > >>>>>> JTextComponents (like JTextField) has a javax.swing.text.Document > >>> model > >>>>>> that > >>>>>> made it pretty easy to create a text field that only allowed a > certain > >>>>>> number of characters in it. Similarly, it was also easy to make a > >>>>>> Document > >>>>>> model that took all input, but forced characters to upper case. > >>>>>> > >>>>>> @Override > >>>>>> public void insertString(int offs, String str, AttributeSet a) > throws > >>>>>> BadLocationException { > >>>>>> > >>>>>> } > >>>>>> > >>>>>> What is there going to be in JavaFX to accomplish the same goals? > >>>>>> > >>>>>> Mark > >>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > > From hang.vo at oracle.com Thu Oct 18 13:03:42 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 18 Oct 2012 20:03:42 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-23812 StackedAreaChart ClassCastException on CategoryAxis Message-ID: <20121018200347.105FA4741F@hg.openjdk.java.net> Changeset: d811a42d75ba Author: Paru Somashekar Date: 2012-10-18 12:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d811a42d75ba fix RT-23812 StackedAreaChart ClassCastException on CategoryAxis + unit test. ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java From phidias51 at gmail.com Thu Oct 18 13:04:17 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 18 Oct 2012 13:04:17 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: Hi Richard, There's probably two overlapping aims here: 1) to build JavaFX itself, and 2) to build JavaFX projects (in your case, projects like Ensemble). As you pointed out, Maven can be rigid if you want to do something that it doesn't normally do. It's goal is value convention over configuration. But you can mix and match Maven and Gradle, or you can write your own Mojo to provide any custom functionality (it's similar to writing an Ant Task). The nice thing about Maven is that you can use the artifacts with Gradle, Ivy and other build tools. And those tools include plugins that let them interoperate with maven builds. As I mentioned in this issue: http://javafx-jira.kenai.com/browse/RT-25723 You can generate project files for most IDEs. Most external developers won't really want to build the native bits. In the past I've created jars that include native DLLs, SOs, and added those as dependencies. If you are using Hudson or some other CI tool, it should be able to handle nightly builds and publish them to a Maven compliant repo (thus making them usable by anyone using Maven, Gradle, or Ivy). The next time a developer builds, it will fetch the latest build including the native bits (assuming that they've configured their POMs to depend on the latest SNAPSHOT). Hudson can also handle generating the coverage, and test reports for you. Mark On Thu, Oct 18, 2012 at 12:16 PM, Richard Bair wrote: > I've spent a couple days (spread out over the last week and a half or so) > looking at our build system and what we can do to improve it. As I have > mentioned in other threads, my test for success in the build system is if a > developer wanting to change Java code simply had to: > > 1) Download (or Clone) the sources > 2) Open the JavaFX project in their IDE of choice (IntelliJ IDEA, > Eclipse, Netbeans) > 3) Hit "run" and it runs Ensemble. > > And likewise, hitting "test" should run all the automatic tests and > hitting "coverage" should generate code coverage stats, and "debug" should > work -- exactly as one might hope. Today, in order to make this work, Steve > has a carefully constructed Eclipse project setup and I have a carefully > (laboriously) constructed IDEA setup and nobody has a very good NetBeans > setup. This is bad. > > Further more, you should be able to do "find usages" in your IDE and get > EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't > have enough information about the 160 other projects in our system to be > able to do this. This is bad. > > Right now we build with ant. Many of you have suggested Maven. Some of you > at JavaOne suggested Gradle. I am presently looking into Gradle. The key > things I like about Gradle are: > > 1) It isn't XML > 2) Like Ivy & Maven, it handles dependencies well > > We presently have a pile of XML files and nasty build logic for > downloading dependencies (this is all in the closed repo, but you would be > exposed to the horror if we just made it all public). I wanted instead to > use Ivy at the very least, but rather if I can get better build happiness > from another setup entirely (like Gradle) then I might as well give it a > try. > > Of course, I'm hoping Danno & Andres will help maintain the build scripts > :-D > > I have two different scripts, one which is to be used during transition, > and will generate the "new world" from the old, and another which will be > the build file going forward. I want to emphasize that this is at the > moment only a prototype. Also, there will be no loss in functionality > migrating from the current system to any future system. In particular: > > 1) I'll make sure cross builds all continue to work > 2) Partial builds (for native code particularly) will continue to > work such that you don't HAVE to build native code > 3) It will produce bit-for-bit compatible output in the artifacts/ > directory, so all our RE (Release Engineering) scripts continue to work > with little or no modification > > Also, in my tests so far the speed of the build is dramatically faster -- > but then I don't have everything in yet so that might just be wishful > thinking. I hope and expect it to be faster though. > > We generate code in our build system for the following reasons: > > 1) We have a VersionInfo class which the build system will update > with version information. It is a com.sun.something class > 2) We have an annotation processor which generates all of the > builders > 3) We have two grammars that Antlr has process to produce parsers > -- one for JSL (for our shaders) and one for CSS > 4) We have a "decora compiler" which takes JSL files and feeds it > through the JSL parser and produces code / shaders > > In addition to code generation, we also build a ton of native code > (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit > into the build system. Building native code is SLOW, so being able to avoid > it for "normal" developers, and being able to avoid native builds when > nothing changed in the native code, is important. > > Also, testing. We have a variety of tests that we need to organize better. > At the moment we have basically two types of tests: JUnit tests and SQE has > visual tests (using Jemmy). The unit tests are all going open source along > with the code projects they belong to. We have not yet got complete > clearance for all of the SQE tests, although I firmly believe it is the > right thing to do, and will push on it again once the rest of our > "homework" (fixing the build system etc) is taken care of. > > I have found that some of our unit tests are written such that they > require more of the platform, rather than just one class. So for example, > there are tests in the scene graph which might want to use a UI control for > some purpose. I'm thinking the easiest thing to do is to have a test > directory at the top level which houses all the tests, and break them up > based on whether they are part of the smoke test, integration test, or > manual test suite. Smoke tests are those that are run continuously. They > must be headless, and they must be completely automated, and they must > execute within some reasonable amount of time (since hudson is going to be > doing it continuously). The integration tests are the rest of the automated > tests that need to be run between every integration with "master". Finally > the manual tests are not run as part of the integration / smoke tests, but > really are just little "toys" or apps we've written that are useful when > developing a feature or whatnot. We've got a ton of these little guys > (mostly of the "HelloWorld" variety), and these would go into "manual". > > We also will have an apps directory, where we will place all the samples > (like Ensemble) and experiments (like the JavaOne Schedule Builder). > > And I want to have a "benchmarks" directory where all of our benchmarks > will live. The only problem with this one is that we have a dependency on > JRockit benchmark harness, and I'm not sure how to resolve that with the > open source bits. Maybe the JRockit benchmark harness is already open > source, I haven't dug into it yet to find out. However I believe we *must* > have benchmarks open, as well as the SQE tests. My goal is to run OpenJFX > in the open and to have meaningful contributions -- how can that happen if > we're keeping back essential verification tools? How can somebody submit a > patch and not know whether it is going to impact performance? So I want to > get the benchmarks all out, but we need to figure out what to do about this > dependency. Another option is to replace this dependency with one of the > other open source benchmark harnesses, but this would need to be carefully > considered as it would disrupt our benchmark reporting for some period of > time. But ultimately having public numbers and public tests would, I think, > be very beneficial across the board. > > So, I am proposing a project structure something like: > > javafx/ > apps > experiments > samples > build-tools > src/java (annotation stuff) > modules > base (javafx.beans, javafx.collections, etc) > graphics (scene graph, prism, glass) > controls (controls, charts) > src/ > decora-d3d > prism-egl > ... > java > swing (javafx.embed.swing) > swt (javafx.embed.swt) > media > web > tests > smoke > integration > manual > > Each module directory is basically just a home for the sources. All native > sources are right there along with the Java sources, and we pick the right > natives to use depending on what the build target is (for all the > cross-compile stuff). > > Thoughts? > Richard From richard.bair at oracle.com Thu Oct 18 13:16:52 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 13:16:52 -0700 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> Message-ID: <7BE4C851-66CE-47C4-9868-E7C49CD48667@oracle.com> > Sure. How do I proceed with this? Create a Jira issue and then submit the > changes that way? Yes, that would be best. If the code is relatively simple, then that is all you need to do. If it is more complex, then (bear with me) you will need to sign and send in the Oracle Contributor Agreement which gives oracle joint copyright so that we can relicense for mobile / embedded / licensees / etc. I'm guessing this one falls into the former category (adding a couple setters is not a big deal). >> Content should be pluggable on a given TextInputControl, or whether it > should require subclassing. > > Subclassing seems a bit inconvenient. To control the input on every text > field on a form, all the fields would need to be custom components. This > would mean that there would be very few TextFields in my app, I would have > just MyTextField everywhere. Also, how would I code it? If I was just > using setContent() I would do something like: > > firstField.setContent(new > RestrictedLengthContent(Person.FIRST_NAME_LENGTH)); > lastField.setContent(new RestrictedLengthContent(Person.LAST_NAME_LENGTH)); > > How would I do that in subclasses and still use SceneBuilder? Maybe there > would be a way in SceneBuilder to allow the use of a parameterized > constructor with a custom parameter, but that seems pretty complex. With subclassing, I might have done something like: public class BetterTextField extends TextField { private IntegerProperty maxLength = new SimpleIntegerProperty(this, "maxLength", -1); // getters / setters // any other properties your ideal text field would have -- maybe a regex for validation, etc private static final class BetterContent extends Content { private IntegerProperty maxLength; // other properties // implementation.... } public BetterTextField() { super(new BetterContent()); BetterContent content = (BetterContent) getContent(); content.maxLength = maxLength; // alias the property } } Then in FXML: Now in Scene Builder I'm not sure this is well handled at present, it was on the task list for 8, although those plans haven't been finalized. It does something, but it might just be an empty box on the form, I'm not sure (depends on whether they are figuring out the classpath). The theory was that some things (like maxLength) should just be added to TextField in the future, and we wanted to have some FormattedTextField (or whatnot) that would handle the other cases. These are all subclasses, so that's fine. If I were to do a SearchField, it would be a subclass. So for most cases it seemed a subclass would be done anyway. Also I think the TextField's Content does special things with regards to \n \t etc that are set on the field, so if you replace with a custom Content, you might want to wrap the original one to avoid problems. >> might fail in the control & in the skin > > I am pretty new to this, and I have not really addressed the Skin and > Behavior aspects of everything. Is there a good place to learn how this > all is intended to work together? It sounds like this is to break apart > the PLAF Look and the PLAF Feel. (Also, a FX skin is more about how things > are painted, and is not the definition that some products use where a > different skin completely rearranges the UI.) Jonathan and Paru did a talk on this at JavaOne, as did Gerrit. Go to http://oracle.com/javaone Click on JavaOne Technical Sessions link I haven't tried to watch them yet via that page, but in theory it should work. Richard From richard.bair at oracle.com Thu Oct 18 13:34:20 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 13:34:20 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: Hi Mark > There's probably two overlapping aims here: 1) to build JavaFX itself, and > 2) to build JavaFX projects (in your case, projects like Ensemble). > > As you pointed out, Maven can be rigid if you want to do something that it > doesn't normally do. It's goal is value convention over configuration. > But you can mix and match Maven and Gradle, or you can write your own Mojo > to provide any custom functionality (it's similar to writing an Ant Task). > The nice thing about Maven is that you can use the artifacts with Gradle, > Ivy and other build tools. And those tools include plugins that let them > interoperate with maven builds. > > As I mentioned in this issue: http://javafx-jira.kenai.com/browse/RT-25723 > You can generate project files for most IDEs. Is this issue related to building JavaFX with Maven or building Maven-based projects with JavaFX? I know both have been talked about on this list before. It looks like this is the latter (building javafx apps using Maven). In the latter case, JavaFX (because it is cobundled with the JRE) should be treated much like a Java version dependency -- ie: if you want to use JavaFX 2.2, them you update your build to use JavaSE 7u7 or whatnot. However it is true we have ant tasks for doing things like generating co-bundles, JNLP files, etc and those should have Maven counterparts, so that within your normal Maven build you can very easily add support for FX co-bundle creation. I'm not sure what that looks like in terms of code though. > Most external developers won't really want to build the native bits. In > the past I've created jars that include native DLLs, SOs, and added those > as dependencies. I did some research into how this is done in Maven but it was hard to follow. Does Maven, Ivy, and Gradle only support jar files in their repos? If it is wrapped in a jar, do I then have to unwrap before creating the final artifacts? > If you are using Hudson or some other CI tool, it should be able to handle > nightly builds and publish them to a Maven compliant repo (thus making them > usable by anyone using Maven, Gradle, or Ivy). The next time a developer > builds, it will fetch the latest build including the native bits (assuming > that they've configured their POMs to depend on the latest SNAPSHOT). > Hudson can also handle generating the coverage, and test reports for you. I don't see how putting JavaFX into Maven repos helps though, since it is co-bundled with the JRE and relies on certain versions in the JRE. In the past, JavaFX was a standalone, and so publishing to a Maven repo would make perfect sense. However now that we're cobundled with the JRE, it seems like it doesn't make sense to publish into a repo. One of the reasons we went for co-bundling was a step along the (hopefully) inevitable path to becoming part of the JavaSE spec (in which case we would have to be co-bundled). Also it allows us to take advantage of advances in JavaSE for performance, Swing integration, deployment fixes, etc. Cheers Richard From richard.bair at oracle.com Thu Oct 18 13:58:01 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 13:58:01 -0700 Subject: Annotation Processing in Gradle Message-ID: OK, I apologize up front -- this gradle script is not something you can reproduce in its entirety because some of the sources I'm building with have not been made public yet (see other email thread today on that subject). However I thought it would be good to detail what I'm up to and any Gradle master's could lend a hand if you have a moment :-) Here is my current directory structure: javafx/ build-tools/ src/ java/ META-INF/services/javafx.annotation.processing.Processor com/ javafx/ modules/ base/ src/ build/ com/sun/javafx/runtime/VersionInfo.java java/ com/ javafx/ Here is my settings.gradle file: include 'build-tools', 'base', 'graphics', 'controls', 'swing', 'swt', 'web', 'fxml' project(':base').projectDir = file('modules/base') project(':graphics').projectDir = file('modules/graphics') project(':controls').projectDir = file('modules/controls') project(':swing').projectDir = file('modules/swing') project(':swt').projectDir = file('modules/swt') project(':web').projectDir = file('modules/web') project(':fxml').projectDir = file('modules/fxml') And here is a portion of my build.gradle file: allprojects { apply plugin: 'java' repositories { mavenCentral() } } project(':build-tools') { sourceSets { main { java { srcDirs = ['src/java'] exclude "META-INF/services/*" } resources { srcDirs = ['src/java'] include "META-INF/services/*" } } } } project(':base') { sourceSets.main.java.srcDirs = ['src/java', 'src/build'] // TODO need to transform the VersionInfo in the src/build prior to compilation dependencies { compile project(':build-tools') } } Now, my current issue is this: in build-tools, I have my annotation processor (BuilderProcessor). It also has some annotations. We use the annotations in our sources, such that we can say "@NoBuilder" or define default values for properties in constructors, etc, so that the builder annotation processor can create the right Builder implementation. So the Annotations need to be available to build-tools, and the annotation processor is also in build-tools, and base (and other modules) must both depend on build-tools (for the annotations) as well as use the annotation processor in build-tools during build time. OK, so that goop in the project(':build-tools') block makes sure teh META-INF of the generated build-tools.jar is correct, so that hopefully the classpath is right for base, so that the annotation processor will be run. Fine. Unfortunately I'm getting a very unhelpful error message: Exception thrown while constructing Processor object: null I'm not sure where the error lies, will keep digging. If anybody has an idea, let me know. Thanks Richard From swpalmer at gmail.com Thu Oct 18 14:09:13 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 18 Oct 2012 17:09:13 -0400 Subject: TextField Document model In-Reply-To: <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> Message-ID: On 2012-10-18, at 3:28 PM, Richard Bair wrote: > I don't have any philosophical reason for not having content be mutable. My only concern here is that having it mutable introduces some additional complexity in the class / skin -- or at least it might. > > BTW, if you find that changing it dynamically works perfect, I'd be happy to do the code review (including Jonathan). Adding a new constructor to set it once would likely work for most cases. I suspect making it dynamic is a lot more work. Scott From richard.bair at oracle.com Thu Oct 18 14:11:45 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 14:11:45 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: <80B3D614-DACD-412A-B89D-BEE09082D958@oracle.com> OK, so we have the following issues: - JavaFX is cobundled with the JRE, but is not on the classpath, and thus basically doesn't exist for developers (that is, they have to manually setup javafx on their classpath since the JRE doesn't have it) - Native app bundles require the target OS to be available in order to create the bundle (obvious pain ensues) - Having to reinstall the JRE to test the latest build of FX stinks (even if it is ultimately deployed with the JRE, being able to link-to / run JavaFX separately makes development easier) Is that right? I'll probably circle back with you on the native / jar issue in a bit, my head is in another space at the moment (trying to get annotation processor working). These are all definitely issues. Would you be able to check and see what the corresponding issues are in JIRA, or file new issues an let me know? I'm going to wrangle the right people. Richard On Oct 18, 2012, at 2:02 PM, Mark Fortner wrote: > Hi Richard, > The issue below is about making JavaFX projects build with Maven. In particular it makes the process of creating a JavaFX project a snap to do by generating the appropriate directory structure, and configuring the POM file to generate the artifacts that people want (like JNLP files, JARs, RPMs, etc). You could test the archetype using your Ensemble project. > > Cobundling of JavaFX solves certain problems, but since the source isn't released yet, and since the default build classpath doesn't include JavaFX you still have to do add JavaFX as a dependency. > > > > > > As I mentioned in this issue: http://javafx-jira.kenai.com/browse/RT-25723 > > You can generate project files for most IDEs. > > Is this issue related to building JavaFX with Maven or building Maven-based projects with JavaFX? I know both have been talked about on this list before. It looks like this is the latter (building javafx apps using Maven). In the latter case, JavaFX (because it is cobundled with the JRE) should be treated much like a Java version dependency -- ie: if you want to use JavaFX 2.2, them you update your build to use JavaSE 7u7 or whatnot. > > However it is true we have ant tasks for doing things like generating co-bundles, JNLP files, etc and those should have Maven counterparts, so that within your normal Maven build you can very easily add support for FX co-bundle creation. I'm not sure what that looks like in terms of code though. > > > Most external developers won't really want to build the native bits. In > > the past I've created jars that include native DLLs, SOs, and added those > > as dependencies. > > I did some research into how this is done in Maven but it was hard to follow. Does Maven, Ivy, and Gradle only support jar files in their repos? If it is wrapped in a jar, do I then have to unwrap before creating the final artifacts? > > > Maven repos can include a variety of different artifacts; however, since the non-native code is expecting the native code in the same directory, it's easier to simply bundle a copy of the class jar with the native artifacts. For example, in my case, I put the dylib files into a jar called jfxrt-mac-2.2.0.jar. I then installed the jar into my local maven repository. > > > > > If you are using Hudson or some other CI tool, it should be able to handle > > nightly builds and publish them to a Maven compliant repo (thus making them > > usable by anyone using Maven, Gradle, or Ivy). The next time a developer > > builds, it will fetch the latest build including the native bits (assuming > > that they've configured their POMs to depend on the latest SNAPSHOT). > > Hudson can also handle generating the coverage, and test reports for you. > > I don't see how putting JavaFX into Maven repos helps though, since it is co-bundled with the JRE and relies on certain versions in the JRE. In the past, JavaFX was a standalone, and so publishing to a Maven repo would make perfect sense. However now that we're cobundled with the JRE, it seems like it doesn't make sense to publish into a repo. One of the reasons we went for co-bundling was a step along the (hopefully) inevitable path to becoming part of the JavaSE spec (in which case we would have to be co-bundled). Also it allows us to take advantage of advances in JavaSE for performance, Swing integration, deployment fixes, etc. > > > Assuming that you don't need the native bits to create platform-specific builds of your app, then we should be OK. I looked into your Native Packaging tools earlier in the year, it seemed that you needed to be on the platform you were building for. Which was a non-starter for me since I build on a Mac and deploy to both Windows and Mac. > > The only problem that not deploying the latest build would have, would be in cases where you've submitted a bug, somebody posts a fix for it, and you want to verify the fix. If you use the nightly build, then you should be able to verify that the fix addresses the problem by running your code with the nightly snapshot libraries without having to build JavaFX from source. Often times waiting until an official release occurs, will cause you to miss your own deadline. > > Cheers, > > Mark From richard.bair at oracle.com Thu Oct 18 14:13:14 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 14:13:14 -0700 Subject: Annotation Processing in Gradle In-Reply-To: References: Message-ID: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> > Exception thrown while constructing Processor object: null To be more clear, the error occurs when trying to compile "base", apparently because the processor cannot be found? Not sure. :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :build-tools:compileJava UP-TO-DATE :build-tools:processResources UP-TO-DATE :build-tools:classes UP-TO-DATE :build-tools:jar UP-TO-DATE :base:compileJava error: Exception thrown while constructing Processor object: null :base:compileJava FAILED From richard.bair at oracle.com Thu Oct 18 14:27:53 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 14:27:53 -0700 Subject: Annotation Processing in Gradle In-Reply-To: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> References: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> Message-ID: <42B647F5-C556-4B29-8E15-83AA2E72DA37@oracle.com> I know this is hopeless noise, sorry about that. But its too late now! Building by hand: Richards-MacBook-Pro-3:base richardbair$ javac -d /Users/richardbair/Projects/Work/jfx/graphics-8.0-refactor/javafx/modules/base/build/classes/main -g -classpath /Users/richardbair/Projects/Work/jfx/graphics-8.0-refactor/javafx/build-tools/build/libs/build-tools.jar /Users/richardbair/Projects/Work/jfx/graphics-8.0-refactor/javafx/modules/base/src/java/com/oracle/javafx/jmx/SGMXBean.java /Users/richardbair/Projects/Work/jfx/graphics-8.0-refactor/javafx/modules/base/src/java/com/sun/javafx/PlatformUtil.java error: Exception thrown while constructing Processor object: null And everything in that Jar which is on the classpath: Richards-MacBook-Pro-3:base richardbair$ jar -tvf /Users/richardbair/Projects/Work/jfx/graphics-8.0-refactor/javafx/build-tools/build/libs/build-tools.jar 0 Thu Oct 18 13:48:36 PDT 2012 META-INF/ 25 Thu Oct 18 13:48:36 PDT 2012 META-INF/MANIFEST.MF 0 Thu Oct 18 13:19:44 PDT 2012 com/ 0 Thu Oct 18 13:19:44 PDT 2012 com/sun/ 0 Thu Oct 18 13:19:44 PDT 2012 com/sun/javafx/ 0 Thu Oct 18 13:19:44 PDT 2012 com/sun/javafx/beans/ 0 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/ 433 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/Default.class 400 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/Delegate.class 484 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/DuplicateInBuilderProperties.class 401 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/NoBuilder.class 410 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/NoInit.class 490 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/beans/annotations/NonNull.class 0 Thu Oct 18 13:19:44 PDT 2012 com/sun/javafx/collections/ 0 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/collections/annotations/ 449 Thu Oct 18 13:48:34 PDT 2012 com/sun/javafx/collections/annotations/ReturnsUnmodifiableCollection.class 0 Thu Oct 18 13:19:44 PDT 2012 javafx/ 0 Thu Oct 18 13:19:44 PDT 2012 javafx/builder/ 0 Thu Oct 18 13:48:36 PDT 2012 javafx/builder/processor/ 2416 Thu Oct 18 13:48:36 PDT 2012 javafx/builder/processor/BuilderProcessor$1SetterCall.class 3552 Thu Oct 18 13:48:36 PDT 2012 javafx/builder/processor/BuilderProcessor$Scanned.class 33393 Thu Oct 18 13:48:36 PDT 2012 javafx/builder/processor/BuilderProcessor.class 0 Thu Oct 18 13:19:44 PDT 2012 META-INF/services/ 42 Thu Oct 18 13:19:44 PDT 2012 META-INF/services/javax.annotation.processing.Processor and "META-INF/services/javax.annotation.processing.Processor has: javafx.builder.processor.BuilderProcessor as its content. Its a mystery to me. Wondering why META-INF is split on the top & bottom of that output, though. From John_Smith at symantec.com Thu Oct 18 14:37:56 2012 From: John_Smith at symantec.com (John Smith) Date: Thu, 18 Oct 2012 14:37:56 -0700 Subject: Open Sourcing Status Report In-Reply-To: <65D94E2E-335A-478F-BA27-B22308CD6BE0@oracle.com> References: <65D94E2E-335A-478F-BA27-B22308CD6BE0@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF3C2@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Thanks for the hard work on open sourcing JavaFX. I noticed some of the fxml work was open sourced recently, so that's progress. Looking at the repository, this is a list of modules currently open sourced: javafx-beans-dt javafx-concurrent javafx-designtime javafx-fxml javafx-ueber-jar javafx-ui-charts javafx-ui-common javafx-ui-controls javafx-util-converter test-stub-toolkit I also think WebKit source modifications are open source somewhere. It would be nice to have an equivalent list of modules which will be open sourced. For example, it is unclear to me whether or not things like the browser plugin, the packaging infrastructure (javafx ant tasks and javafxpackager source) and the packager embedded launcher and fallback code will be open source. Also, will all of the code for the native libraries supporting prism, glass, media, opengl and direct3d bindings be open source by February? In terms of project infrastructure, any chance that github could be used as the primary infrastructure or as a mirror of the existing infrastructure (similar to how redhat manage Ceylon https://github.com/ceylon/)? Access via github might help the project feel a little more accessible and a bit more like a community project than an Oracle project. Just asking, I understand if the answer to that question is no. - John -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Thursday, October 18, 2012 11:42 AM To: openjfx-dev at openjdk.java.net Mailing Subject: Open Sourcing Status Report I wanted to give a status report on where we're at in the process of open sourcing JavaFX. Obviously we started this process earlier this year or late last year (UI Controls went out either last December or this January, I don't remember exactly), but it stalled awaiting internal approvals, but now that those have been cleared, we're moving forward as quickly as we can. For each chunk of code that we open source, we need to perform the following work: - Update the build system to build the open source bits - Review for Security - Sanity check headers - Review rights (some parts like T2K are licensed and cannot be open sourced) The long pole in this process is the "review for security". In some parts of the code, as we audit we may find a potential security hole. Much of the code we will be able to simply fix and then release (or may have no issues anyway in which case it can just be released after audit), but there will likely be some parts that need to wait until the next security release in February 2013 before we can even apply the patches to the workspace, let alone open source the code. I'm hoping this latter category will be small and that most if not all of our code will be clean and we can push before next February. But just a heads-up that it may take until February for the process to complete. In addition, I'm engaged in a proposal for revamping the project structure and build infrastructure. My main goals are: 1) Make it trivial to develop JavaFX using an IDE 2) Allow for partial builds, cross builds (especially speaking of native compilation. Compiling WebKit can take an hour on my system) 3) Download dependencies dynamically 4) Reduce the number of lines in our build script(s) 5) Simplify the project structure Over the last 4 years things have grown to be quite difficult and cumbersome, and on embedded David Hill said he is spending upwards of 40% of his time wrestling with the build system. Further, only a few of us use IDE's to their maximum potential, and only after wrestling quite hard with the system and coming up with our own "magic sauce" for how to build JavaFX. Clearly this isn't scalable or desirable. To declare success, the process needs to be as simple as: 1) Download the Sources 2) Use your favorite IDE to open the project 3) Hit run If I have to concede defeat, then there might be a 2b) 2b) execute a build step to download dependencies I'll send a separate email in a moment discussing what I want to do around project structure (ie: source file layout etc) and the build. Most of our time at present is spent on Security audits, and as soon as we get those done for some chunk of code, we'll move it into the open. Richard From richard.bair at oracle.com Thu Oct 18 14:38:24 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 14:38:24 -0700 Subject: Annotation Processing in Gradle In-Reply-To: <42B647F5-C556-4B29-8E15-83AA2E72DA37@oracle.com> References: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> <42B647F5-C556-4B29-8E15-83AA2E72DA37@oracle.com> Message-ID: Found it. For some reason, BuilderProcessor.properties is not being copied over. So the Gradle says: project(':build-tools') { sourceSets { main { java { srcDirs = ['src/java'] exclude "META-INF/services/*" } resources { srcDirs = ['src/java'] include "META-INF/services/*" } } } } So I guess .properties files are not copied as part of the "java" dir normally. I wonder what else isn't copied normally (we've got a bunch of non .java files that are in the java dir. We don't use a separate resources dir). Richard From hang.vo at oracle.com Thu Oct 18 14:39:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 18 Oct 2012 21:39:01 +0000 Subject: hg: openjfx/8/master/rt: 18 new changesets Message-ID: <20121018213920.39FE047429@hg.openjdk.java.net> Changeset: 91c30a8859db Author: rbair Date: 2012-09-20 22:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/91c30a8859db Improved handling of thumb size, from previous patch 81cc13fe6f96 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 408ee6a41174 Author: David Hill Date: 2012-10-09 17:44 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/408ee6a41174 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: 19bdbf3b30ee Author: David Hill Date: 2012-10-12 11:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/19bdbf3b30ee Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: 7831b4f4de86 Author: Martin Sladecek Date: 2012-10-16 14:37 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7831b4f4de86 RT-25147 [FindBugs] GradientUtils$Point - A mutable static field could be changed by malicious code or by accident from another package. ! javafx-ui-common/src/com/sun/javafx/scene/paint/GradientUtils.java Changeset: bae4dedcad85 Author: Martin Sladecek Date: 2012-10-16 14:39 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bae4dedcad85 merge Changeset: 4dd0ce0f750e Author: Lubomir Nerad Date: 2012-10-16 14:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4dd0ce0f750e Fix for RT-25148: [FindBugs] Toolkit.java - A mutable static field could be changed by malicious code or by accident from another package. ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java Changeset: a49900764c1d Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-16 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a49900764c1d Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt Changeset: 988f6f79107b Author: rbair Date: 2012-10-10 11:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/988f6f79107b Fix for RT-25049: SplitMenuButton have gap. As near as I can tell, they have a gap going back a long way. In fact, the gap is still there with Region caching disabled (in fact with region caching turned on, you don't get this gap at all, so I think this error came from some time in the past). The MenuButtonSkinBase layout was incorrect, along with the CSS. ! javafx-ui-common/src/javafx/scene/layout/CornerRadii.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 32ed56155a53 Author: rbair Date: 2012-10-11 10:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/32ed56155a53 Updated documentation to indicate contents draw over borders on regions. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: 8d346510b927 Author: leifs Date: 2012-10-11 12:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8d346510b927 Additional fix for RT-25049 to avoid label truncation. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java Changeset: 41cfd7b80910 Author: David Grieve Date: 2012-10-11 15:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/41cfd7b80910 RT-25016: calculated value not stored in cache when styles are recalculted. remove fastpath check and always cache calculated value. ensure inline styles are cached locally ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: ef37b66b00b0 Author: David Grieve Date: 2012-10-11 15:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ef37b66b00b0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 09253f3afb0b Author: leifs Date: 2012-10-11 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/09253f3afb0b Make VK_TYPE_NAMES array package private. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java Changeset: 393c90eb52e0 Author: David Grieve Date: 2012-10-12 14:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/393c90eb52e0 RT-25225: default background color should be transparent per w3c spec ! javafx-ui-common/src/javafx/scene/layout/Background.java Changeset: 9352015d712d Author: David Grieve Date: 2012-10-12 14:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9352015d712d RT-24784: ensure parent style manager is properly initialized ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: c731a926c171 Author: mickf Date: 2012-10-16 14:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c731a926c171 RT-20786 : Focus couldn't be received or traversed. ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 97d1312344e8 Author: leifs Date: 2012-10-16 13:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/97d1312344e8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt Changeset: dafaa830d4d0 Author: hudson Date: 2012-10-18 14:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dafaa830d4d0 Added tag 8.0-b61 for changeset 97d1312344e8 ! .hgtags From richard.bair at oracle.com Thu Oct 18 14:50:38 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 14:50:38 -0700 Subject: Open Sourcing Status Report In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF3C2@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <65D94E2E-335A-478F-BA27-B22308CD6BE0@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF3C2@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <3C4F4F6F-2BDD-486C-A806-DB9B0C1E05CC@oracle.com> Hi John, On Oct 18, 2012, at 2:37 PM, John Smith wrote: > Thanks for the hard work on open sourcing JavaFX. > I noticed some of the fxml work was open sourced recently, so that's progress. > > Looking at the repository, this is a list of modules currently open sourced: > javafx-beans-dt > javafx-concurrent > javafx-designtime > javafx-fxml > javafx-ueber-jar > javafx-ui-charts > javafx-ui-common > javafx-ui-controls > javafx-util-converter > test-stub-toolkit > I also think WebKit source modifications are open source somewhere. > > It would be nice to have an equivalent list of modules which will be open sourced. > > For example, it is unclear to me whether or not things like the browser plugin, the packaging infrastructure (javafx ant tasks and javafxpackager source) and the packager embedded launcher and fallback code will be open source. Also, will all of the code for the native libraries supporting prism, glass, media, opengl and direct3d bindings be open source by February? Right, deployment is an open question because I don't know what all the bits are in the javafx-deploy workspace right now. Certainly the JavaSE plugin / deployment code is not open source yet, and so I would imagine any FX bits derived from it will likewise not be open. But hopefully we can get a replacement in the open, much like IcedTea has for applets. All the native libs for prism, glass, media, opengl, direct3d, etc should all be open sourced by February. Its a tall order (since native code is harder to finish security audits for), but that is definitely the goal. And definitely all of these will be open sourced. The list of modules presently would include: javafx-annotation-processor javafx-util-converter javafx-anim javafx-beans javafx-common javafx-logging javafx-mx-common javafx-ui-common javafx-concurrent decora-compiler decora-d3d decora-es2 decora-jsw decora-prism decora-prism-ps decora-prism-sw decora-runtime decora-sse glass javafx-font javafx-geom javafx-iio javafx-sg-common javafx-sg-prism javafx-ui-quantum pisces prism-common prism-d3d prism-es2 prism-es2-eglfb prism-es2-eglx11 prism-es2-mac prism-es2-win prism-es2-x11 prism-j2d prism-null prism-ps prism-sw prism-util javafx-ui-desktop decora-compiler javafx-beans-dt javafx-designtime decora-d3d-native decora-sse-native javafx-font-native javafx-iio-native prism-common-native prism-d3d-native prism-es2-native prism-sw-native javafx-ui-charts javafx-ui-controls javafx-ui-webnode webnode-prism javafx-embed-swing javafx-embed-swt javafx-fxml This doesn't include benchmarks or apps, just the core runtime libraries. Apps and benchmarks will also be added, and hopefully a pile of SQE tests. > In terms of project infrastructure, any chance that github could be used as the primary infrastructure or as a mirror of the existing infrastructure (similar to how redhat manage Ceylon https://github.com/ceylon/)? Access via github might help the project feel a little more accessible and a bit more like a community project than an Oracle project. Just asking, I understand if the answer to that question is no. I don't know how that would work? Certainly we want to host things on the openjfx / openjdk, especially as we get more integrated in their processes (gulp). However Danno has a bitbucket mirror up, would this be essentially the same thing? Its an open source project so mirroring the open bits is certainly not a problem, but the main repos will remain here on openjdk. Cheers Richard From John_Smith at symantec.com Thu Oct 18 15:26:41 2012 From: John_Smith at symantec.com (John Smith) Date: Thu, 18 Oct 2012 15:26:41 -0700 Subject: Open Sourcing Status Report In-Reply-To: <3C4F4F6F-2BDD-486C-A806-DB9B0C1E05CC@oracle.com> References: <65D94E2E-335A-478F-BA27-B22308CD6BE0@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF3C2@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <3C4F4F6F-2BDD-486C-A806-DB9B0C1E05CC@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF45A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Thanks Richard, the potential list of open-sourced modules is helpful in understanding the scope of the open source effort. Re: the github stuff, I guess as you say, if somebody decided to do that then it would be similar to Danno's bitbucket mirror of the openjdk hosts masters. In terms of build support, you might want to make it easy to hook into the openjdk build and distribution system that Henri Gomez has put together here: http://obuildfactory.hgomez.net/ http://code.google.com/p/openjdk-osx-build/ There are still some jira issues which give permission violations when you try to look at them. Is it possible to limit the jira issues which have restricted permissions to those which are unresolved security issues and to allow anybody to view jira cases without signing up for a jira account and logging in? Regards, John -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Thursday, October 18, 2012 2:51 PM To: John Smith Cc: openjfx-dev at openjdk.java.net Mailing Subject: Re: Open Sourcing Status Report Hi John, On Oct 18, 2012, at 2:37 PM, John Smith wrote: > Thanks for the hard work on open sourcing JavaFX. > I noticed some of the fxml work was open sourced recently, so that's progress. > > Looking at the repository, this is a list of modules currently open sourced: > javafx-beans-dt > javafx-concurrent > javafx-designtime > javafx-fxml > javafx-ueber-jar > javafx-ui-charts > javafx-ui-common > javafx-ui-controls > javafx-util-converter > test-stub-toolkit > I also think WebKit source modifications are open source somewhere. > > It would be nice to have an equivalent list of modules which will be open sourced. > > For example, it is unclear to me whether or not things like the browser plugin, the packaging infrastructure (javafx ant tasks and javafxpackager source) and the packager embedded launcher and fallback code will be open source. Also, will all of the code for the native libraries supporting prism, glass, media, opengl and direct3d bindings be open source by February? Right, deployment is an open question because I don't know what all the bits are in the javafx-deploy workspace right now. Certainly the JavaSE plugin / deployment code is not open source yet, and so I would imagine any FX bits derived from it will likewise not be open. But hopefully we can get a replacement in the open, much like IcedTea has for applets. All the native libs for prism, glass, media, opengl, direct3d, etc should all be open sourced by February. Its a tall order (since native code is harder to finish security audits for), but that is definitely the goal. And definitely all of these will be open sourced. The list of modules presently would include: javafx-annotation-processor javafx-util-converter javafx-anim javafx-beans javafx-common javafx-logging javafx-mx-common javafx-ui-common javafx-concurrent decora-compiler decora-d3d decora-es2 decora-jsw decora-prism decora-prism-ps decora-prism-sw decora-runtime decora-sse glass javafx-font javafx-geom javafx-iio javafx-sg-common javafx-sg-prism javafx-ui-quantum pisces prism-common prism-d3d prism-es2 prism-es2-eglfb prism-es2-eglx11 prism-es2-mac prism-es2-win prism-es2-x11 prism-j2d prism-null prism-ps prism-sw prism-util javafx-ui-desktop decora-compiler javafx-beans-dt javafx-designtime decora-d3d-native decora-sse-native javafx-font-native javafx-iio-native prism-common-native prism-d3d-native prism-es2-native prism-sw-native javafx-ui-charts javafx-ui-controls javafx-ui-webnode webnode-prism javafx-embed-swing javafx-embed-swt javafx-fxml This doesn't include benchmarks or apps, just the core runtime libraries. Apps and benchmarks will also be added, and hopefully a pile of SQE tests. > In terms of project infrastructure, any chance that github could be used as the primary infrastructure or as a mirror of the existing infrastructure (similar to how redhat manage Ceylon https://github.com/ceylon/)? Access via github might help the project feel a little more accessible and a bit more like a community project than an Oracle project. Just asking, I understand if the answer to that question is no. I don't know how that would work? Certainly we want to host things on the openjfx / openjdk, especially as we get more integrated in their processes (gulp). However Danno has a bitbucket mirror up, would this be essentially the same thing? Its an open source project so mirroring the open bits is certainly not a problem, but the main repos will remain here on openjdk. Cheers Richard From richard.bair at oracle.com Thu Oct 18 15:37:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 15:37:22 -0700 Subject: Open Sourcing Status Report In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF45A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <65D94E2E-335A-478F-BA27-B22308CD6BE0@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF3C2@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <3C4F4F6F-2BDD-486C-A806-DB9B0C1E05CC@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D221601FEF45A@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: > In terms of build support, you might want to make it easy to hook into the openjdk build and distribution system that Henri Gomez has put together here: > http://obuildfactory.hgomez.net/ > http://code.google.com/p/openjdk-osx-build/ I'll send him a note, JavaFX should be co-bundled with JRE builds, but I could imagine OpenJDK builds don't co-bundle, but it would be awesome if they did. > There are still some jira issues which give permission violations when you try to look at them. Is it possible to limit the jira issues which have restricted permissions to those which are unresolved security issues and to allow anybody to view jira cases without signing up for a jira account and logging in? I'm not sure why we don't already allow un-authenticated users from browsing JIRA. It seems odd because we should want Google indexing the thing and so forth. I've put in a question to Brian and Kevin to find out what the story on that is. I'm not comfortable with un-authenticated editing of a JIRA issue (darn spam bots), but certainly browsing should be allowed it seems. Thanks Richard From swpalmer at gmail.com Thu Oct 18 15:56:13 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 18 Oct 2012 18:56:13 -0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <80B3D614-DACD-412A-B89D-BEE09082D958@oracle.com> References: <80B3D614-DACD-412A-B89D-BEE09082D958@oracle.com> Message-ID: On Thu, Oct 18, 2012 at 5:11 PM, Richard Bair wrote: > OK, so we have the following issues: > > - JavaFX is cobundled with the JRE, but is not on the classpath, > and thus basically doesn't exist for developers > (that is, they have to manually setup javafx on their > classpath since the JRE doesn't have it) > - Native app bundles require the target OS to be available in > order to create the bundle (obvious pain ensues) > - Having to reinstall the JRE to test the latest build of FX > stinks (even if it is ultimately deployed with the JRE, > being able to link-to / run JavaFX separately makes > development easier) > > Is that right? I don't think you are going to avoid the target OS requirement to produce those native bundles. (I.e. you aren't going to run WiX or Innosetup without running it on Windows.) As a developer, you shouldn't be providing an app specific bundle that you haven't tested anyway, so access to said OS is implied. Run VirtualBox if you must, to get access to alternate OS environments for building and testing. Or have a build-buddy that runs the OS if you can't afford the OS license. The last step isn't a big deal for me. If JavaFX is just part of the JRE I'm not sure as a developer that I need anything more than early-access builds (of the JRE) in order to avoid surprises. Once JavaFX is on the classpath most issues are solved as far as I'm concerned. We might be able to deal with some issues now with an ugly scope Maven dependency and a check for a minimum JDK version. I'm already using JavaFX in a local Maven repo with some hackery to augment the classpath and force the JFX runtime to load from somewhere other than the Maven cache. One option is java -Xbootclasspath/a: which works for running in the IDE where it loads classes from build folders instead of jars. At runtime our Swing app does ugly classpath hacking to put the JRE's JavaFX runtime on the class path.. much like what the jfxpackager stubs must do. It will be great to get rid of that nasty hacking, but it works well for now. Scott From markclaassenx at gmail.com Thu Oct 18 15:57:10 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Thu, 18 Oct 2012 18:57:10 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> Message-ID: > Adding a new constructor to set it once would likely work for most cases. > I suspect making it dynamic is a lot more work. Maybe it is a bit more for the API designer, but, the way I understand it, this would preclude the use of the SceneBuilder to create the components, without a lot of subclassing. (See the rest of this thread.) If this is not the case, I would be very interested to know how to accomplish this. On Thu, Oct 18, 2012 at 5:09 PM, Scott Palmer wrote: > On 2012-10-18, at 3:28 PM, Richard Bair wrote: > > > I don't have any philosophical reason for not having content be mutable. > My only concern here is that having it mutable introduces some additional > complexity in the class / skin -- or at least it might. > > > > BTW, if you find that changing it dynamically works perfect, I'd be > happy to do the code review (including Jonathan). > > Adding a new constructor to set it once would likely work for most cases. > I suspect making it dynamic is a lot more work. > > Scott From danno.ferrin at shemnon.com Thu Oct 18 16:00:55 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 18 Oct 2012 17:00:55 -0600 Subject: Annotation Processing in Gradle In-Reply-To: References: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> <42B647F5-C556-4B29-8E15-83AA2E72DA37@oracle.com> Message-ID: I would much prefer that it went to the maven/gradle src/main/java style, with resources and java sources. There is less text in the build file and what is left is really what is relevant to the peculiarities of the build. On Thu, Oct 18, 2012 at 3:38 PM, Richard Bair wrote: > Found it. For some reason, BuilderProcessor.properties is not being copied > over. So the Gradle says: > > project(':build-tools') { > sourceSets { > main { > java { > srcDirs = ['src/java'] > exclude "META-INF/services/*" > } > resources { > srcDirs = ['src/java'] > include "META-INF/services/*" > } > } > } > } > > So I guess .properties files are not copied as part of the "java" dir > normally. I wonder what else isn't copied normally (we've got a bunch of > non .java files that are in the java dir. We don't use a separate resources > dir). > > Richard -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From swpalmer at gmail.com Thu Oct 18 16:22:40 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 18 Oct 2012 19:22:40 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> Message-ID: I think you are correct. I don' t know enough about the builders used during FXML loading. Some classes have an initBlah(x) instead of a setBlah(x) when the value can't be changed. I doubt that can be made to work for something like this without breaking TextField. For now, subclassing instead of setContent is probably the path of least resistance. But I'm in agreement that something better is preferred. It's just that there are a lot of bigger problems with JavaFX... so I'm not sure where re-working TextFieldSkin interactions sits. I would like to be able to augment or replace the context menu on a TextField for example, or be able to get the on-screen position of the caret so I can popup assistance windows at the right place (I've got that working reasonably by subclassing TextFieldSkin so I can get at the font metrics). There are rough edges but I'm really loving the direction that JavaFX is taking and how responsive the JavaFX team is. I've submitted bug reports on a Saturday morning and observed activity on the issue in Jira within fifteen minutes. Scott On Thu, Oct 18, 2012 at 6:57 PM, Mark Claassen wrote: > > Adding a new constructor to set it once would likely work for most cases. > > I suspect making it dynamic is a lot more work. > Maybe it is a bit more for the API designer, but, the way I understand it, > this would preclude the use of the SceneBuilder to create the components, > without a lot of subclassing. (See the rest of this thread.) > If this is not the case, I would be very interested to know how to > accomplish this. > > On Thu, Oct 18, 2012 at 5:09 PM, Scott Palmer wrote: > > > On 2012-10-18, at 3:28 PM, Richard Bair wrote: > > > > > I don't have any philosophical reason for not having content be > mutable. > > My only concern here is that having it mutable introduces some additional > > complexity in the class / skin -- or at least it might. > > > > > > BTW, if you find that changing it dynamically works perfect, I'd be > > happy to do the code review (including Jonathan). > > > > Adding a new constructor to set it once would likely work for most cases. > > I suspect making it dynamic is a lot more work. > > > > Scott > From richard.bair at oracle.com Thu Oct 18 16:23:18 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 16:23:18 -0700 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> Message-ID: <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> >> Adding a new constructor to set it once would likely work for most cases. >> I suspect making it dynamic is a lot more work. > Maybe it is a bit more for the API designer, but, the way I understand it, > this would preclude the use of the SceneBuilder to create the components, > without a lot of subclassing. (See the rest of this thread.) > If this is not the case, I would be very interested to know how to > accomplish this. Actually, as long as there is a Builder for the class, you should be able to build it from FXML even if there is no default constructor. From richard.bair at oracle.com Thu Oct 18 16:26:21 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 16:26:21 -0700 Subject: Annotation Processing in Gradle In-Reply-To: References: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> <42B647F5-C556-4B29-8E15-83AA2E72DA37@oracle.com> Message-ID: <3FF6B402-D9A0-4DC0-868E-006668A7547D@oracle.com> I don't know, for example, I have .java files, .css files, .png and other files, .properties files (that are not build related), and then this property file which actually is build related. It seems like storing the .css files / .png files etc along with the source files in one tree is cleaner (that is, from the IDE I only have one tree expanded instead of two). I'm wondering if it is just a preferences thing or is there a compelling argument one way or the other? On Oct 18, 2012, at 4:00 PM, Danno Ferrin wrote: > I would much prefer that it went to the maven/gradle src/main/java style, with resources and java sources. There is less text in the build file and what is left is really what is relevant to the peculiarities of the build. > > On Thu, Oct 18, 2012 at 3:38 PM, Richard Bair wrote: > Found it. For some reason, BuilderProcessor.properties is not being copied over. So the Gradle says: > > project(':build-tools') { > sourceSets { > main { > java { > srcDirs = ['src/java'] > exclude "META-INF/services/*" > } > resources { > srcDirs = ['src/java'] > include "META-INF/services/*" > } > } > } > } > > So I guess .properties files are not copied as part of the "java" dir normally. I wonder what else isn't copied normally (we've got a bunch of non .java files that are in the java dir. We don't use a separate resources dir). > > Richard > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > From richard.bair at oracle.com Thu Oct 18 16:30:35 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 16:30:35 -0700 Subject: SWT build dependency Message-ID: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> So may latest headache is downloading the SWT dependency for our build. We use SWT for the SWT embedding support. So this is what I tried from looking at various blogs, because the version of SWT I'm looking for isn't in a Repo: project(':swt') { sourceSets.main.java.srcDirs = ['src/java'] dependencies { compile project(':build-tools'), project(':base'), project(':graphics') compile module('org.eclipse.swt:org.eclipse.swt:3.7.1 at jar') { //name = 'org.eclipse.swt' extension = 'jar' url = 'http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.1-201109091335/swt-3.7.1-cocoa-macosx-x86_64.zip' } } } so I'm trying to download directly from a URL. No dice. Still browsing the web looking for some solution From phidias51 at gmail.com Thu Oct 18 16:55:32 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 18 Oct 2012 16:55:32 -0700 Subject: Annotation Processing in Gradle In-Reply-To: <3FF6B402-D9A0-4DC0-868E-006668A7547D@oracle.com> References: <3903150F-F562-4AFF-B8EB-7A79F58DDDB2@oracle.com> <42B647F5-C556-4B29-8E15-83AA2E72DA37@oracle.com> <3FF6B402-D9A0-4DC0-868E-006668A7547D@oracle.com> Message-ID: I'd have to agree with Danno on this one. The problem is the clutter factor. When you have a large number of classes and resources stored together it gets harder to find what you're looking for when you're scanning through the project tree. It's easier if the resources are separated. It's also difficult to build with maven if you don't follow the standards. :-) Cheers, Mark On Thu, Oct 18, 2012 at 4:26 PM, Richard Bair wrote: > I don't know, for example, I have .java files, .css files, .png and other > files, .properties files (that are not build related), and then this > property file which actually is build related. It seems like storing the > .css files / .png files etc along with the source files in one tree is > cleaner (that is, from the IDE I only have one tree expanded instead of > two). I'm wondering if it is just a preferences thing or is there a > compelling argument one way or the other? > > On Oct 18, 2012, at 4:00 PM, Danno Ferrin wrote: > > > I would much prefer that it went to the maven/gradle src/main/java > style, with resources and java sources. There is less text in the build > file and what is left is really what is relevant to the peculiarities of > the build. > > > > On Thu, Oct 18, 2012 at 3:38 PM, Richard Bair > wrote: > > Found it. For some reason, BuilderProcessor.properties is not being > copied over. So the Gradle says: > > > > project(':build-tools') { > > sourceSets { > > main { > > java { > > srcDirs = ['src/java'] > > exclude "META-INF/services/*" > > } > > resources { > > srcDirs = ['src/java'] > > include "META-INF/services/*" > > } > > } > > } > > } > > > > So I guess .properties files are not copied as part of the "java" dir > normally. I wonder what else isn't copied normally (we've got a bunch of > non .java files that are in the java dir. We don't use a separate resources > dir). > > > > Richard > > > > > > > > -- > > There is nothing that will hold me back. I know who I am.... > > I remember wher I came from, and I feel stronger for knowing. > > Zane, Ninja of Ice. Ninjago S01E07 > > > > From tom.schindl at bestsolution.at Thu Oct 18 16:57:32 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 19 Oct 2012 01:57:32 +0200 Subject: SWT build dependency In-Reply-To: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> Message-ID: <5080976C.3050908@bestsolution.at> That can't work there you get a zip which inlcude swt.jar. You need to have the plain jar. Which you can get from: http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/ The mac one is named org.eclipse.swt.cocoa.macosx_3.7.2.v3740f.jar because you only need to compile against it doesn't really matter which platform you compile against. Tom Am 19.10.12 01:30, schrieb Richard Bair: > So may latest headache is downloading the SWT dependency for our build. We use SWT for the SWT embedding support. So this is what I tried from looking at various blogs, because the version of SWT I'm looking for isn't in a Repo: > > project(':swt') { > sourceSets.main.java.srcDirs = ['src/java'] > dependencies { > compile project(':build-tools'), project(':base'), project(':graphics') > compile module('org.eclipse.swt:org.eclipse.swt:3.7.1 at jar') { > //name = 'org.eclipse.swt' > extension = 'jar' > url = 'http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.1-201109091335/swt-3.7.1-cocoa-macosx-x86_64.zip' > } > } > } > > > so I'm trying to download directly from a URL. No dice. Still browsing the web looking for some solution > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From phidias51 at gmail.com Thu Oct 18 17:22:15 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 18 Oct 2012 17:22:15 -0700 Subject: Lombard? Presidio? Message-ID: Could somebody add a note in the description of the Lombard & Presidio releases in JIRA that explains how these code names map to the current JavaFX version numbers? I think there was some discussion earlier about this. If the description's in JIRA at least it will be easier to set expectations. Cheers, Mark From Richard.Bair at oracle.com Thu Oct 18 19:17:59 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Thu, 18 Oct 2012 19:17:59 -0700 Subject: Ensemble in Mac App Store Message-ID: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> Awesome :-) https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 Jasper, great looking icon. Scott, awesome work fixing all the issues and pushing it through! From richard.bair at oracle.com Fri Oct 19 00:48:57 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Oct 2012 00:48:57 -0700 Subject: Lombard? Presidio? In-Reply-To: References: Message-ID: <48E5B103-C29D-4249-8BA1-178395964CDA@oracle.com> I've wondered why we don't rename Lombard to 8.0 in JIRA, since that's what it is. Presidio was 2.0, wasn't it? Gosh, I should go to bed. From here out I think we're sticking with version numbers. I'll ask Brian Beck (Brian, are you there?) what the story on that is. Richard On Oct 18, 2012, at 5:22 PM, Mark Fortner wrote: > Could somebody add a note in the description of the Lombard & Presidio > releases in JIRA that explains how these code names map to the current > JavaFX version numbers? I think there was some discussion earlier about > this. If the description's in JIRA at least it will be easier to set > expectations. > > Cheers, > > Mark From goddard at seznam.cz Fri Oct 19 01:08:49 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Fri, 19 Oct 2012 10:08:49 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Ensemble=20in=20Mac=20App=20Store?= In-Reply-To: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> Message-ID: <136654.14750.50169-10923-359997412-1350634129@seznam.cz> Congratulation guys! :) Jiri ------------ P?vodn? zpr?va ------------ Od: Richard Bair P?edm?t: Ensemble in Mac App Store Datum: 19.10.2012 04:20:12 ---------------------------------------- Awesome :-) https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 Jasper, great looking icon. Scott, awesome work fixing all the issues and pushing it through! From johan at lodgon.com Fri Oct 19 01:24:32 2012 From: johan at lodgon.com (Johan Vos) Date: Fri, 19 Oct 2012 10:24:32 +0200 Subject: Ensemble in Mac App Store In-Reply-To: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> Message-ID: This is a major step forward indeed. - Johan 2012/10/19 Richard Bair > Awesome :-) > > https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 > > Jasper, great looking icon. Scott, awesome work fixing all the issues and > pushing it through! From sven.reimers at gmail.com Fri Oct 19 02:25:38 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 19 Oct 2012 11:25:38 +0200 Subject: Ensemble in Mac App Store In-Reply-To: References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> Message-ID: Really good.... So - who's next? -Sven On Fri, Oct 19, 2012 at 10:24 AM, Johan Vos wrote: > This is a major step forward indeed. > > - Johan > > 2012/10/19 Richard Bair > >> Awesome :-) >> >> https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 >> >> Jasper, great looking icon. Scott, awesome work fixing all the issues and >> pushing it through! -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From mp at jugs.org Fri Oct 19 03:36:00 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 19 Oct 2012 12:36:00 +0200 Subject: Ensemble in Mac App Store In-Reply-To: References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> Message-ID: <50812D10.1060908@jugs.org> Am 19.10.2012 11:25, schrieb Sven Reimers: > Really good.... > > So - who's next? The Android and iOS App Store ? Sorry, couldn't resist :-) > > -Sven > > On Fri, Oct 19, 2012 at 10:24 AM, Johan Vos wrote: >> This is a major step forward indeed. >> >> - Johan >> >> 2012/10/19 Richard Bair >> >>> Awesome :-) >>> >>> https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 >>> >>> Jasper, great looking icon. Scott, awesome work fixing all the issues and >>> pushing it through! > > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From hang.vo at oracle.com Fri Oct 19 05:03:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 19 Oct 2012 12:03:46 +0000 Subject: hg: openjfx/8/graphics/rt: 12 new changesets Message-ID: <20121019120401.68EB247454@hg.openjdk.java.net> Changeset: 988f6f79107b Author: rbair Date: 2012-10-10 11:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/988f6f79107b Fix for RT-25049: SplitMenuButton have gap. As near as I can tell, they have a gap going back a long way. In fact, the gap is still there with Region caching disabled (in fact with region caching turned on, you don't get this gap at all, so I think this error came from some time in the past). The MenuButtonSkinBase layout was incorrect, along with the CSS. ! javafx-ui-common/src/javafx/scene/layout/CornerRadii.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 32ed56155a53 Author: rbair Date: 2012-10-11 10:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/32ed56155a53 Updated documentation to indicate contents draw over borders on regions. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: 8d346510b927 Author: leifs Date: 2012-10-11 12:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8d346510b927 Additional fix for RT-25049 to avoid label truncation. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java Changeset: 41cfd7b80910 Author: David Grieve Date: 2012-10-11 15:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/41cfd7b80910 RT-25016: calculated value not stored in cache when styles are recalculted. remove fastpath check and always cache calculated value. ensure inline styles are cached locally ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: ef37b66b00b0 Author: David Grieve Date: 2012-10-11 15:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ef37b66b00b0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 09253f3afb0b Author: leifs Date: 2012-10-11 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/09253f3afb0b Make VK_TYPE_NAMES array package private. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java Changeset: 393c90eb52e0 Author: David Grieve Date: 2012-10-12 14:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/393c90eb52e0 RT-25225: default background color should be transparent per w3c spec ! javafx-ui-common/src/javafx/scene/layout/Background.java Changeset: 9352015d712d Author: David Grieve Date: 2012-10-12 14:51 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9352015d712d RT-24784: ensure parent style manager is properly initialized ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: c731a926c171 Author: mickf Date: 2012-10-16 14:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c731a926c171 RT-20786 : Focus couldn't be received or traversed. ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 97d1312344e8 Author: leifs Date: 2012-10-16 13:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/97d1312344e8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/rt Changeset: dafaa830d4d0 Author: hudson Date: 2012-10-18 14:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dafaa830d4d0 Added tag 8.0-b61 for changeset 97d1312344e8 ! .hgtags Changeset: 923b26ed6ea4 Author: kcr Date: 2012-10-19 05:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/923b26ed6ea4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From weiqigao at gmail.com Fri Oct 19 05:11:57 2012 From: weiqigao at gmail.com (Weiqi Gao) Date: Fri, 19 Oct 2012 07:11:57 -0500 Subject: Lombard? Presidio? In-Reply-To: <48E5B103-C29D-4249-8BA1-178395964CDA@oracle.com> References: <48E5B103-C29D-4249-8BA1-178395964CDA@oracle.com> Message-ID: <19D2C243-8C77-4745-85A8-D6E7BA7454E2@gmail.com> The problem with version numbers is that you never know exactly which version you are working on until you are about to release. Just make sure people who needs to know the mapping from code names to actual version numbers know about them. A couple lines of explanation in the project's front page will do fine. -- Weiqi On Oct 19, 2012, at 2:48 AM, Richard Bair wrote: > I've wondered why we don't rename Lombard to 8.0 in JIRA, since that's what it is. Presidio was 2.0, wasn't it? Gosh, I should go to bed. From here out I think we're sticking with version numbers. I'll ask Brian Beck (Brian, are you there?) what the story on that is. > > Richard > > On Oct 18, 2012, at 5:22 PM, Mark Fortner wrote: > >> Could somebody add a note in the description of the Lombard & Presidio >> releases in JIRA that explains how these code names map to the current >> JavaFX version numbers? I think there was some discussion earlier about >> this. If the description's in JIRA at least it will be easier to set >> expectations. >> >> Cheers, >> >> Mark > From goddard at seznam.cz Fri Oct 19 05:27:19 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Fri, 19 Oct 2012 14:27:19 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Open=20Sourcing=20Status=20Report?= In-Reply-To: Message-ID: <136674.14725.50197-25437-2079876434-1350649639@seznam.cz> This is awesome, thanks for doing this :) Jiri ------------ P?vodn? zpr?va ------------ Od: Richard Bair P?edm?t: Re: Open Sourcing Status Report Datum: 19.10.2012 00:39:21 ---------------------------------------- > In terms of build support, you might want to make it easy to hook into the openjdk build and distribution system that Henri Gomez has put together here: > http://obuildfactory.hgomez.net/ > http://code.google.com/p/openjdk-osx-build/ I'll send him a note, JavaFX should be co-bundled with JRE builds, but I could imagine OpenJDK builds don't co-bundle, but it would be awesome if they did. > There are still some jira issues which give permission violations when you try to look at them. Is it possible to limit the jira issues which have restricted permissions to those which are unresolved security issues and to allow anybody to view jira cases without signing up for a jira account and logging in? I'm not sure why we don't already allow un-authenticated users from browsing JIRA. It seems odd because we should want Google indexing the thing and so forth. I've put in a question to Brian and Kevin to find out what the story on that is. I'm not comfortable with un-authenticated editing of a JIRA issue (darn spam bots), but certainly browsing should be allowed it seems. Thanks Richard From anthony.petrov at oracle.com Fri Oct 19 05:37:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 19 Oct 2012 16:37:12 +0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: <50814978.8080605@oracle.com> On 10/18/2012 11:16 PM, Richard Bair wrote: > In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. Building native code may be slow in general, but building e.g. Glass takes under a minute. Of course I agree that if code hasn't changed, it shouldn't be re-built. One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)? Another point: I see that the ultimate goal is to be able to build from an IDE, and this is fine. However, I think that building from command line should still be supported and not require any more than it requires now (which is basically just `cd to-my-repo && ant`). -- best regards, Anthony From dalibor.topic at oracle.com Fri Oct 19 05:50:30 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 19 Oct 2012 14:50:30 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <80B3D614-DACD-412A-B89D-BEE09082D958@oracle.com> Message-ID: <50814C96.8050501@oracle.com> On 10/19/12 12:56 AM, Scott Palmer wrote: > The last step isn't a big deal for me. If JavaFX is just part of the JRE > I'm not sure as a developer that I need anything more than early-access > builds (of the JRE) in order to avoid surprises. Just in case someone wasn't aware - developer preview builds of the Oracle JDK 7 are available on http://jdk7.java.net , and similarly for 8 on http://jdk8.java.net cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From kevin.rushforth at oracle.com Fri Oct 19 06:10:32 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Oct 2012 06:10:32 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50814978.8080605@oracle.com> References: <50814978.8080605@oracle.com> Message-ID: <50815148.1070007@oracle.com> > Another point: I see that the ultimate goal is to be able to build > from an IDE, and this is fine. However, I think that building from > command line should still be supported and not require any more than > it requires now ... I would go farther than that and state: Building from the IDE is a very nice developer convenience. Building from the command line is the primary way the product is built and must be supported for developer builds. -- Kevin Anthony Petrov wrote: > On 10/18/2012 11:16 PM, Richard Bair wrote: >> In addition to code generation, we also build a ton of native code >> (gstreamer, webkit, prism, fonts, glass, image loading). So that has >> to fit into the build system. Building native code is SLOW, so being >> able to avoid it for "normal" developers, and being able to avoid >> native builds when nothing changed in the native code, is important. > > Building native code may be slow in general, but building e.g. Glass > takes under a minute. Of course I agree that if code hasn't changed, > it shouldn't be re-built. > > One more point: presently we can clone the repository and build just > glass itself (which is very fast as I mentioned above). This is useful > for quick testing, and also we have a Glass-only demo app that doesn't > depend on FX, so we can work on Glass w/o even building the whole FX > right now. Can we make the new build system support this kind of > partial builds (at least for Glass)? > > Another point: I see that the ultimate goal is to be able to build > from an IDE, and this is fine. However, I think that building from > command line should still be supported and not require any more than > it requires now (which is basically just `cd to-my-repo && ant`). > > -- > best regards, > Anthony From steve.x.northover at oracle.com Fri Oct 19 06:12:53 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 19 Oct 2012 09:12:53 -0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50815148.1070007@oracle.com> References: <50814978.8080605@oracle.com> <50815148.1070007@oracle.com> Message-ID: <508151D5.7040504@oracle.com> Hilarious, I was typing about the same thing. I love IDE's but if you want to be picked up by a Linux distribution, you have to have a command line build. Stege On 19/10/2012 9:10 AM, Kevin Rushforth wrote: > >> Another point: I see that the ultimate goal is to be able to build >> from an IDE, and this is fine. However, I think that building from >> command line should still be supported and not require any more than >> it requires now ... > > I would go farther than that and state: > > Building from the IDE is a very nice developer convenience. > > Building from the command line is the primary way the product is built > and must be supported for developer builds. > > -- Kevin > > > Anthony Petrov wrote: >> On 10/18/2012 11:16 PM, Richard Bair wrote: >>> In addition to code generation, we also build a ton of native code >>> (gstreamer, webkit, prism, fonts, glass, image loading). So that has >>> to fit into the build system. Building native code is SLOW, so being >>> able to avoid it for "normal" developers, and being able to avoid >>> native builds when nothing changed in the native code, is important. >> >> Building native code may be slow in general, but building e.g. Glass >> takes under a minute. Of course I agree that if code hasn't changed, >> it shouldn't be re-built. >> >> One more point: presently we can clone the repository and build just >> glass itself (which is very fast as I mentioned above). This is >> useful for quick testing, and also we have a Glass-only demo app that >> doesn't depend on FX, so we can work on Glass w/o even building the >> whole FX right now. Can we make the new build system support this >> kind of partial builds (at least for Glass)? >> >> Another point: I see that the ultimate goal is to be able to build >> from an IDE, and this is fine. However, I think that building from >> command line should still be supported and not require any more than >> it requires now (which is basically just `cd to-my-repo && ant`). >> >> -- >> best regards, >> Anthony From markclaassenx at gmail.com Fri Oct 19 06:16:01 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Fri, 19 Oct 2012 09:16:01 -0400 Subject: TextField Document model In-Reply-To: <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> Message-ID: I am still a bit unclear on how I would do this. I would like to create and position the field using the SceneBuilder, but the document model and formatting are determined by other parameters, such as fields read out of a database. Take postal codes for instance, for the US it is #####-####, but for Canada it is A#A-#A# (where A means any letter). It would not be until they chose a country that the formatting could be selected and applied. I don't see how I can do this using the constructor approach and still use SceneBuilder without creating an extra layer of indirection designed specifically sidestep this issue. I could create a subclass of TextField that would simply pass the calls to a delegate Content, which would be pluggable. This approach, however, just sort of pushes the can down the road a bit by forcing a layer of indirection. I did not have time to look at the Skin and Behavior paradigms yet, so I can't speak to the impact on them. I will try to brush up on those this weekend. However, if this subclassing to delegate becomes relatively common, then it seems that whatever Skin and Behavior issues might arise would still need to be addressed. However now they would need to be addressed by application designers instead of by the platform. Mark On Thu, Oct 18, 2012 at 7:23 PM, Richard Bair wrote: > >> Adding a new constructor to set it once would likely work for most > cases. > >> I suspect making it dynamic is a lot more work. > > Maybe it is a bit more for the API designer, but, the way I understand > it, > > this would preclude the use of the SceneBuilder to create the components, > > without a lot of subclassing. (See the rest of this thread.) > > If this is not the case, I would be very interested to know how to > > accomplish this. > > Actually, as long as there is a Builder for the class, you should be able > to build it from FXML even if there is no default constructor. > > From neugens.limasoftware at gmail.com Fri Oct 19 06:31:52 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 19 Oct 2012 15:31:52 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: > Further more, you should be able to do "find usages" in your IDE and get EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't have enough information about the 160 other projects in our system to be able to do this. This is bad. > > Right now we build with ant. Many of you have suggested Maven. Some of you at JavaOne suggested Gradle. I am presently looking into Gradle. The key things I like about Gradle are: > > 1) It isn't XML > 2) Like Ivy & Maven, it handles dependencies well > > We presently have a pile of XML files and nasty build logic for downloading dependencies (this is all in the closed repo, but you would be exposed to the horror if we just made it all public). I wanted instead to use Ivy at the very least, but rather if I can get better build happiness from another setup entirely (like Gradle) then I might as well give it a try. I kind of like Gradle, but let me put the cart before the horse here (I don't know if this sounds as well in English as it is in Italian, where we actually use the oxen, but well :) While Maven is a well understood tool, Gradle is fairly new. This turns to be especially problematic when building and shipping on Linux distributions because there are some constraints and limitation on what can go or not in a given release (btw, I think this could be considered a problem on Windows and OSX installations in some environments where you can't simply install any tool you want). Maven, on the other end, is pretty likely sitting on your machine already (as are Make, GCC and Configure most of the time on developers machines), so I suspect it will be easier for the average folk as well as heavily filled packager to take care of the build bits. Oh my, I would have never thought I would try to sell Maven myself! Of course, don't make this stop evolutionary attempts at solving the build process, but I thought it's one consideration to take into account when deciding what build system to use, since it's such a fundamental part of the code. Ultimately, the build infrastructure should be what makes more sense for the project obviously. > 1) I'll make sure cross builds all continue to work > 2) Partial builds (for native code particularly) will continue to work such that you don't HAVE to build native code > 3) It will produce bit-for-bit compatible output in the artifacts/ directory, so all our RE (Release Engineering) scripts continue to work with little or no modification > > Also, in my tests so far the speed of the build is dramatically faster -- but then I don't have everything in yet so that might just be wishful thinking. I hope and expect it to be faster though. > > We generate code in our build system for the following reasons: > > 1) We have a VersionInfo class which the build system will update with version information. It is a com.sun.something class > 2) We have an annotation processor which generates all of the builders > 3) We have two grammars that Antlr has process to produce parsers -- one for JSL (for our shaders) and one for CSS > 4) We have a "decora compiler" which takes JSL files and feeds it through the JSL parser and produces code / shaders > > In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. Speaking about this, I wonder if we will end up doing like IcedTea with OpenJDK, since most of those probably have an OS counterpart we would rather want to use (in other words, make those elements somehow pluggable). > I have found that some of our unit tests are written such that they require more of the platform, rather than just one class. So for example, there are tests in the scene graph which might want to use a UI control for some purpose. I'm thinking the easiest thing to do is to have a test directory at the top level which houses all the tests, and break them up based on whether they are part of the smoke test, integration test, or manual test suite. Smoke tests are those that are run continuously. They must be headless, and they must be completely automated, and they must execute within some reasonable amount of time (since hudson is going to be doing it continuously). The integration tests are the rest of the automated tests that need to be run between every integration with "master". Finally the manual tests are not run as part of the integration / smoke tests, but really are just little "toys" or apps we've written that are useful when developing a feature or whatnot. We've got a ton of these little guys (mostly of the "HelloWorld" variety), and these would go into "manual". This is one advantage of maven, in that you are somehow forced to have this layout. Maven supports the idea of modules, they are a hierarchy that pretty much resembles what the project structure you depict later looks, and for each of those modules you would have unit tests. Integration tests could simply go into an high level module, the same for the manual tests. > We also will have an apps directory, where we will place all the samples (like Ensemble) and experiments (like the JavaOne Schedule Builder). > > And I want to have a "benchmarks" directory where all of our benchmarks will live. The only problem with this one is that we have a dependency on JRockit benchmark harness, and I'm not sure how to resolve that with the open source bits. Maybe the JRockit benchmark harness is already open source, I haven't dug into it yet to find out. However I believe we *must* have benchmarks open, as well as the SQE tests. My goal is to run OpenJFX in the open and to have meaningful contributions -- how can that happen if we're keeping back essential verification tools? How can somebody submit a patch and not know whether it is going to impact performance? So I want to get the benchmarks all out, but we need to figure out what to do about this dependency. Another option is to replace this dependency with one of the other open source benchmark harnesses, but this would need to be carefully considered as it would disrupt our benchmark reporting for some period of time. But ultimately having public numbers and public tests would, I think, be very beneficial across the board. As a side note, we're developing a monitoring tool for OpenJDK (Thermostat). I don't want to put Thermostat in competition with JRockit (well, I did so already!), but by the time the full code is out, we will be quite likely ready for prime time. There are also other tools that do pretty good job, like VisualVM and JConsole. Depending on the harness you have (which I assume means loads of binary files with dumps and performance related data), we can either try to make them compatible with all those tools, or better yet, develop some kind exchange format for Performance Analysis (so that we are not really depending on any tool). This can be a cool collaboration between some other teams (I suspect such an effort would go beyond JavaFX of course). In any case, having the harness in the code doesn't hurt (as soon as we don't depend on them to build the final code). Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From sven.reimers at gmail.com Fri Oct 19 06:45:23 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 19 Oct 2012 15:45:23 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50815148.1070007@oracle.com> References: <50814978.8080605@oracle.com> <50815148.1070007@oracle.com> Message-ID: Comments in-lined.. On Fri, Oct 19, 2012 at 3:10 PM, Kevin Rushforth wrote: > >> Another point: I see that the ultimate goal is to be able to build from an >> IDE, and this is fine. However, I think that building from command line >> should still be supported and not require any more than it requires now ... > > > I would go farther than that and state: > > Building from the IDE is a very nice developer convenience. Well, if you want participation from the community easy setup for hacking and building sources is more than just a convenience... > > Building from the command line is the primary way the product is built and > must be supported for developer builds. +1, a must have for CI. -Sven > > -- Kevin > > > > Anthony Petrov wrote: >> >> On 10/18/2012 11:16 PM, Richard Bair wrote: >>> >>> In addition to code generation, we also build a ton of native code >>> (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit >>> into the build system. Building native code is SLOW, so being able to avoid >>> it for "normal" developers, and being able to avoid native builds when >>> nothing changed in the native code, is important. >> >> >> Building native code may be slow in general, but building e.g. Glass takes >> under a minute. Of course I agree that if code hasn't changed, it shouldn't >> be re-built. >> >> One more point: presently we can clone the repository and build just glass >> itself (which is very fast as I mentioned above). This is useful for quick >> testing, and also we have a Glass-only demo app that doesn't depend on FX, >> so we can work on Glass w/o even building the whole FX right now. Can we >> make the new build system support this kind of partial builds (at least for >> Glass)? >> >> Another point: I see that the ultimate goal is to be able to build from an >> IDE, and this is fine. However, I think that building from command line >> should still be supported and not require any more than it requires now >> (which is basically just `cd to-my-repo && ant`). >> >> -- >> best regards, >> Anthony -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From roman at kennke.org Fri Oct 19 06:55:52 2012 From: roman at kennke.org (Roman Kennke) Date: Fri, 19 Oct 2012 15:55:52 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: <1350654952.4085.18.camel@mercury> Am Freitag, den 19.10.2012, 15:31 +0200 schrieb Mario Torre: > > Further more, you should be able to do "find usages" in your IDE and get EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't have enough information about the 160 other projects in our system to be able to do this. This is bad. > > > > Right now we build with ant. Many of you have suggested Maven. Some of you at JavaOne suggested Gradle. I am presently looking into Gradle. The key things I like about Gradle are: > > > > 1) It isn't XML > > 2) Like Ivy & Maven, it handles dependencies well > > > > We presently have a pile of XML files and nasty build logic for downloading dependencies (this is all in the closed repo, but you would be exposed to the horror if we just made it all public). I wanted instead to use Ivy at the very least, but rather if I can get better build happiness from another setup entirely (like Gradle) then I might as well give it a try. > > I kind of like Gradle, but let me put the cart before the horse here > (I don't know if this sounds as well in English as it is in Italian, > where we actually use the oxen, but well :) > > While Maven is a well understood tool, Gradle is fairly new. This > turns to be especially problematic when building and shipping on Linux > distributions because there are some constraints and limitation on > what can go or not in a given release (btw, I think this could be > considered a problem on Windows and OSX installations in some > environments where you can't simply install any tool you want). > > Maven, on the other end, is pretty likely sitting on your machine > already (as are Make, GCC and Configure most of the time on developers > machines), so I suspect it will be easier for the average folk as well > as heavily filled packager to take care of the build bits. I totally agree with this, but would take a view from the IDE angle at it. I still remember the days when Maven was 'young' (i.e. just a few years old ;-) ), there was an Eclipse plugin, but it was horror. Only recently the Eclipse-Maven plugin evolved into something truly useful. I don't know how good or bad a Gradle plugin for Eclipse does though, or if it even exists (I am sure it does). However, there is more to this than just that. JavaFX comes with a bunch of native code (quite a lot, I'd figure). The IDE extensions for C/C++ hacking (e.g. CDT for Eclipse) are usually really good at handling configure/make style projects, but totally lack support for anything else (e.g. Maven, Ant or even Gradle). That is in part due to the fact that Maven, Ant (dunno about Gradle) themselves are not that well-suited for building C/C++ code. For example, I am completely hacking on OpenJDK/Hotspot using Eclipse, with just make, and it wasn't even difficult to setup, and yes, I can hit 'go' and it builds+runs whatever I want with my code or 'find' and it finds everything in the universe (both C/C++ and Java). So, from my point of view, what would work well is probably make for native code and ant or maven or whatever for Java code (and just call one from the other to make it a nicely integrated build). Roman From tom.schindl at bestsolution.at Fri Oct 19 07:05:07 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 19 Oct 2012 16:05:07 +0200 Subject: SWT build dependency In-Reply-To: <5080976C.3050908@bestsolution.at> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> <5080976C.3050908@bestsolution.at> Message-ID: <50815E13.60802@bestsolution.at> Steve replied to me in private that you need to have the real SWT-Jars for each and every platform because the automated test runs against them. The Jar for the JavaFX supported platforms are: http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/... * org.eclipse.swt.cocoa.macosx.x86_64_3.7.2.v3740f.jar * org.eclipse.swt.gtk.linux.x86_3.7.2.v3740f.jar * org.eclipse.swt.gtk.linux.x86_64_3.7.2.v3740f.jar * org.eclipse.swt.win32.win32.x86_3.7.2.v3740f.jar * org.eclipse.swt.win32.win32.x86_64_3.7.2.v3740f.jar As a general note in this area. a) bundling the swt bits with the javafxrt.jar is a problem when putting fx on the bootclasspath b) wouldn't it be better if Oracle contributes the code to Eclipse.org, the SWT-Swing bridge is already part of SWT (in light of a this makes even more sense) Tom Am 19.10.12 01:57, schrieb Tom Schindl: > That can't work there you get a zip which inlcude swt.jar. You need to > have the plain jar. > > Which you can get from: > > http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/ > > The mac one is named org.eclipse.swt.cocoa.macosx_3.7.2.v3740f.jar > because you only need to compile against it doesn't really matter which > platform you compile against. > > Tom > > > Am 19.10.12 01:30, schrieb Richard Bair: >> So may latest headache is downloading the SWT dependency for our build. We use SWT for the SWT embedding support. So this is what I tried from looking at various blogs, because the version of SWT I'm looking for isn't in a Repo: >> >> project(':swt') { >> sourceSets.main.java.srcDirs = ['src/java'] >> dependencies { >> compile project(':build-tools'), project(':base'), project(':graphics') >> compile module('org.eclipse.swt:org.eclipse.swt:3.7.1 at jar') { >> //name = 'org.eclipse.swt' >> extension = 'jar' >> url = 'http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.1-201109091335/swt-3.7.1-cocoa-macosx-x86_64.zip' >> } >> } >> } >> >> >> so I'm trying to download directly from a URL. No dice. Still browsing the web looking for some solution >> > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Fri Oct 19 07:19:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Oct 2012 07:19:39 -0700 Subject: Lombard? Presidio? In-Reply-To: <19D2C243-8C77-4745-85A8-D6E7BA7454E2@gmail.com> References: <48E5B103-C29D-4249-8BA1-178395964CDA@oracle.com> <19D2C243-8C77-4745-85A8-D6E7BA7454E2@gmail.com> Message-ID: Yes, you are right, and when some security uber-fix comes along due to some ravaging exploit and we have to bump all the version numbers -- in such cases you really wish you didn't have version numbers. At least for the update releases. Richard On Oct 19, 2012, at 5:11 AM, Weiqi Gao wrote: > The problem with version numbers is that you never know exactly which version you are working on until you are about to release. Just make sure people who needs to know the mapping from code names to actual version numbers know about them. A couple lines of explanation in the project's front page will do fine. > > -- > Weiqi > > On Oct 19, 2012, at 2:48 AM, Richard Bair wrote: > >> I've wondered why we don't rename Lombard to 8.0 in JIRA, since that's what it is. Presidio was 2.0, wasn't it? Gosh, I should go to bed. From here out I think we're sticking with version numbers. I'll ask Brian Beck (Brian, are you there?) what the story on that is. >> >> Richard >> >> On Oct 18, 2012, at 5:22 PM, Mark Fortner wrote: >> >>> Could somebody add a note in the description of the Lombard & Presidio >>> releases in JIRA that explains how these code names map to the current >>> JavaFX version numbers? I think there was some discussion earlier about >>> this. If the description's in JIRA at least it will be easier to set >>> expectations. >>> >>> Cheers, >>> >>> Mark >> > From kevin.rushforth at oracle.com Fri Oct 19 07:20:14 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Oct 2012 07:20:14 -0700 Subject: SWT build dependency In-Reply-To: <50815E13.60802@bestsolution.at> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> <5080976C.3050908@bestsolution.at> <50815E13.60802@bestsolution.at> Message-ID: <5081619E.5010809@oracle.com> > > a) bundling the swt bits with the javafxrt.jar is a problem when > putting fx on the bootclasspath In fact http://javafx-jira.kenai.com/browse/RT-23041 has been filed to unbundle javafx.embed.swt from jfxrt.jar for precisely this reason. -- Kevin Tom Schindl wrote: > Steve replied to me in private that you need to have the real SWT-Jars > for each and every platform because the automated test runs against them. > > The Jar for the JavaFX supported platforms are: > http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/... > * org.eclipse.swt.cocoa.macosx.x86_64_3.7.2.v3740f.jar > * org.eclipse.swt.gtk.linux.x86_3.7.2.v3740f.jar > * org.eclipse.swt.gtk.linux.x86_64_3.7.2.v3740f.jar > * org.eclipse.swt.win32.win32.x86_3.7.2.v3740f.jar > * org.eclipse.swt.win32.win32.x86_64_3.7.2.v3740f.jar > > As a general note in this area. > a) bundling the swt bits with the javafxrt.jar is a problem when > putting fx on the bootclasspath > b) wouldn't it be better if Oracle contributes the code to Eclipse.org, > the SWT-Swing bridge is already part of SWT (in light of a this > makes even more sense) > > Tom > > Am 19.10.12 01:57, schrieb Tom Schindl: > >> That can't work there you get a zip which inlcude swt.jar. You need to >> have the plain jar. >> >> Which you can get from: >> >> http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/ >> >> The mac one is named org.eclipse.swt.cocoa.macosx_3.7.2.v3740f.jar >> because you only need to compile against it doesn't really matter which >> platform you compile against. >> >> Tom >> >> >> Am 19.10.12 01:30, schrieb Richard Bair: >> >>> So may latest headache is downloading the SWT dependency for our build. We use SWT for the SWT embedding support. So this is what I tried from looking at various blogs, because the version of SWT I'm looking for isn't in a Repo: >>> >>> project(':swt') { >>> sourceSets.main.java.srcDirs = ['src/java'] >>> dependencies { >>> compile project(':build-tools'), project(':base'), project(':graphics') >>> compile module('org.eclipse.swt:org.eclipse.swt:3.7.1 at jar') { >>> //name = 'org.eclipse.swt' >>> extension = 'jar' >>> url = 'http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.1-201109091335/swt-3.7.1-cocoa-macosx-x86_64.zip' >>> } >>> } >>> } >>> >>> >>> so I'm trying to download directly from a URL. No dice. Still browsing the web looking for some solution >>> >>> >> > > > From danno.ferrin at shemnon.com Fri Oct 19 07:24:02 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Fri, 19 Oct 2012 08:24:02 -0600 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: On Fri, Oct 19, 2012 at 7:31 AM, Mario Torre wrote: > > Further more, you should be able to do "find usages" in your IDE and get > EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't > have enough information about the 160 other projects in our system to be > able to do this. This is bad. > > > > Right now we build with ant. Many of you have suggested Maven. Some of > you at JavaOne suggested Gradle. I am presently looking into Gradle. The > key things I like about Gradle are: > > > > 1) It isn't XML > > 2) Like Ivy & Maven, it handles dependencies well > > > > We presently have a pile of XML files and nasty build logic for > downloading dependencies (this is all in the closed repo, but you would be > exposed to the horror if we just made it all public). I wanted instead to > use Ivy at the very least, but rather if I can get better build happiness > from another setup entirely (like Gradle) then I might as well give it a > try. > > I kind of like Gradle, but let me put the cart before the horse here > (I don't know if this sounds as well in English as it is in Italian, > where we actually use the oxen, but well :) > > While Maven is a well understood tool, Gradle is fairly new. This > turns to be especially problematic when building and shipping on Linux > distributions because there are some constraints and limitation on > what can go or not in a given release (btw, I think this could be > considered a problem on Windows and OSX installations in some > environments where you can't simply install any tool you want). > > Maven, on the other end, is pretty likely sitting on your machine > already (as are Make, GCC and Configure most of the time on developers > machines), so I suspect it will be easier for the average folk as well > as heavily filled packager to take care of the build bits. > Gradle has a "wrapper" script that can be checked in with the build (the gradlew script), it will download the specific version of gradle and build it in place, from the build. So having Gradle on your machine is not a requirement, the gradle script will build with it in place like it was an external library. Plus, Android has just shifted to building user projects with Gradle instead of Ant. So there will be many Linux distros that will ship and approve Gradle just for that reason. > > Oh my, I would have never thought I would try to sell Maven myself! Of > course, don't make this stop evolutionary attempts at solving the > build process, but I thought it's one consideration to take into > account when deciding what build system to use, since it's such a > fundamental part of the code. > > Ultimately, the build infrastructure should be what makes more sense > for the project obviously. > > > 1) I'll make sure cross builds all continue to work > > 2) Partial builds (for native code particularly) will continue > to work such that you don't HAVE to build native code > > 3) It will produce bit-for-bit compatible output in the > artifacts/ directory, so all our RE (Release Engineering) scripts continue > to work with little or no modification > > > > Also, in my tests so far the speed of the build is dramatically faster > -- but then I don't have everything in yet so that might just be wishful > thinking. I hope and expect it to be faster though. > > > > We generate code in our build system for the following reasons: > > > > 1) We have a VersionInfo class which the build system will > update with version information. It is a com.sun.something class > > 2) We have an annotation processor which generates all of the > builders > > 3) We have two grammars that Antlr has process to produce > parsers -- one for JSL (for our shaders) and one for CSS > > 4) We have a "decora compiler" which takes JSL files and feeds > it through the JSL parser and produces code / shaders > > > > In addition to code generation, we also build a ton of native code > (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit > into the build system. Building native code is SLOW, so being able to avoid > it for "normal" developers, and being able to avoid native builds when > nothing changed in the native code, is important. > > Speaking about this, I wonder if we will end up doing like IcedTea > with OpenJDK, since most of those probably have an OS counterpart we > would rather want to use (in other words, make those elements somehow > pluggable). > > > I have found that some of our unit tests are written such that they > require more of the platform, rather than just one class. So for example, > there are tests in the scene graph which might want to use a UI control for > some purpose. I'm thinking the easiest thing to do is to have a test > directory at the top level which houses all the tests, and break them up > based on whether they are part of the smoke test, integration test, or > manual test suite. Smoke tests are those that are run continuously. They > must be headless, and they must be completely automated, and they must > execute within some reasonable amount of time (since hudson is going to be > doing it continuously). The integration tests are the rest of the automated > tests that need to be run between every integration with "master". Finally > the manual tests are not run as part of the integration / smoke tests, but > really are just little "toys" or apps we've written that are useful when > developing a feature or whatnot. We've got a ton of these little guys > (mostly of the "HelloWorld" variety), and these would go into "manual". > > This is one advantage of maven, in that you are somehow forced to have > this layout. Maven supports the idea of modules, they are a hierarchy > that pretty much resembles what the project structure you depict later > looks, and for each of those modules you would have unit tests. > Integration tests could simply go into an high level module, the same > for the manual tests. > The problem with Maven is when you get off the beaten path (like running your own annotation processor, shipping source code in the jar, custom build languages) the build script gets very verbose and hard to read. All the XML creates more noise. Yes, you can do it, but it becomes difficult to maintain. Build scripts for Maven projects that follow the maven conventions are dead simple, but OpenJFX is not one of those run of the mill builds. > > > We also will have an apps directory, where we will place all the samples > (like Ensemble) and experiments (like the JavaOne Schedule Builder). > > > > And I want to have a "benchmarks" directory where all of our benchmarks > will live. The only problem with this one is that we have a dependency on > JRockit benchmark harness, and I'm not sure how to resolve that with the > open source bits. Maybe the JRockit benchmark harness is already open > source, I haven't dug into it yet to find out. However I believe we *must* > have benchmarks open, as well as the SQE tests. My goal is to run OpenJFX > in the open and to have meaningful contributions -- how can that happen if > we're keeping back essential verification tools? How can somebody submit a > patch and not know whether it is going to impact performance? So I want to > get the benchmarks all out, but we need to figure out what to do about this > dependency. Another option is to replace this dependency with one of the > other open source benchmark harnesses, but this would need to be carefully > considered as it would disrupt our benchmark reporting for some period of > time. But ultimately having public numbers and public tests would, I think, > be very beneficial across the board. > > As a side note, we're developing a monitoring tool for OpenJDK > (Thermostat). I don't want to put Thermostat in competition with > JRockit (well, I did so already!), but by the time the full code is > out, we will be quite likely ready for prime time. There are also > other tools that do pretty good job, like VisualVM and JConsole. > Depending on the harness you have (which I assume means loads of > binary files with dumps and performance related data), we can either > try to make them compatible with all those tools, or better yet, > develop some kind exchange format for Performance Analysis (so that we > are not really depending on any tool). This can be a cool > collaboration between some other teams (I suspect such an effort would > go beyond JavaFX of course). In any case, having the harness in the > code doesn't hurt (as soon as we don't depend on them to build the > final code). > > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From steve.x.northover at oracle.com Fri Oct 19 07:28:41 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 19 Oct 2012 10:28:41 -0400 Subject: SWT build dependency In-Reply-To: <50815E13.60802@bestsolution.at> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> <5080976C.3050908@bestsolution.at> <50815E13.60802@bestsolution.at> Message-ID: <50816399.1030301@oracle.com> .. the reply in private was an accident. Thanks for forwarding back to the list. I'm not against contributing the code to Eclipse.org and having it in SWT, just like the Swing bridge. There are a few arguments against this. The code uses objects and frameworks that are not yet open source. It is easier to keep the code up to date when FX changes and ensure that interop works from day one when FX ships rather than aligning with an Eclipse release. Steve On 19/10/2012 10:05 AM, Tom Schindl wrote: > Steve replied to me in private that you need to have the real SWT-Jars > for each and every platform because the automated test runs against them. > > The Jar for the JavaFX supported platforms are: > http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/... > * org.eclipse.swt.cocoa.macosx.x86_64_3.7.2.v3740f.jar > * org.eclipse.swt.gtk.linux.x86_3.7.2.v3740f.jar > * org.eclipse.swt.gtk.linux.x86_64_3.7.2.v3740f.jar > * org.eclipse.swt.win32.win32.x86_3.7.2.v3740f.jar > * org.eclipse.swt.win32.win32.x86_64_3.7.2.v3740f.jar > > As a general note in this area. > a) bundling the swt bits with the javafxrt.jar is a problem when > putting fx on the bootclasspath > b) wouldn't it be better if Oracle contributes the code to Eclipse.org, > the SWT-Swing bridge is already part of SWT (in light of a this > makes even more sense) > > Tom > > Am 19.10.12 01:57, schrieb Tom Schindl: >> That can't work there you get a zip which inlcude swt.jar. You need to >> have the plain jar. >> >> Which you can get from: >> >> http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/ >> >> The mac one is named org.eclipse.swt.cocoa.macosx_3.7.2.v3740f.jar >> because you only need to compile against it doesn't really matter which >> platform you compile against. >> >> Tom >> >> >> Am 19.10.12 01:30, schrieb Richard Bair: >>> So may latest headache is downloading the SWT dependency for our build. We use SWT for the SWT embedding support. So this is what I tried from looking at various blogs, because the version of SWT I'm looking for isn't in a Repo: >>> >>> project(':swt') { >>> sourceSets.main.java.srcDirs = ['src/java'] >>> dependencies { >>> compile project(':build-tools'), project(':base'), project(':graphics') >>> compile module('org.eclipse.swt:org.eclipse.swt:3.7.1 at jar') { >>> //name = 'org.eclipse.swt' >>> extension = 'jar' >>> url = 'http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.1-201109091335/swt-3.7.1-cocoa-macosx-x86_64.zip' >>> } >>> } >>> } >>> >>> >>> so I'm trying to download directly from a URL. No dice. Still browsing the web looking for some solution >>> >> > From richard.bair at oracle.com Fri Oct 19 07:34:20 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Oct 2012 07:34:20 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50814978.8080605@oracle.com> References: <50814978.8080605@oracle.com> Message-ID: <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> > On 10/18/2012 11:16 PM, Richard Bair wrote: >> In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. > > Building native code may be slow in general, but building e.g. Glass takes under a minute. Of course I agree that if code hasn't changed, it shouldn't be re-built. > > One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)? I don't know that compilation time is actually going to be a problem in practice. I already have the prototype build setup to build all of base, graphics (which is Scene Graph + Prism + Glass), and controls and it only takes a few seconds on my machine, which is saying something, because my machine has a very slow harddrive and chronically long build times. I also expect there will be build targets for only building specific native parts, so you could say something like: gradle :graphics compile-glass-native and it would only compile the glass natives. In that case, I think you still have the ability to just clone, compile the natives, and run rain. > Another point: I see that the ultimate goal is to be able to build from an IDE, and this is fine. However, I think that building from command line should still be supported and not require any more than it requires now (which is basically just `cd to-my-repo && ant`). Yes, I think that goes without saying. Gradle (and Maven) are fully controllable / usable from the command line. Cheers Richard From danno.ferrin at shemnon.com Fri Oct 19 07:37:28 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Fri, 19 Oct 2012 08:37:28 -0600 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <1350654952.4085.18.camel@mercury> References: <1350654952.4085.18.camel@mercury> Message-ID: On Fri, Oct 19, 2012 at 7:55 AM, Roman Kennke wrote: > Am Freitag, den 19.10.2012, 15:31 +0200 schrieb Mario Torre: > > > Further more, you should be able to do "find usages" in your IDE and > get EVERYTHING IN THE UNIVERSE, rather than right now where in NB it > doesn't have enough information about the 160 other projects in our system > to be able to do this. This is bad. > > > > > > Right now we build with ant. Many of you have suggested Maven. Some of > you at JavaOne suggested Gradle. I am presently looking into Gradle. The > key things I like about Gradle are: > > > > > > 1) It isn't XML > > > 2) Like Ivy & Maven, it handles dependencies well > > > > > > We presently have a pile of XML files and nasty build logic for > downloading dependencies (this is all in the closed repo, but you would be > exposed to the horror if we just made it all public). I wanted instead to > use Ivy at the very least, but rather if I can get better build happiness > from another setup entirely (like Gradle) then I might as well give it a > try. > > > > I kind of like Gradle, but let me put the cart before the horse here > > (I don't know if this sounds as well in English as it is in Italian, > > where we actually use the oxen, but well :) > > > > While Maven is a well understood tool, Gradle is fairly new. This > > turns to be especially problematic when building and shipping on Linux > > distributions because there are some constraints and limitation on > > what can go or not in a given release (btw, I think this could be > > considered a problem on Windows and OSX installations in some > > environments where you can't simply install any tool you want). > > > > Maven, on the other end, is pretty likely sitting on your machine > > already (as are Make, GCC and Configure most of the time on developers > > machines), so I suspect it will be easier for the average folk as well > > as heavily filled packager to take care of the build bits. > > I totally agree with this, but would take a view from the IDE angle at > it. I still remember the days when Maven was 'young' (i.e. just a few > years old ;-) ), there was an Eclipse plugin, but it was horror. Only > recently the Eclipse-Maven plugin evolved into something truly useful. I > don't know how good or bad a Gradle plugin for Eclipse does though, or > if it even exists (I am sure it does). > I've heard good things about the Spring Source Tools Gradle plugin http://static.springsource.org/sts/docs/latest/reference/html/gradle/ but I am not an Eclipse user. Idea has built in support for Gradle. Idea is my current IDE of choice. (Sidebar, when is netbeans going to get changelist support?) There is a NetBeans project starting for Gradle: https://github.com/kelemen/netbeans-gradle-project Gradle can also spit out Eclipse projects and Idea projects. That is what I use personally. Since eclipse projects are fairly universal any IDE that people may want to hack in can ingest that. (JDeveloper?) > However, there is more to this than just that. JavaFX comes with a bunch > of native code (quite a lot, I'd figure). The IDE extensions for C/C++ > hacking (e.g. CDT for Eclipse) are usually really good at handling > configure/make style projects, but totally lack support for anything > else (e.g. Maven, Ant or even Gradle). That is in part due to the fact > that Maven, Ant (dunno about Gradle) themselves are not that well-suited > for building C/C++ code. For example, I am completely hacking on > OpenJDK/Hotspot using Eclipse, with just make, and it wasn't even > difficult to setup, and yes, I can hit 'go' and it builds+runs whatever > I want with my code or 'find' and it finds everything in the universe > (both C/C++ and Java). > > What would be nice is if the snapshot builds posted the intermediaries to a public facing repository so that installing the naitve build chain ins not a requirement. IIRC you need a non-free-as-in-beer VisualC++ compiler to spit out windows builds. (I may be wrong as my knowledge is dated). > So, from my point of view, what would work well is probably make for > native code and ant or maven or whatever for Java code (and just call > one from the other to make it a nicely integrated build). > > Roman > > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From neugens.limasoftware at gmail.com Fri Oct 19 07:39:14 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 19 Oct 2012 16:39:14 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: 2012/10/19 Danno Ferrin : > > > On Fri, Oct 19, 2012 at 7:31 AM, Mario Torre > wrote: >> >> > Further more, you should be able to do "find usages" in your IDE and get >> > EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't >> > have enough information about the 160 other projects in our system to be >> > able to do this. This is bad. >> > >> > Right now we build with ant. Many of you have suggested Maven. Some of >> > you at JavaOne suggested Gradle. I am presently looking into Gradle. The key >> > things I like about Gradle are: >> > >> > 1) It isn't XML >> > 2) Like Ivy & Maven, it handles dependencies well >> > >> > We presently have a pile of XML files and nasty build logic for >> > downloading dependencies (this is all in the closed repo, but you would be >> > exposed to the horror if we just made it all public). I wanted instead to >> > use Ivy at the very least, but rather if I can get better build happiness >> > from another setup entirely (like Gradle) then I might as well give it a >> > try. >> >> I kind of like Gradle, but let me put the cart before the horse here >> (I don't know if this sounds as well in English as it is in Italian, >> where we actually use the oxen, but well :) >> >> While Maven is a well understood tool, Gradle is fairly new. This >> turns to be especially problematic when building and shipping on Linux >> distributions because there are some constraints and limitation on >> what can go or not in a given release (btw, I think this could be >> considered a problem on Windows and OSX installations in some >> environments where you can't simply install any tool you want). >> >> Maven, on the other end, is pretty likely sitting on your machine >> already (as are Make, GCC and Configure most of the time on developers >> machines), so I suspect it will be easier for the average folk as well >> as heavily filled packager to take care of the build bits. > > > Gradle has a "wrapper" script that can be checked in with the build (the > gradlew script), it will download the specific version of gradle and build > it in place, from the build. So having Gradle on your machine is not a > requirement, the gradle script will build with it in place like it was an > external library. Yeah, but this is an issue for Linux distributions that want to package and ship JavaFX, it also doesn't really solve the problem if you can't install things on your machine that easily. > Plus, Android has just shifted to building user projects with Gradle instead > of Ant. So there will be many Linux distros that will ship and approve > Gradle just for that reason. Maybe, but this is still far in the future, and it will remain so for long enough to actually make a difference... > The problem with Maven is when you get off the beaten path (like running > your own annotation processor, shipping source code in the jar, custom build > languages) the build script gets very verbose and hard to read. All the XML > creates more noise. Yes, you can do it, but it becomes difficult to > maintain. Build scripts for Maven projects that follow the maven > conventions are dead simple, but OpenJFX is not one of those run of the mill > builds. Yeah, I agree. Just to be very clear what I mean, I don't think JavaFX should necessarily embrace Maven, or any other specific tool; ultimately what makes more sense for JavaFX is the way to go. If something that is incompatible with the distributions will be used, we will pretty much have some kind of wrapper projects, say IcedTeaFX or such, to take care of that, exactlu the way it has been done for OpenJDK and IcedTea, so this is less than issue than what it seems. On the other end, upstream should be aware of downstream when doing such critical decisions, that's the only reason why I bring this here now, one way or the other it may turns more friendly (or get more work on) the downstream side of things. Again, not enough alone to drive the choice, but something to think of seriously. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From tom.schindl at bestsolution.at Fri Oct 19 07:41:40 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 19 Oct 2012 16:41:40 +0200 Subject: SWT build dependency In-Reply-To: <50816399.1030301@oracle.com> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> <5080976C.3050908@bestsolution.at> <50815E13.60802@bestsolution.at> <50816399.1030301@oracle.com> Message-ID: <508166A4.3060808@bestsolution.at> Am 19.10.12 16:28, schrieb steve.x.northover at oracle.com: > .. the reply in private was an accident. Thanks for forwarding back to > the list. > > I'm not against contributing the code to Eclipse.org and having it in > SWT, just like the Swing bridge. There are a few arguments against > this. The code uses objects and frameworks that are not yet open > source. It is easier to keep the code up to date when FX changes and > ensure that interop works from day one when FX ships rather than > aligning with an Eclipse release. > (I assume most people consume SWT along with Eclipse-RCP in an OSGi-Env) For people to easily consume those in their RCP application the following would be ideal: a) the jar has the OSGi-Manifest headers b) the OSGi-Bundle is part of the p2 repository To align it with FX rather than SWT I guess this would be possible at the moment someone proposes an JavaFX-Project at Eclipse.org ;-) and Oracles contribution to it is the SWT-FX-Bridge. The project then aligns its release schedule to the one of FX beside following the Eclipse-Release-train. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From steve.x.northover at oracle.com Fri Oct 19 07:46:38 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 19 Oct 2012 10:46:38 -0400 Subject: SWT build dependency In-Reply-To: <508166A4.3060808@bestsolution.at> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> <5080976C.3050908@bestsolution.at> <50815E13.60802@bestsolution.at> <50816399.1030301@oracle.com> <508166A4.3060808@bestsolution.at> Message-ID: <508167CE.8090004@oracle.com> Sure, but if the bridge is part of SWT and joins that code base (like the Swing bridge), then it gets released with SWT. Steve On 19/10/2012 10:41 AM, Tom Schindl wrote: > Am 19.10.12 16:28, schrieb steve.x.northover at oracle.com: >> .. the reply in private was an accident. Thanks for forwarding back to >> the list. >> >> I'm not against contributing the code to Eclipse.org and having it in >> SWT, just like the Swing bridge. There are a few arguments against >> this. The code uses objects and frameworks that are not yet open >> source. It is easier to keep the code up to date when FX changes and >> ensure that interop works from day one when FX ships rather than >> aligning with an Eclipse release. >> > (I assume most people consume SWT along with Eclipse-RCP in an OSGi-Env) > > For people to easily consume those in their RCP application the > following would be ideal: > a) the jar has the OSGi-Manifest headers > b) the OSGi-Bundle is part of the p2 repository > > To align it with FX rather than SWT I guess this would be possible at > the moment someone proposes an JavaFX-Project at Eclipse.org ;-) and > Oracles contribution to it is the SWT-FX-Bridge. > > The project then aligns its release schedule to the one of FX beside > following the Eclipse-Release-train. > > Tom > > From anthony.petrov at oracle.com Fri Oct 19 07:58:02 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 19 Oct 2012 18:58:02 +0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> References: <50814978.8080605@oracle.com> <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> Message-ID: <50816A7A.9020404@oracle.com> On 10/19/2012 6:34 PM, Richard Bair wrote: >> On 10/18/2012 11:16 PM, Richard Bair wrote: >>> In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. >> Building native code may be slow in general, but building e.g. Glass takes under a minute. Of course I agree that if code hasn't changed, it shouldn't be re-built. >> >> One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)? > > I don't know that compilation time is actually going to be a problem in practice. I already have the prototype build setup to build all of base, graphics (which is Scene Graph + Prism + Glass), and controls and it only takes a few seconds on my machine, which is saying something, because my machine has a very slow harddrive and chronically long build times. I also expect there will be build targets for only building specific native parts, so you could say something like: > > gradle :graphics compile-glass-native > > and it would only compile the glass natives. In that case, I think you still have the ability to just clone, compile the natives, and run rain. Using partial build targets sounds interesting. Let's see how it will look in the end. But for some reason I can't believe (I wish!) it takes just a few seconds for your builds. Are you only compiling java code, or does this also include the native libs in prism/glass as well? On what platform are you currently testing? >> Another point: I see that the ultimate goal is to be able to build from an IDE, and this is fine. However, I think that building from command line should still be supported and not require any more than it requires now (which is basically just `cd to-my-repo && ant`). > > Yes, I think that goes without saying. Gradle (and Maven) are fully controllable / usable from the command line. Good to know this. -- best regards, Anthony From anthony.petrov at oracle.com Fri Oct 19 08:00:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 19 Oct 2012 19:00:23 +0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <1350654952.4085.18.camel@mercury> Message-ID: <50816B07.9030400@oracle.com> On 10/19/2012 6:37 PM, Danno Ferrin wrote: > What would be nice is if the snapshot builds posted the intermediaries to a > public facing repository so that installing the naitve build chain ins not > a requirement. IIRC you need a non-free-as-in-beer VisualC++ compiler to > spit out windows builds. (I may be wrong as my knowledge is dated). JDK can be built using a free VS 2010 Express edition. I think FX can be built with this free compiler as well. -- best regards, Anthony From swpalmer at gmail.com Fri Oct 19 08:01:47 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 19 Oct 2012 11:01:47 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> Message-ID: Put the dynamic aspect inside your Content implementation. So it can delegate to something that handles whatever the current format should be. You still pass one fixed interface to the constructor. Scott On 2012-10-19, at 9:16 AM, Mark Claassen wrote: > I am still a bit unclear on how I would do this. I would like to create > and position the field using the SceneBuilder, but the document model and > formatting are determined by other parameters, such as fields read out of a > database. Take postal codes for instance, for the US it is #####-####, but > for Canada it is A#A-#A# (where A means any letter). It would not be until > they chose a country that the formatting could be selected and applied. > > I don't see how I can do this using the constructor approach and still use > SceneBuilder without creating an extra layer of indirection designed > specifically sidestep this issue. I could create a subclass of TextField > that would simply pass the calls to a delegate Content, which would be > pluggable. This approach, however, just sort of pushes the can down the > road a bit by forcing a layer of indirection. > > I did not have time to look at the Skin and Behavior paradigms yet, so I > can't speak to the impact on them. I will try to brush up on those this > weekend. However, if this subclassing to delegate becomes relatively > common, then it seems that whatever Skin and Behavior issues might arise > would still need to be addressed. However now they would need to be > addressed by application designers instead of by the platform. > > Mark > > On Thu, Oct 18, 2012 at 7:23 PM, Richard Bair wrote: > >>>> Adding a new constructor to set it once would likely work for most >> cases. >>>> I suspect making it dynamic is a lot more work. >>> Maybe it is a bit more for the API designer, but, the way I understand >> it, >>> this would preclude the use of the SceneBuilder to create the components, >>> without a lot of subclassing. (See the rest of this thread.) >>> If this is not the case, I would be very interested to know how to >>> accomplish this. >> >> Actually, as long as there is a Builder for the class, you should be able >> to build it from FXML even if there is no default constructor. >> >> From richard.bair at oracle.com Fri Oct 19 08:23:02 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Oct 2012 08:23:02 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50816A7A.9020404@oracle.com> References: <50814978.8080605@oracle.com> <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> <50816A7A.9020404@oracle.com> Message-ID: <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> >>> One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)? >> I don't know that compilation time is actually going to be a problem in practice. I already have the prototype build setup to build all of base, graphics (which is Scene Graph + Prism + Glass), and controls and it only takes a few seconds on my machine, which is saying something, because my machine has a very slow harddrive and chronically long build times. I also expect there will be build targets for only building specific native parts, so you could say something like: >> gradle :graphics compile-glass-native >> and it would only compile the glass natives. In that case, I think you still have the ability to just clone, compile the natives, and run rain. > > Using partial build targets sounds interesting. Let's see how it will look in the end. > > But for some reason I can't believe (I wish!) it takes just a few seconds for your builds. Are you only compiling java code, or does this also include the native libs in prism/glass as well? On what platform are you currently testing? Yes you are right, I am cheating as I haven't built the natives yet. BUT, that's because I am putting a plan in place to reuse the latest built natives (from a hudson job, for example) rather than having to recompile all the natives, so that your "typical" javaFX developer doesn't have to have a native toolchain installed, in which case the build really will only be a few seconds (by few, meaning, 17 or so I think was the last count). I'm on a 3yr old Mac. Richard From swpalmer at gmail.com Fri Oct 19 09:05:09 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 19 Oct 2012 12:05:09 -0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50814C96.8050501@oracle.com> References: <80B3D614-DACD-412A-B89D-BEE09082D958@oracle.com> <50814C96.8050501@oracle.com> Message-ID: <016B3E14-D77E-4F34-B178-132D51AA764A@gmail.com> On 2012-10-19, at 8:50 AM, Dalibor Topic wrote: > On 10/19/12 12:56 AM, Scott Palmer wrote: >> The last step isn't a big deal for me. If JavaFX is just part of the JRE >> I'm not sure as a developer that I need anything more than early-access >> builds (of the JRE) in order to avoid surprises. > > Just in case someone wasn't aware - developer preview builds of the Oracle JDK > 7 are available on http://jdk7.java.net , and similarly for 8 on http://jdk8.java.net > Yes, but we have absolutely no idea what version of JavaFX is included. The last 3 or 4 builds of 7u10 show "no changes" in the change log. That is mysterious. Why then have a new build at all? Did the embedded JavaFX change? Scott From anthony.petrov at oracle.com Fri Oct 19 09:09:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 19 Oct 2012 20:09:49 +0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> References: <50814978.8080605@oracle.com> <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> <50816A7A.9020404@oracle.com> <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> Message-ID: <50817B4D.1040803@oracle.com> On 10/19/2012 7:23 PM, Richard Bair wrote: >>>> One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)? >>> I don't know that compilation time is actually going to be a problem in practice. I already have the prototype build setup to build all of base, graphics (which is Scene Graph + Prism + Glass), and controls and it only takes a few seconds on my machine, which is saying something, because my machine has a very slow harddrive and chronically long build times. I also expect there will be build targets for only building specific native parts, so you could say something like: >>> gradle :graphics compile-glass-native >>> and it would only compile the glass natives. In that case, I think you still have the ability to just clone, compile the natives, and run rain. >> Using partial build targets sounds interesting. Let's see how it will look in the end. >> >> But for some reason I can't believe (I wish!) it takes just a few seconds for your builds. Are you only compiling java code, or does this also include the native libs in prism/glass as well? On what platform are you currently testing? > > Yes you are right, I am cheating as I haven't built the natives yet. BUT, that's because I am putting a plan in place to reuse the latest built natives (from a hudson job, for example) rather than having to recompile all the natives, so that your "typical" javaFX developer doesn't have to have a native toolchain installed, in which case the build really will only be a few seconds (by few, meaning, 17 or so I think was the last count). > > I'm on a 3yr old Mac. Thanks for clarifying that. This sounds reasonable then. -- best regards, Anthony From swpalmer at gmail.com Fri Oct 19 09:17:58 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 19 Oct 2012 12:17:58 -0400 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50816B07.9030400@oracle.com> References: <1350654952.4085.18.camel@mercury> <50816B07.9030400@oracle.com> Message-ID: <50BB792A-F13B-4D22-AA54-B63CE98B9D50@gmail.com> On 2012-10-19, at 11:00 AM, Anthony Petrov wrote: > On 10/19/2012 6:37 PM, Danno Ferrin wrote: >> What would be nice is if the snapshot builds posted the intermediaries to a >> public facing repository so that installing the naitve build chain ins not >> a requirement. IIRC you need a non-free-as-in-beer VisualC++ compiler to >> spit out windows builds. (I may be wrong as my knowledge is dated). > > JDK can be built using a free VS 2010 Express edition. I think FX can be built with this free compiler as well. > > -- > best regards, > Anthony +1 to using VS express edition. Other projects attempt to use things like MinGW or some windows-ish variation of GCC. They are all horrible on Windows. +1 to Gradle as well. Maven works okay for simple things, but anything requiring complexity leads you to pull your hair out. Maven is by-design nearly unconfigurable and awkward to tweak. Gradle is much easier to deal with when you need to configure a custom build experience. From a command-line perspective it is the clear winner. Hopefully IDE support will catch up. Our current JavaFX-based product us using Gradle to drive builds that are composed of Ant, Maven, Make, and Visual Studio projects along with invoking some custom build tools. We have a combination of Java Swing, JavaFX, and native bits on Windows, Mac and Linux. Managing it all can be "interesting" at times. Scott From david.dehaven at oracle.com Fri Oct 19 09:26:35 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 19 Oct 2012 09:26:35 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50814978.8080605@oracle.com> References: <50814978.8080605@oracle.com> Message-ID: <996E7B8F-5266-447E-B44A-F029FD78EEB0@oracle.com> >> In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. > > Building native code may be slow in general, but building e.g. Glass takes under a minute. Of course I agree that if code hasn't changed, it shouldn't be re-built. The first time, yes. Especially large modules like WebNode, GStreamer and all the JSL shaders. Subsequent builds are very fast, barring the overhead of ant itself (which is horrible, IMHO). Getting a more efficient build system in there will go a long ways. > One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)? I've suggested using subrepos but I'm not sure if those will allow doing a partial clone and building only certain modules. That's probably the only advantage of using forest (other issues with forest aside?). It would also be highly beneficial if each module could contain it's own RCS history. The problem with using a single repository is that it gets more and more bloated over time, breaking it up into smaller pieces mitigates that bloat and allows people to decide which pieces they want to spend the time pulling. It currently takes me a better part of an hour to fully clone the workspace over VPN, and I have a fairly fast connection and a dedicated VPN router. -DrD- From philip.race at oracle.com Fri Oct 19 09:31:49 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Oct 2012 09:31:49 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> References: <50814978.8080605@oracle.com> <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> <50816A7A.9020404@oracle.com> <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> Message-ID: <50818075.2030604@oracle.com> On 10/19/12 8:23 AM, Richard Bair wrote: > Yes you are right, I am cheating as I haven't built the natives yet. > BUT, that's because I am putting a plan in place to reuse the latest > built natives (from a hudson job, for example) rather than having to > recompile all the natives, so that your "typical" javaFX developer > doesn't have to have a native toolchain installed, in which case the > build really will only be a few seconds (by few, meaning, 17 or so I > think was the last count). I'm on a 3yr old Mac. Richard FWIW, remember that eventually (JDK 9?) we will need to build as *part of* the JDK build. The folks working on the new build system are (as I understand it) prefer to move away from partial builds. Eg they expect you to have the top-level repo, hotspot and the jdk repo. And builds are claimed to be so fast it doesn't matter .. Also whatever the IDE support we have for Fx builds should not be "2 build paths" for us to support. No one wants to have test both if they can help it. So really IDE support needs to be another way to 'get at' the underlying support. And I am not sure if you'll convince the build folks that maven or gradle should be a JDK build dependency. Maybe you understand how this'll all work together but its not clear to me .. perhaps "modules" can or will be separate builds with their own rules but I don't know if that fits with the apparent direction on build-infra-dev. -phil. From david.dehaven at oracle.com Fri Oct 19 09:31:50 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 19 Oct 2012 09:31:50 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50BB792A-F13B-4D22-AA54-B63CE98B9D50@gmail.com> References: <1350654952.4085.18.camel@mercury> <50816B07.9030400@oracle.com> <50BB792A-F13B-4D22-AA54-B63CE98B9D50@gmail.com> Message-ID: <0BA079E0-5BE4-4167-AEB7-0E495C626226@oracle.com> > Our current JavaFX-based product us using Gradle to drive builds that are composed of Ant, Maven, Make, and Visual Studio projects along with invoking some custom build tools. We have a combination of Java Swing, JavaFX, and native bits on Windows, Mac and Linux. Managing it all can be "interesting" at times. What about Xcode projects? Those may be needed in some cases... -DrD- From richard.bair at oracle.com Fri Oct 19 09:50:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Oct 2012 09:50:29 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <50818075.2030604@oracle.com> References: <50814978.8080605@oracle.com> <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> <50816A7A.9020404@oracle.com> <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> <50818075.2030604@oracle.com> Message-ID: <344C8DC6-7D7F-432F-B121-A3C79313F0D3@oracle.com> >> Yes you are right, I am cheating as I haven't built the natives yet. BUT, that's because I am putting a plan in place to reuse the latest built natives (from a hudson job, for example) rather than having to recompile all the natives, so that your "typical" javaFX developer doesn't have to have a native toolchain installed, in which case the build really will only be a few seconds (by few, meaning, 17 or so I think was the last count). I'm on a 3yr old Mac. Richard > > FWIW, remember that eventually (JDK 9?) we will need to build as *part of* the JDK build. > The folks working on the new build system are (as I understand it) prefer to > move away from partial builds. Eg they expect you to have the top-level repo, hotspot > and the jdk repo. And builds are claimed to be so fast it doesn't matter .. > Also whatever the IDE support we have for Fx builds should not be "2 build paths" > for us to support. No one wants to have test both if they can help it. So really > IDE support needs to be another way to 'get at' the underlying support. > And I am not sure if you'll convince the build folks that maven or gradle should > be a JDK build dependency. Maybe you understand how this'll all work together > but its not clear to me .. perhaps "modules" can or will be separate builds with their > own rules but I don't know if that fits with the apparent direction on build-infra-dev. I have thought about this, and I'm not sure how it will all go in the end. One advantage of simplifying the project tree is that changing the build system should be pretty straightforward if it ever comes to that. If we had to use make (gulp). we could even have it generate maven / gradle / whatever build scripts, as long as those were pretty simple. The last time I talked to the infra team, they had suggested "we can call anything from make" so I don't know if it will be an issue. I figure, lets do something that is awesome now, and who knows. In a year and a half maybe we'll find from experience this really is much better, and affect change on JavaSE -- much like JIRA. Richard From david.dehaven at oracle.com Fri Oct 19 09:52:08 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 19 Oct 2012 09:52:08 -0700 Subject: Do we have to fear February? In-Reply-To: References: Message-ID: <7D20937C-C40A-4A59-AE6B-9F8AC9896A55@oracle.com> > I share pretty much every single one of Robert's concerns. > It looks like come Feb 2013 I have to consider shipping my app with a bundled JDK7. > And to my customers it will probably look like the app got *worse*, they will be upset and rightly so. > > Any insights are highly appreciated. Not trying to be facetious, but one could start investigating porting to JavaFX. Ensemble is now available in the Mac App store: https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 -DrD- From sven.reimers at gmail.com Fri Oct 19 10:00:01 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 19 Oct 2012 19:00:01 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <344C8DC6-7D7F-432F-B121-A3C79313F0D3@oracle.com> References: <50814978.8080605@oracle.com> <9E72FB4C-633C-4B09-98F1-10B9CBD0C1B3@oracle.com> <50816A7A.9020404@oracle.com> <77B5FBDA-6F35-4FB5-ADE3-2F59A6EBDF98@oracle.com> <50818075.2030604@oracle.com> <344C8DC6-7D7F-432F-B121-A3C79313F0D3@oracle.com> Message-ID: +1 Sven On Fri, Oct 19, 2012 at 6:50 PM, Richard Bair wrote: >>> Yes you are right, I am cheating as I haven't built the natives yet. BUT, that's because I am putting a plan in place to reuse the latest built natives (from a hudson job, for example) rather than having to recompile all the natives, so that your "typical" javaFX developer doesn't have to have a native toolchain installed, in which case the build really will only be a few seconds (by few, meaning, 17 or so I think was the last count). I'm on a 3yr old Mac. Richard >> >> FWIW, remember that eventually (JDK 9?) we will need to build as *part of* the JDK build. >> The folks working on the new build system are (as I understand it) prefer to >> move away from partial builds. Eg they expect you to have the top-level repo, hotspot >> and the jdk repo. And builds are claimed to be so fast it doesn't matter .. >> Also whatever the IDE support we have for Fx builds should not be "2 build paths" >> for us to support. No one wants to have test both if they can help it. So really >> IDE support needs to be another way to 'get at' the underlying support. >> And I am not sure if you'll convince the build folks that maven or gradle should >> be a JDK build dependency. Maybe you understand how this'll all work together >> but its not clear to me .. perhaps "modules" can or will be separate builds with their >> own rules but I don't know if that fits with the apparent direction on build-infra-dev. > > I have thought about this, and I'm not sure how it will all go in the end. One advantage of simplifying the project tree is that changing the build system should be pretty straightforward if it ever comes to that. If we had to use make (gulp). we could even have it generate maven / gradle / whatever build scripts, as long as those were pretty simple. The last time I talked to the infra team, they had suggested "we can call anything from make" so I don't know if it will be an issue. > > I figure, lets do something that is awesome now, and who knows. In a year and a half maybe we'll find from experience this really is much better, and affect change on JavaSE -- much like JIRA. > > Richard -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From richard.bair at oracle.com Fri Oct 19 10:05:30 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Oct 2012 10:05:30 -0700 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> Message-ID: > I did not have time to look at the Skin and Behavior paradigms yet, so I > can't speak to the impact on them. I will try to brush up on those this > weekend. However, if this subclassing to delegate becomes relatively > common, then it seems that whatever Skin and Behavior issues might arise > would still need to be addressed. However now they would need to be > addressed by application designers instead of by the platform. In general, I'm not a fan of subclass to delegate (AWT required subclassing for all event handling. Whoops!). The question in this case however is, what are the use cases and what is the best way to expose support for those such that the API is consistent and doesn't have any odd corners or gotchas. Sometimes the only way to expose the required functionality is to create such gotchas. Other times we can do something simpler, although more constraining, that covers 95% of the usages, and then subclassing allows power users to squeeze out the extra 5%. So for example, I would expect people would prefer to have a SearchField, DateField, MoneyField, and TextField with a maxLength property, rather than having to use callbacks or having to configure a TextField with all the right properties. It is easier to pick a DateField from a palette and just use it than it is to setup custom Content or even using off-the-shelf Content but having to plug it into a TextField (since doing this requires a little more thought and understanding of the architecture). On the other hand, being able to plug in the content is more natural than having to subclass in order to plug in the content. My feeling on it has been, we ought to add (or JFXtras, or JIDE ought to add) SearchField, MoneyField, etc as Controls and we ought to give TextField a maxLength, and we ought to have a more general purpose FormattedTextField. Of course, that doesn't help address some of the other odd use cases like an all-caps field, so the question is, for such a use case, is it better to: a) Add some callbacks to all TextInputControl's that let you filter / modify changes to the text or b) Allow Content to be replaced or c) Restrict such features to sub classes Of these, my feeling was that (a) was the most useful in connection with built-in DateField, MoneyField, etc. I worry that by making Content mutable, we make it very easy for people to naively replace the Content with their own, rather than wrapping the existing Content, and thus adding bugs into their software such as what happens when you paste a \n into a TextField. That just isn't one of those things that people think about the first time around. That's why I liked (a) better, where Content was basically under the control of the Text control implementation, but developers had an easy way to insert code into the process and filter / reject / etc changes to the Content model. Richard From philip.race at oracle.com Fri Oct 19 10:33:15 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Oct 2012 10:33:15 -0700 Subject: Do we have to fear February? In-Reply-To: <7D20937C-C40A-4A59-AE6B-9F8AC9896A55@oracle.com> References: <7D20937C-C40A-4A59-AE6B-9F8AC9896A55@oracle.com> Message-ID: <50818EDB.10006@oracle.com> David, I'm not sure what you are replying to since I don't appear to have any emails in this thread so I am guessing its something about Apple EOL'ing their JDK 6 and the need to bundle a JRE in future. I don't see how using JavaFX makes that any different (better or worse), since I'd be pretty sure that Scott bundled a JRE runtime to run Ensemble. Its a 61Mb download :-). [But large app store downloads are not that unusual.] -phil. On 10/19/2012 9:52 AM, David DeHaven wrote: >> I share pretty much every single one of Robert's concerns. >> It looks like come Feb 2013 I have to consider shipping my app with a bundled JDK7. >> And to my customers it will probably look like the app got *worse*, they will be upset and rightly so. >> >> Any insights are highly appreciated. > > Not trying to be facetious, but one could start investigating porting to JavaFX. > > Ensemble is now available in the Mac App store: > https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 > > -DrD- > From david.dehaven at oracle.com Fri Oct 19 10:46:00 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 19 Oct 2012 10:46:00 -0700 Subject: Do we have to fear February? In-Reply-To: <50818EDB.10006@oracle.com> References: <7D20937C-C40A-4A59-AE6B-9F8AC9896A55@oracle.com> <50818EDB.10006@oracle.com> Message-ID: <9087B332-15BA-441E-A282-C13B2165478A@oracle.com> Ignore that? I replied to the wrong list :) -Dr "list heavy" D- > David, > > I'm not sure what you are replying to since I don't appear to have > any emails in this thread so I am guessing its something about > Apple EOL'ing their JDK 6 and the need to bundle a JRE in future. > > I don't see how using JavaFX makes that any different (better or worse), > since I'd be pretty sure that Scott bundled a JRE runtime to run Ensemble. > Its a 61Mb download :-). [But large app store downloads are not that unusual.] > > -phil. > > On 10/19/2012 9:52 AM, David DeHaven wrote: >>> I share pretty much every single one of Robert's concerns. >>> It looks like come Feb 2013 I have to consider shipping my app with a bundled JDK7. >>> And to my customers it will probably look like the app got *worse*, they will be upset and rightly so. >>> >>> Any insights are highly appreciated. >> >> Not trying to be facetious, but one could start investigating porting to JavaFX. >> >> Ensemble is now available in the Mac App store: >> https://itunes.apple.com/us/app/ensemble/id557744983?mt=12 >> >> -DrD- >> > From philip.race at oracle.com Fri Oct 19 11:07:55 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Oct 2012 11:07:55 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <996E7B8F-5266-447E-B44A-F029FD78EEB0@oracle.com> References: <50814978.8080605@oracle.com> <996E7B8F-5266-447E-B44A-F029FD78EEB0@oracle.com> Message-ID: <508196FB.8000806@oracle.com> On 10/19/2012 9:26 AM, David DeHaven wrote: > > I've suggested using subrepos but I'm not sure if those will allow doing a partial clone and building only certain modules. That's probably the only advantage of using forest (other issues with forest aside?). It would also be highly beneficial if each module could contain it's own RCS history. The problem with using a single repository is that it gets more and more bloated over time, breaking it up into smaller pieces mitigates that bloat and allows people to decide which pieces they want to spend the time pulling. It currently takes me a better part of an hour to fully clone the workspace over VPN, and I have a fairly fast connection and a dedicated VPN router. > > -DrD- > In the JDK, sub-repos have been suggested several times, but presented some problems .. I think one of which was difficulty in maintaining open and closed. The upshot was that sub-repos were rejected each time it came up. -phil. From felipe.heidrich at oracle.com Fri Oct 19 11:23:07 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Fri, 19 Oct 2012 11:23:07 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <1350654952.4085.18.camel@mercury> Message-ID: <39772FAC-3E4D-4585-97D8-8738198277A5@oracle.com> > > > Gradle can also spit out Eclipse projects and Idea projects. That is what > I use personally. Since eclipse projects are fairly universal any IDE that > people may want to hack in can ingest that. (JDeveloper?) > > This make sense to me http://gradle.org/docs/current/userguide/eclipse_plugin.html I like the idea that the source in the repo is IDE neutral. Right now Steve and I make sure the eclipse related files are in good shape, but every time something changes in the repo these files get broken. Btw, I can see Tom adding e(fx)clips behavior to the plugin so I can get all the e(fx)clipse sweetness in my IDE. Felipe From mcdonnell.john at gmail.com Fri Oct 19 11:51:51 2012 From: mcdonnell.john at gmail.com (John McDonnell) Date: Fri, 19 Oct 2012 19:51:51 +0100 Subject: setOnDragDropped Message-ID: Any change someone can point out the errors of my ways, when trying to drop a node on another one? I have simplified my code so I can show you a sample of my problem[1]. The sample shows 2 labels. One that can be dragged, and another that is just there to allow the dragged label to be dropped on. In my sample when I drag the draggable node it works as expected, I even can detected that the dragged label is dragged over the other label listening on the onDragOver property of the second label. But when ever I try to attach a listener to either label to detect when the label has been dropped I am not getting any thing printed in the console. Should the DragDropped event listener be added to the draggable label? should the DragDropped event be fired when the mouse button is release of the dragged label right? [1] Sample code: public class DropTests extends Application { @Override public void start(Stage primaryStage) { final HBox root = new HBox(); root.setSpacing(25.0d); Label lblDraggable = new Label(); lblDraggable.setText("'Drag me'"); lblDraggable.setOnDragDetected(new EventHandler() { @Override public void handle(MouseEvent event) { System.out.println("Drag Detected"); Dragboard db = root.startDragAndDrop(TransferMode.ANY); /* Put a string on a dragboard */ ClipboardContent content = new ClipboardContent(); content.putString("Label Being Dragged."); db.setContent(content); event.consume(); } }); Label lblDragOver = new Label(); lblDragOver.setText("Drag over Me"); lblDragOver.setOnDragOver(new EventHandler() { @Override public void handle(DragEvent t) { System.out.println("Drag Over."); t.consume(); } }); lblDragOver.setOnDragDropped(new EventHandler() { @Override public void handle(DragEvent t) { System.out.println("Drag DROPPED"); t.consume(); } }); root.getChildren().add(lblDragOver); root.getChildren().add(lblDraggable); Scene scene = new Scene(root, 300, 250); primaryStage.setTitle("Dragging Tests"); primaryStage.setScene(scene); primaryStage.show(); } -- John From markclaassenx at gmail.com Fri Oct 19 11:55:09 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Fri, 19 Oct 2012 14:55:09 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> Message-ID: > Add some callbacks to all TextInputControl's that let you filter / modify changes I agree with lots of what you said. However, the callback stuff scares me a bit. With the current implementation of only filters, things like the date field will not be done be most developers (if the alternative is to write their own control). To ensure the necessary flexibility, one needs to almost re-invent the Content interface, but have it called something else. It seems that your main concern with my previous suggestion was giving a developer too much of an opportunity to shoot themselves in the foot. And I agree that if someone doesn't extend from a well created implementation, this is bound to happen. Would you consider having a setContent(TextFieldDocument doc) method in TextField? The length() method and the get(int, int) method could be final, making it necessary to call super.insert() or super.delete() to get anything done. This would provide the flexibility (likely all the flexibility) and yet would prevent a developer from making a fairly large set of mistakes. Mark On Fri, Oct 19, 2012 at 1:05 PM, Richard Bair wrote: > > I did not have time to look at the Skin and Behavior paradigms yet, so I > > can't speak to the impact on them. I will try to brush up on those this > > weekend. However, if this subclassing to delegate becomes relatively > > common, then it seems that whatever Skin and Behavior issues might arise > > would still need to be addressed. However now they would need to be > > addressed by application designers instead of by the platform. > > In general, I'm not a fan of subclass to delegate (AWT required > subclassing for all event handling. Whoops!). The question in this case > however is, what are the use cases and what is the best way to expose > support for those such that the API is consistent and doesn't have any odd > corners or gotchas. Sometimes the only way to expose the required > functionality is to create such gotchas. Other times we can do something > simpler, although more constraining, that covers 95% of the usages, and > then subclassing allows power users to squeeze out the extra 5%. > > So for example, I would expect people would prefer to have a SearchField, > DateField, MoneyField, and TextField with a maxLength property, rather than > having to use callbacks or having to configure a TextField with all the > right properties. It is easier to pick a DateField from a palette and just > use it than it is to setup custom Content or even using off-the-shelf > Content but having to plug it into a TextField (since doing this requires a > little more thought and understanding of the architecture). On the other > hand, being able to plug in the content is more natural than having to > subclass in order to plug in the content. > > My feeling on it has been, we ought to add (or JFXtras, or JIDE ought to > add) SearchField, MoneyField, etc as Controls and we ought to give > TextField a maxLength, and we ought to have a more general purpose > FormattedTextField. Of course, that doesn't help address some of the other > odd use cases like an all-caps field, so the question is, for such a use > case, is it better to: > > a) Add some callbacks to all TextInputControl's that let you > filter / modify changes to the text or > b) Allow Content to be replaced or > c) Restrict such features to sub classes > > Of these, my feeling was that (a) was the most useful in connection with > built-in DateField, MoneyField, etc. I worry that by making Content > mutable, we make it very easy for people to naively replace the Content > with their own, rather than wrapping the existing Content, and thus adding > bugs into their software such as what happens when you paste a \n into a > TextField. That just isn't one of those things that people think about the > first time around. That's why I liked (a) better, where Content was > basically under the control of the Text control implementation, but > developers had an easy way to insert code into the process and filter / > reject / etc changes to the Content model. > > Richard From chien.yang at oracle.com Fri Oct 19 12:05:35 2012 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 19 Oct 2012 12:05:35 -0700 Subject: Initial Draft of 3D API For Version 8 is Ready For Review Message-ID: <5081A47F.80304@oracle.com> Hi all, Thank you all for the feedback to 3D features for JavaFX 8. We now have an initial 3D API ready for the community to review. Proposed API: https://wikis.oracle.com/display/OpenJDK/Proposed+API Note: I can't find a good way to present the 3D API (javadoc) at Oracle's Wikis so I have attached a gzip copy (~400 kB) to the associated JIRA. Proposed 3D Features: https://wikis.oracle.com/display/OpenJDK/3D+Features Please let us know if you have any suggestions or concerns. Regards, - Chien Yang JavaFX Graphics Team From tom.schindl at bestsolution.at Fri Oct 19 13:06:04 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 19 Oct 2012 22:06:04 +0200 Subject: SWT build dependency In-Reply-To: <508167CE.8090004@oracle.com> References: <15498258-EB9E-4C09-A2C0-A98B6DA06D2D@oracle.com> <5080976C.3050908@bestsolution.at> <50815E13.60802@bestsolution.at> <50816399.1030301@oracle.com> <508166A4.3060808@bestsolution.at> <508167CE.8090004@oracle.com> Message-ID: <5081B2AC.4030209@bestsolution.at> Well who says it has to be in the SWT project? If there's a project let's name it "eclipsefx" (and Oracle is part of the project team at least to maintain the SWT-Bridge code) which holds tooling and runtime it could be part of this project and by default a) & b) would be provided because all projects at a eclipse provide stuff with OSGi-Meta-Data and a p2 repository to consume the bits. Tom Am 19.10.12 16:46, schrieb steve.x.northover at oracle.com: > Sure, but if the bridge is part of SWT and joins that code base (like > the Swing bridge), then it gets released with SWT. > > Steve > > On 19/10/2012 10:41 AM, Tom Schindl wrote: >> Am 19.10.12 16:28, schrieb steve.x.northover at oracle.com: >>> .. the reply in private was an accident. Thanks for forwarding back to >>> the list. >>> >>> I'm not against contributing the code to Eclipse.org and having it in >>> SWT, just like the Swing bridge. There are a few arguments against >>> this. The code uses objects and frameworks that are not yet open >>> source. It is easier to keep the code up to date when FX changes and >>> ensure that interop works from day one when FX ships rather than >>> aligning with an Eclipse release. >>> >> (I assume most people consume SWT along with Eclipse-RCP in an OSGi-Env) >> >> For people to easily consume those in their RCP application the >> following would be ideal: >> a) the jar has the OSGi-Manifest headers >> b) the OSGi-Bundle is part of the p2 repository >> >> To align it with FX rather than SWT I guess this would be possible at >> the moment someone proposes an JavaFX-Project at Eclipse.org ;-) and >> Oracles contribution to it is the SWT-FX-Bridge. >> >> The project then aligns its release schedule to the one of FX beside >> following the Eclipse-Release-train. >> >> Tom >> >> -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From swpalmer at gmail.com Fri Oct 19 13:23:34 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 19 Oct 2012 16:23:34 -0400 Subject: Lombard? Presidio? In-Reply-To: References: <48E5B103-C29D-4249-8BA1-178395964CDA@oracle.com> <19D2C243-8C77-4745-85A8-D6E7BA7454E2@gmail.com> Message-ID: That is a fault of dropping all the fields in the version numbers that we used to have. Given this number: 1.7.0_09 You would think it would be possible to use more than just the last part :-) If you were working on 1.7.1 then all the security updates you want could be released for 1.7.0 without causing any problems to the scheduled release numbering. It would also be clear what was a "security uber-fix" and what was part of the regular development cycle. This is what happens when marketing people are allowed to pick numbers. I would propose changing the version number reported for Java 8 to 8.0.0 but somebody will fight it I'm sure :-) Scott On 2012-10-19, at 10:19 AM, Richard Bair wrote: > Yes, you are right, and when some security uber-fix comes along due to some ravaging exploit and we have to bump all the version numbers -- in such cases you really wish you didn't have version numbers. At least for the update releases. > > Richard > > On Oct 19, 2012, at 5:11 AM, Weiqi Gao wrote: > >> The problem with version numbers is that you never know exactly which version you are working on until you are about to release. Just make sure people who needs to know the mapping from code names to actual version numbers know about them. A couple lines of explanation in the project's front page will do fine. >> >> -- >> Weiqi >> >> On Oct 19, 2012, at 2:48 AM, Richard Bair wrote: >> >>> I've wondered why we don't rename Lombard to 8.0 in JIRA, since that's what it is. Presidio was 2.0, wasn't it? Gosh, I should go to bed. From here out I think we're sticking with version numbers. I'll ask Brian Beck (Brian, are you there?) what the story on that is. >>> >>> Richard >>> >>> On Oct 18, 2012, at 5:22 PM, Mark Fortner wrote: >>> >>>> Could somebody add a note in the description of the Lombard & Presidio >>>> releases in JIRA that explains how these code names map to the current >>>> JavaFX version numbers? I think there was some discussion earlier about >>>> this. If the description's in JIRA at least it will be easier to set >>>> expectations. >>>> >>>> Cheers, >>>> >>>> Mark >>> >> > From pavel.safrata at oracle.com Fri Oct 19 13:41:02 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Fri, 19 Oct 2012 22:41:02 +0200 Subject: setOnDragDropped In-Reply-To: References: Message-ID: <5081BADE.9050505@oracle.com> Hello John, your drop target node has to tell to the system that it is a drop target. In the OnDragOver handler you need to do something like | Dragboard db = event.getDragboard(); if (db.hasString()) { event.acceptTransferModes(TransferMode.COPY_OR_MOVE); } | The acceptTransferModes call tells to the system that your node is a potential drop target for the dragged data. This enables the drop event for your node (and also, at least on Windows, switches the cursor from the "stop" sign to the "copy", "move" or "link" sign). Please refer to the DragEvent's javadoc, the proper usage is described there, including example code snippets. Regards, Pavel On 19.10.2012 20:51, John McDonnell wrote: > Any change someone can point out the errors of my ways, when trying to drop > a node on another one? > > > I have simplified my code so I can show you a sample of my problem[1]. The > sample shows 2 labels. One that can be dragged, and another that is just > there to allow the dragged label to be dropped on. > > In my sample when I drag the draggable node it works as expected, I even > can detected that the dragged label is dragged over the other label > listening on the onDragOver property of the second label. > > But when ever I try to attach a listener to either label to detect when the > label has been dropped I am not getting any thing printed in the console. > Should the DragDropped event listener be added to the draggable label? > should the DragDropped event be fired when the mouse button is release of > the dragged label right? > > [1] Sample code: > public class DropTests extends Application > { > @Override > public void start(Stage primaryStage) > { > final HBox root = new HBox(); > root.setSpacing(25.0d); > > Label lblDraggable = new Label(); > lblDraggable.setText("'Drag me'"); > lblDraggable.setOnDragDetected(new EventHandler() > { > @Override > public void handle(MouseEvent event) > { > System.out.println("Drag Detected"); > Dragboard db = root.startDragAndDrop(TransferMode.ANY); > > /* Put a string on a dragboard */ > ClipboardContent content = new ClipboardContent(); > content.putString("Label Being Dragged."); > db.setContent(content); > > event.consume(); > } > }); > > Label lblDragOver = new Label(); > > lblDragOver.setText("Drag over Me"); > lblDragOver.setOnDragOver(new EventHandler() { > > @Override > public void handle(DragEvent t) > { > System.out.println("Drag Over."); > t.consume(); > } > }); > > lblDragOver.setOnDragDropped(new EventHandler() { > > @Override > public void handle(DragEvent t) > { > System.out.println("Drag DROPPED"); > t.consume(); > } > }); > > root.getChildren().add(lblDragOver); > root.getChildren().add(lblDraggable); > Scene scene = new Scene(root, 300, 250); > > primaryStage.setTitle("Dragging Tests"); > primaryStage.setScene(scene); > primaryStage.show(); > } > From neugens.limasoftware at gmail.com Fri Oct 19 16:30:08 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 20 Oct 2012 01:30:08 +0200 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <39772FAC-3E4D-4585-97D8-8738198277A5@oracle.com> References: <1350654952.4085.18.camel@mercury> <39772FAC-3E4D-4585-97D8-8738198277A5@oracle.com> Message-ID: 2012/10/19 Felipe Heidrich : >> >> >> Gradle can also spit out Eclipse projects and Idea projects. That is what >> I use personally. Since eclipse projects are fairly universal any IDE that >> people may want to hack in can ingest that. (JDeveloper?) >> >> > > This make sense to me > http://gradle.org/docs/current/userguide/eclipse_plugin.html > I like the idea that the source in the repo is IDE neutral. > > Right now Steve and I make sure the eclipse related files are in good shape, but every time something changes in the repo these files get broken. > > Btw, I can see Tom adding e(fx)clips behavior to the plugin so I can get all the e(fx)clipse sweetness in my IDE. > > Felipe > I don't personally like much the idea of keeping around IDE generated projects files in the repository to be honest. I rather prefer if the IDE is smart enough to figure the setup from the tool dedicated to the build (like Eclipse, IDEA and Netbeans do with Maven and C/C++ projects for example). Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From swpalmer at gmail.com Sat Oct 20 06:10:05 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 20 Oct 2012 09:10:05 -0400 Subject: Memory Leaks Message-ID: Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? In my application I add and remove style classes to highlight objects in the scene graph that are in various states (selected, active, disabled, etc). It seems that every time the style class list is changed that there is a small leak. Since while the app runs and process data (a process that may run indefinitely) the state of objects in the graph changes as data is processed, this is a significant issue. Our customers may have the app fail after several hours or a few days because of these leaks. Scott From phidias51 at gmail.com Sat Oct 20 09:58:25 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Sat, 20 Oct 2012 09:58:25 -0700 Subject: Icon Theme Support Message-ID: I was wondering if anyone had given any thought to supporting Icon Themes in JavaFX? When you look at Swing apps (and now JavaFX apps) you find a lot of the same icons borrowed from various Linux icon themes. Invariably someone has taken apart the theme's archive, and extracted the icons that they wanted and simply added them as resources to their project. However, that misses some of advantages of having a theme in the first place -- namely that if you use the standard naming conventions for icons, then you should be able to do drop-in replacements of the icons without having to change your code. This makes is possible to freshen up the look of your app, or to use icon themes that fit a specific OS. After all, do you really want Tango icons on your nice clean OS X app? Moreover, it would make it possible for user's to customize the look of their apps without developer involvement. Which brings me rather circuitously back to my point -- is there a way to support icon themes in CSS? For example, I'd like to simply drop * AwOken.tar.gz* into my classpath, and have an icon reference like this resolve properly: *-fx-image: url('clear/24x24/apps/ubuntuone-client.png');* * * Ideally, this should happen without having to repackage the icon themes into a JAR since themes are often stored in a variety of formats tar.gz, rar, zip, etc. Cheers, Mark From goddard at seznam.cz Sat Oct 20 10:46:41 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sat, 20 Oct 2012 19:46:41 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Initial=20Draft=20of=203D=20API=20For=20Version=208=20is=20Ready=20For=20Review?= In-Reply-To: <5081A47F.80304@oracle.com> Message-ID: <136777.14610.50343-10989-1144462420-1350755198@seznam.cz> Thanks a lot! :) Jiri ------------ P?vodn? zpr?va ------------ Od: Chien Yang P?edm?t: Initial Draft of 3D API For Version 8 is Ready For Review Datum: 19.10.2012 21:14:57 ---------------------------------------- Hi all, Thank you all for the feedback to 3D features for JavaFX 8. We now have an initial 3D API ready for the community to review. Proposed API: https://wikis.oracle.com/display/OpenJDK/Proposed+API Note: I can't find a good way to present the 3D API (javadoc) at Oracle's Wikis so I have attached a gzip copy (~400 kB) to the associated JIRA. Proposed 3D Features: https://wikis.oracle.com/display/OpenJDK/3D+Features Please let us know if you have any suggestions or concerns. Regards, - Chien Yang JavaFX Graphics Team From jonathan.giles at oracle.com Sat Oct 20 14:16:00 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 21 Oct 2012 10:16:00 +1300 Subject: Memory Leaks In-Reply-To: References: Message-ID: <50831490.2030007@oracle.com> David Grieve is the go-to expert on all things CSS, but from a higher-level perspective the general answer is always: you tell us! :-) There might be a leak we don't know about, or can't easily reproduce, and you might have just the information we need to finally get rid of that annoying leak you mention. So, please, file Jira bugs on us and we'll get to looking at them as soon as possible. If you can provide a reproducible test case that would be hugely appreciated too. Finally, from our point of view JavaFX 2.2.3 is rather old code - we've been actively developing in the 8.0 branch for quite a long time now, and one of our primary focuses during this time has been performance (CPU and memory). In other words, there is a chance it may already be resolved (or minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 builds available that you can test with. If you have the time and inclination, it might be worth testing against these builds to see if it is resolved. Thanks, -- Jonathan On 21/10/2012 2:10 a.m., Scott Palmer wrote: > Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? > In my application I add and remove style classes to highlight objects in the scene graph that are in various states (selected, active, disabled, etc). It seems that every time the style class list is changed that there is a small leak. Since while the app runs and process data (a process that may run indefinitely) the state of objects in the graph changes as data is processed, this is a significant issue. Our customers may have the app fail after several hours or a few days because of these leaks. > > Scott From swpalmer at gmail.com Sat Oct 20 15:01:39 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 20 Oct 2012 18:01:39 -0400 Subject: Memory Leaks In-Reply-To: <50831490.2030007@oracle.com> References: <50831490.2030007@oracle.com> Message-ID: Thanks for the response. 8.0 is too far away. I need to ship my app in a few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 yesterday. We were on 7u7 and then I discovered that there was a new JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too long ago with 2.2.0 and I didn't see any sort of announcements that there was anything newer. I will try to isolate the leak. We think we are seeing com.sun.javafx.css.StyleHelper$CacheEntry and com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least). jvisualvm shows the number of those objects are always growing. Comparing heap dumps we have never observed the number to decrease. I'm currently only able to connect to the machine running my test via Remote Desktop, and the screen saver probably keep kicking in, I think that is affecting the test. Is JavaFX smart enough to not render when the screen is blanked? I will try to produce a test case. But if anyone has knowledge about this that wants to share, any info is appreciated. Thanks,, Scott On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles wrote: > David Grieve is the go-to expert on all things CSS, but from a > higher-level perspective the general answer is always: you tell us! :-) > There might be a leak we don't know about, or can't easily reproduce, and > you might have just the information we need to finally get rid of that > annoying leak you mention. > > So, please, file Jira bugs on us and we'll get to looking at them as soon > as possible. If you can provide a reproducible test case that would be > hugely appreciated too. > > Finally, from our point of view JavaFX 2.2.3 is rather old code - we've > been actively developing in the 8.0 branch for quite a long time now, and > one of our primary focuses during this time has been performance (CPU and > memory). In other words, there is a chance it may already be resolved (or > minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 > builds available that you can test with. If you have the time and > inclination, it might be worth testing against these builds to see if it is > resolved. > > Thanks, > -- Jonathan > > > On 21/10/2012 2:10 a.m., Scott Palmer wrote: > >> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? >> In my application I add and remove style classes to highlight objects in >> the scene graph that are in various states (selected, active, disabled, >> etc). It seems that every time the style class list is changed that there >> is a small leak. Since while the app runs and process data (a process that >> may run indefinitely) the state of objects in the graph changes as data is >> processed, this is a significant issue. Our customers may have the app >> fail after several hours or a few days because of these leaks. >> >> Scott >> > > From jonathan.giles at oracle.com Sat Oct 20 19:36:59 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 21 Oct 2012 15:36:59 +1300 Subject: Icon Theme Support In-Reply-To: References: Message-ID: <50835FCB.90703@oracle.com> I'm interested to hear if this is common practice. In one of my past lives as a Swing client application developer I would always cherry pick the icons I wanted to use out of the icon packs I had available to me, rather than try to ship an entire icon pack (or multiple icon packs). From my experience icon packs tend to be rather large (when taking into account they normally ship with some permutation of 16x16, 24x24, 32x32, 48x48, 64x64 pixel .png, .svg and .ico files). So, in short, is shipping an entire, or multiple, icon packs something that people actually want to do, and if so, would some kind of library support for this be beneficial? As a secondary question / comment: this seems like something that a third party library could offer - rather than being necessarily included in JavaFX itself? -- Jonathan On 21/10/2012 5:58 a.m., Mark Fortner wrote: > I was wondering if anyone had given any thought to supporting Icon Themes > in JavaFX? When you look at Swing apps (and now JavaFX apps) you find a > lot of the same icons borrowed from various Linux icon themes. Invariably > someone has taken apart the theme's archive, and extracted the icons that > they wanted and simply added them as resources to their project. However, > that misses some of advantages of having a theme in the first place -- > namely that if you use the standard naming conventions for icons, then you > should be able to do drop-in replacements of the icons without having to > change your code. This makes is possible to freshen up the look of your > app, or to use icon themes that fit a specific OS. After all, do you > really want Tango icons on your nice clean OS X app? Moreover, it would > make it possible for user's to customize the look of their apps without > developer involvement. > > Which brings me rather circuitously back to my point -- is there a way to > support icon themes in CSS? For example, I'd like to simply drop * > AwOken.tar.gz* into my classpath, and have an icon reference like this > resolve properly: *-fx-image: url('clear/24x24/apps/ubuntuone-client.png');* > * > * > Ideally, this should happen without having to repackage the icon themes > into a JAR since themes are often stored in a variety of formats tar.gz, > rar, zip, etc. > > > Cheers, > > Mark From jonathan.giles at oracle.com Sat Oct 20 20:30:20 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 21 Oct 2012 16:30:20 +1300 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> Message-ID: <50836C4C.6050407@oracle.com> I'm coming into this discussion really late, but I've been sick, so that's my excuse, and I'm sticking to it :-) Firstly, regarding the options Richard sets out below, my strong preference is for option a (introduce a callback). It seems that it supports the use cases that have been raised, and it does so without introducing concerns around having a mutable Content. I think I would only sway from this position if there is a use case that just can't be done with this approach (which I'm totally willing to do if someone has one). Secondly, Richard mentions an important point here: one of the things that has been on the controls team backlog for way too long is support for a FormattedTextField control, and important subclasses thereof (e.g. Date/Time, Money, Zip code, etc). An ideal situation would be (in my humble opinion) for JavaFX to ship with FormattedTextField and the most critical subclasses, and for 3rd party projects such as JFXtras / JIDE to bring out all the rest. This approach of shipping 'simple' controls is what we did with Button / Hyperlink and RadioButton / ToggleButton - in many cases the difference in code between these classes is minimal, but it allows for way better discoverability of controls and functionality - rather than having an uber control with miles of API to toggle state / features. This approach works well, and it also looks great on our 'number of controls' fact sheet :-) Zooming out even further, we need to expand this discussion in one very important way: validation support. I don't have an answer for validation yet (it is certainly not a JavaFX 8.0 feature), but we have to keep it in the back of our minds lest we regret it later (ah, the joys of API development!). Finally, FormattedTextField is _not_ planned for JavaFX 8.0. However, I would love to have someone submit a FormattedTextField control via OpenJFX. I am more than happy to work with anyone interested in doing so, and from my perspective this would seem to be an easy control to develop - so it would be ideal for someone to get up to speed with JavaFX controls development. If anyone is interested please join the discussion and let me know. Thanks, -- Jonathan On 20/10/2012 6:05 a.m., Richard Bair wrote: >> I did not have time to look at the Skin and Behavior paradigms yet, so I >> can't speak to the impact on them. I will try to brush up on those this >> weekend. However, if this subclassing to delegate becomes relatively >> common, then it seems that whatever Skin and Behavior issues might arise >> would still need to be addressed. However now they would need to be >> addressed by application designers instead of by the platform. > In general, I'm not a fan of subclass to delegate (AWT required subclassing for all event handling. Whoops!). The question in this case however is, what are the use cases and what is the best way to expose support for those such that the API is consistent and doesn't have any odd corners or gotchas. Sometimes the only way to expose the required functionality is to create such gotchas. Other times we can do something simpler, although more constraining, that covers 95% of the usages, and then subclassing allows power users to squeeze out the extra 5%. > > So for example, I would expect people would prefer to have a SearchField, DateField, MoneyField, and TextField with a maxLength property, rather than having to use callbacks or having to configure a TextField with all the right properties. It is easier to pick a DateField from a palette and just use it than it is to setup custom Content or even using off-the-shelf Content but having to plug it into a TextField (since doing this requires a little more thought and understanding of the architecture). On the other hand, being able to plug in the content is more natural than having to subclass in order to plug in the content. > > My feeling on it has been, we ought to add (or JFXtras, or JIDE ought to add) SearchField, MoneyField, etc as Controls and we ought to give TextField a maxLength, and we ought to have a more general purpose FormattedTextField. Of course, that doesn't help address some of the other odd use cases like an all-caps field, so the question is, for such a use case, is it better to: > > a) Add some callbacks to all TextInputControl's that let you filter / modify changes to the text or > b) Allow Content to be replaced or > c) Restrict such features to sub classes > > Of these, my feeling was that (a) was the most useful in connection with built-in DateField, MoneyField, etc. I worry that by making Content mutable, we make it very easy for people to naively replace the Content with their own, rather than wrapping the existing Content, and thus adding bugs into their software such as what happens when you paste a \n into a TextField. That just isn't one of those things that people think about the first time around. That's why I liked (a) better, where Content was basically under the control of the Text control implementation, but developers had an easy way to insert code into the process and filter / reject / etc changes to the Content model. > > Richard From zonski at gmail.com Sat Oct 20 21:30:54 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 21 Oct 2012 15:30:54 +1100 Subject: JavaFX Maven Plugin Message-ID: I have tidied up, and open sourced my JavaFX Maven plugin enough that it builds executable JARs (equivalent to the fx:jar ant task) and native bundles (equivalent to a subset of fx:deploy ant task): https://github.com/zonski/javafx-maven-plugin I was waiting for the bootclasspath issue to get resolved to fix this up properly, but since I'm getting further and further away from JFX I figured better to tidy it up and hand it over to the community. It does work perfectly well enough that you can use it to build real distributables of your app via Maven. However it wraps only the basic JavaFX plugin features (i.e. you can't customise many of the settings), does not support Applets (dead anyway) or JNLP (I've never had success getting JNLP to actually work with JFX). It likely also has some platform specific bugs and problems, since I have tested only on Windows and building MSI's. It would be relatively trivial (but time consuming) to extend it further. The code is simple but inelegant. Great improvements could be made if the JFX deployment team were to make some minor changes to their packaging API to make it easier to integrate with. And massive clean-ups could be made if they put their tools JAR in a Maven repo that they maintained. I don't have any intention to develop this further or maintain it. It is a good base but it would be up to someone from the community to do this if they want it to do anything more than it does. Note this plugin is to address the packaging/assembly issue. It does NOT solve the getting-jfx-on-the-classpath-issue. You still need to do whatever workaround you're doing now on that front. From zonski at gmail.com Sat Oct 20 21:37:52 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 21 Oct 2012 15:37:52 +1100 Subject: Icon Theme Support In-Reply-To: <50835FCB.90703@oracle.com> References: <50835FCB.90703@oracle.com> Message-ID: Extending JFX CSS to support features similar to Less might be another way to solve this, or provide features that a third party library could build this on top of: http://lesscss.org/ On Sun, Oct 21, 2012 at 1:36 PM, Jonathan Giles wrote: > I'm interested to hear if this is common practice. In one of my past lives > as a Swing client application developer I would always cherry pick the > icons I wanted to use out of the icon packs I had available to me, rather > than try to ship an entire icon pack (or multiple icon packs). From my > experience icon packs tend to be rather large (when taking into account > they normally ship with some permutation of 16x16, 24x24, 32x32, 48x48, > 64x64 pixel .png, .svg and .ico files). > > So, in short, is shipping an entire, or multiple, icon packs something > that people actually want to do, and if so, would some kind of library > support for this be beneficial? > > As a secondary question / comment: this seems like something that a third > party library could offer - rather than being necessarily included in > JavaFX itself? > > -- Jonathan > > > On 21/10/2012 5:58 a.m., Mark Fortner wrote: > >> I was wondering if anyone had given any thought to supporting Icon Themes >> in JavaFX? When you look at Swing apps (and now JavaFX apps) you find a >> lot of the same icons borrowed from various Linux icon themes. Invariably >> someone has taken apart the theme's archive, and extracted the icons that >> they wanted and simply added them as resources to their project. However, >> that misses some of advantages of having a theme in the first place -- >> namely that if you use the standard naming conventions for icons, then you >> should be able to do drop-in replacements of the icons without having to >> change your code. This makes is possible to freshen up the look of your >> app, or to use icon themes that fit a specific OS. After all, do you >> really want Tango icons on your nice clean OS X app? Moreover, it would >> make it possible for user's to customize the look of their apps without >> developer involvement. >> >> Which brings me rather circuitously back to my point -- is there a way to >> support icon themes in CSS? For example, I'd like to simply drop * >> AwOken.tar.gz* into my classpath, and have an icon reference like this >> resolve properly: *-fx-image: url('clear/24x24/apps/** >> ubuntuone-client.png');* >> * >> * >> Ideally, this should happen without having to repackage the icon themes >> into a JAR since themes are often stored in a variety of formats tar.gz, >> rar, zip, etc. >> >> >> Cheers, >> >> Mark >> > > From tbee at tbee.org Sat Oct 20 23:49:17 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 21 Oct 2012 08:49:17 +0200 Subject: JavaFX Maven Plugin In-Reply-To: References: Message-ID: <50839AED.3060801@tbee.org> Thanks for sharing Daniel! On 2012-10-21 06:30, Daniel Zwolenski wrote: > I have tidied up, and open sourced my JavaFX Maven plugin enough that it > builds executable JARs (equivalent to the fx:jar ant task) and native > bundles (equivalent to a subset of fx:deploy ant task): > > https://github.com/zonski/javafx-maven-plugin > > > I was waiting for the bootclasspath issue to get resolved to fix this up > properly, but since I'm getting further and further away from JFX I figured > better to tidy it up and hand it over to the community. > > It does work perfectly well enough that you can use it to build real > distributables of your app via Maven. > > However it wraps only the basic JavaFX plugin features (i.e. you can't > customise many of the settings), does not support Applets (dead anyway) or > JNLP (I've never had success getting JNLP to actually work with JFX). It > likely also has some platform specific bugs and problems, since I have > tested only on Windows and building MSI's. > > It would be relatively trivial (but time consuming) to extend it further. > The code is simple but inelegant. Great improvements could be made if the > JFX deployment team were to make some minor changes to their packaging API > to make it easier to integrate with. And massive clean-ups could be made if > they put their tools JAR in a Maven repo that they maintained. > > I don't have any intention to develop this further or maintain it. It is a > good base but it would be up to someone from the community to do this if > they want it to do anything more than it does. > > Note this plugin is to address the packaging/assembly issue. It does NOT > solve the getting-jfx-on-the-classpath-issue. You still need to do whatever > workaround you're doing now on that front. From tbee at tbee.org Sun Oct 21 00:01:07 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 21 Oct 2012 09:01:07 +0200 Subject: Icon Theme Support In-Reply-To: <50835FCB.90703@oracle.com> References: <50835FCB.90703@oracle.com> Message-ID: <50839DB3.7010709@tbee.org> I wrote such a library for swing. Icon packs are interesting when you allow the users to select their skin. I have an custom ERP application which is 10 years old. It initially was using Metal, but since that looks kinda old fashion, I've had a number of goes at trying to use another skin (synthentica is brilliant). The problem was that some of the more, ah, experienced users wanted to keep using Metal, while newcomers were open to a fresher look. Hence they get to choose between 30 something skins. And when they switch skin, they also switch icon pack. Icon packs can be large indeed, but considering the ERP's all-in-one jar that is distributed is about 10MB, a few KB more or less is no issue. It of course depends on the context; maybe if you're developing for mobile, than icons packs may be too much (otoh, the Ensemble app is almost 70MB I believe?). The advantage is that you have all icons available and can simply pick one if you need a new one vs having to copy a new file into the source tree. And you can -if you like- provide a tuned icon pack with only the sizes and icons that are required. So it does offer the best of both worlds; easily switchable, easily distributable but still tuneable. Tom On 2012-10-21 04:36, Jonathan Giles wrote: > I'm interested to hear if this is common practice. In one of my past lives as a Swing client application developer I would always cherry pick the icons I wanted to use out of the icon packs I had available to me, rather than try to ship an entire icon pack (or multiple icon packs). From my experience icon packs tend to be rather large (when taking into account they normally ship with some permutation of 16x16, 24x24, 32x32, 48x48, 64x64 pixel .png, .svg and .ico files). > > So, in short, is shipping an entire, or multiple, icon packs something that people actually want to do, and if so, would some kind of library support for this be beneficial? > > As a secondary question / comment: this seems like something that a third party library could offer - rather than being necessarily included in JavaFX itself? > > -- Jonathan > > On 21/10/2012 5:58 a.m., Mark Fortner wrote: >> I was wondering if anyone had given any thought to supporting Icon Themes >> in JavaFX? When you look at Swing apps (and now JavaFX apps) you find a >> lot of the same icons borrowed from various Linux icon themes. Invariably >> someone has taken apart the theme's archive, and extracted the icons that >> they wanted and simply added them as resources to their project. However, >> that misses some of advantages of having a theme in the first place -- >> namely that if you use the standard naming conventions for icons, then you >> should be able to do drop-in replacements of the icons without having to >> change your code. This makes is possible to freshen up the look of your >> app, or to use icon themes that fit a specific OS. After all, do you >> really want Tango icons on your nice clean OS X app? Moreover, it would >> make it possible for user's to customize the look of their apps without >> developer involvement. >> >> Which brings me rather circuitously back to my point -- is there a way to >> support icon themes in CSS? For example, I'd like to simply drop * >> AwOken.tar.gz* into my classpath, and have an icon reference like this >> resolve properly: *-fx-image: url('clear/24x24/apps/ubuntuone-client.png');* >> * >> * >> Ideally, this should happen without having to repackage the icon themes >> into a JAR since themes are often stored in a variety of formats tar.gz, >> rar, zip, etc. >> >> >> Cheers, >> >> Mark > From phidias51 at gmail.com Sun Oct 21 10:08:46 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Sun, 21 Oct 2012 10:08:46 -0700 Subject: Fwd: Icon Theme Support In-Reply-To: References: <50835FCB.90703@oracle.com> Message-ID: Sorry about not sending this directly to the list. I keep tripping over the fact that by default it only sends the reply directly to the sender. Somebody please fix this. ---------- Forwarded message ---------- From: Mark Fortner Date: Sun, Oct 21, 2012 at 10:05 AM Subject: Re: Icon Theme Support To: jonathan.giles at oracle.com Hi Jonathan, Given the size of the desktop applications, an additional few Mb doesn't make that big of a difference. But you do bring up a good point about being able to cherry pick icons. Maven has a plugin called Shade which is useful in reducing the size of the resultant artifact. Usually we use it when we want to cherry pick classes from large libraries and create an uber jar that contains the application classes + the cherry picked classes. It makes me wonder if something similar already exists for dealing with resources. The workflow would then resemble what most people currently do with libraries: 1. Add a dependency from mvnrepository.com (or in this case a resource dependency) to your POM. 2. Maven would automatically download and install the resource in your local .m2/repository. 3. Build your application and Shade the resulting JAR (or in this case perhaps "Shard" the resources). The primary disadvantage to manually cherry picking icons, is that often the resultant application reflects that cherry picking. Developer A chooses his icons from Theme 1, and Developer B chooses his icons from Theme 2. And the results look horrendous to the end user. The other thing I wonder, is how someone would control which icon theme was selected? I could envision these scenarios: 1. The developer wants to specify 3 themes (1 per OS they plan to support), and have a factory automatically switch between those three choices whenever the user loads the applications. The CSS stylesheets * -fx-image* references would need to automatically resolve the appropriate icon from the appropriate icon theme. The developer would want to treat icons in all themes within has classpath as *mutually exclusive*-- only one theme would get used at a time. 2. The developer wants a single look and thus the URL resolver only has to focus on retrieving icons from a single theme. The developer perhaps selects a different icon factory for this. 3. The developer wants to use two closely related themes, that are graphically similar (like general Tango theme, and the Tango theme for graphics applications like the GIMP). The developer would want to treat icons in all themes within his classpath as *mutually inclusive*. 4. The developer wants to provide the users with the ability to switch between icon themes as part of the application preferences. 5. The developer needs to support different icon sizes to support different resolutions, or the needs of users with different levels of visual acuity. ** The Less library that Dan pointed out looks particularly interesting. I like that you can dynamically change the style sheet. One of the things that I currently find bothersome is that you can't map arbitrary states to pseudo selectors. Currently you have a pseudo selector like ":hover", but it would be nice if the developer could map any state or combination of states to a style. ** Cheers, Mark On Sat, Oct 20, 2012 at 7:36 PM, Jonathan Giles wrote: > I'm interested to hear if this is common practice. In one of my past lives > as a Swing client application developer I would always cherry pick the > icons I wanted to use out of the icon packs I had available to me, rather > than try to ship an entire icon pack (or multiple icon packs). From my > experience icon packs tend to be rather large (when taking into account > they normally ship with some permutation of 16x16, 24x24, 32x32, 48x48, > 64x64 pixel .png, .svg and .ico files). > > So, in short, is shipping an entire, or multiple, icon packs something > that people actually want to do, and if so, would some kind of library > support for this be beneficial? > > As a secondary question / comment: this seems like something that a third > party library could offer - rather than being necessarily included in > JavaFX itself? > > -- Jonathan > > > On 21/10/2012 5:58 a.m., Mark Fortner wrote: > >> I was wondering if anyone had given any thought to supporting Icon Themes >> in JavaFX? When you look at Swing apps (and now JavaFX apps) you find a >> lot of the same icons borrowed from various Linux icon themes. Invariably >> someone has taken apart the theme's archive, and extracted the icons that >> they wanted and simply added them as resources to their project. However, >> that misses some of advantages of having a theme in the first place -- >> namely that if you use the standard naming conventions for icons, then you >> should be able to do drop-in replacements of the icons without having to >> change your code. This makes is possible to freshen up the look of your >> app, or to use icon themes that fit a specific OS. After all, do you >> really want Tango icons on your nice clean OS X app? Moreover, it would >> make it possible for user's to customize the look of their apps without >> developer involvement. >> >> Which brings me rather circuitously back to my point -- is there a way to >> support icon themes in CSS? For example, I'd like to simply drop * >> AwOken.tar.gz* into my classpath, and have an icon reference like this >> resolve properly: *-fx-image: url('clear/24x24/apps/** >> ubuntuone-client.png');* >> * >> >> * >> Ideally, this should happen without having to repackage the icon themes >> into a JAR since themes are often stored in a variety of formats tar.gz, >> rar, zip, etc. >> >> >> Cheers, >> >> Mark >> > > From phidias51 at gmail.com Sun Oct 21 10:16:50 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Sun, 21 Oct 2012 10:16:50 -0700 Subject: Making JavaFX Development Faster In-Reply-To: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> Message-ID: The article that Will pointed out was interesting. However, the developer would still end up having to write code to make their POJOs or POJO collections observable. It would be nice if there was a "dynamic proxy" that automagically made any class you sent it observable. Not sure how doable that is -- just thinking off the top of my head. The one thing that you would need to avoid is making your POJO have any JavaFX dependencies. On the issue of RAD tooling, it sounds like the Griffon team is making some progress with respect to making JavaFX easier. I'm not sure how well Griffon's Service and Controller interfaces map to JavaFX's Controller. Cheers, Mark On Thu, Oct 18, 2012 at 11:21 AM, Richard Bair wrote: > Another option I would guess is to not use observable objects at all, but > you can still use binding (the property adapters should work with that). > Even with a list view, which has an ObservableList, you can add items form > a normal list and vice versa. > > On Oct 18, 2012, at 10:39 AM, Mark Fortner wrote: > > > One of the big timewasters when it comes to JavaFX projects taking your > > server-side POJOs, creating Observable versions of them, and creating > > forms, and controllers for them. If you've been doing JEE development in > > the past 5 years then you're probably already using Spring ROO, Grails, > or > > some other RAD tooling that makes this type of work trivial in the web > > world. All of these artifacts are usually generated directly from the > > POJOs. > > > > So I'm curious if anyone knows of any tools that make that process easier > > and faster? > > > > > > Cheers, > > > > Mark > > From tbee at tbee.org Sun Oct 21 12:37:19 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 21 Oct 2012 21:37:19 +0200 Subject: IllegalStateException on an observable list Message-ID: <50844EEF.3070708@tbee.org> I have two observable lists; one containing appointments, the other containing selected appointments. If an appointment is removed from the first list, it also must be removed from the second. For this I setup a listener on the first list to handle this: // when appointments are removed, they can't be selected anymore appointments.addListener(new ListChangeListener() { @Override public void onChanged(javafx.collections.ListChangeListener.Change changes) { for (Appointment lAppointment : changes.getRemoved()) { selectedAppointments.remove(lAppointment); } } }); when constructing the control I get the following exception on the getRemoved() call. Caused by: java.lang.IllegalStateException at com.sun.javafx.collections.NonIterableChange.checkState(NonIterableChange.java:101) at com.sun.javafx.collections.NonIterableChange$SimpleAddChange.getRemoved(NonIterableChange.java:158) at jfxtras.labs.scene.control.Agenda$1.onChanged(Agenda.java:108) at com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:134) at com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:48) at com.sun.javafx.collections.ObservableListWrapper.callObservers(ObservableListWrapper.java:97) at com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:171) at com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:160) at com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:309) at jfxtras.labs.scene.control.AgendaTrial1.start(AgendaTrial1.java:122) at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:319) at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:206) at com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29) at com.sun.glass.ui.win.WinApplication$2$1.run(WinApplication.java:62) ... 1 more Can someone explain why? And how to work around that? Tom From jonathan.giles at oracle.com Sun Oct 21 13:12:42 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 22 Oct 2012 09:12:42 +1300 Subject: IllegalStateException on an observable list In-Reply-To: <50844EEF.3070708@tbee.org> References: <50844EEF.3070708@tbee.org> Message-ID: <5084573A.8050001@oracle.com> This is a common mistake. You must, inside the onChanged method, loop through the changes as such: while (changes.next()) { // put your for loop here } I agree the exception is not clear - I would love to see an improved error message in the exception to clarify what people need to do. -- Jonathan On 22/10/2012 8:37 a.m., Tom Eugelink wrote: > I have two observable lists; one containing appointments, the other > containing selected appointments. If an appointment is removed from > the first list, it also must be removed from the second. For this I > setup a listener on the first list to handle this: > > // when appointments are removed, they can't be selected anymore > appointments.addListener(new > ListChangeListener() > { > @Override > public void > onChanged(javafx.collections.ListChangeListener.Change Appointment> changes) > { > for (Appointment lAppointment : changes.getRemoved()) > { > selectedAppointments.remove(lAppointment); > } > } > }); > > when constructing the control I get the following exception on the > getRemoved() call. > > Caused by: java.lang.IllegalStateException > at > com.sun.javafx.collections.NonIterableChange.checkState(NonIterableChange.java:101) > at > com.sun.javafx.collections.NonIterableChange$SimpleAddChange.getRemoved(NonIterableChange.java:158) > at jfxtras.labs.scene.control.Agenda$1.onChanged(Agenda.java:108) > at > com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:134) > at > com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:48) > at > com.sun.javafx.collections.ObservableListWrapper.callObservers(ObservableListWrapper.java:97) > at > com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:171) > at > com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:160) > at > com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:309) > at > jfxtras.labs.scene.control.AgendaTrial1.start(AgendaTrial1.java:122) > at > com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:319) > at > com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:206) > at > com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173) > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at > com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29) > at > com.sun.glass.ui.win.WinApplication$2$1.run(WinApplication.java:62) > ... 1 more > > Can someone explain why? And how to work around that? > > Tom > > From tbee at tbee.org Sun Oct 21 13:12:59 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 21 Oct 2012 22:12:59 +0200 Subject: IllegalStateException on an observable list In-Reply-To: References: <50844EEF.3070708@tbee.org> Message-ID: <5084574B.6000108@tbee.org> How blond can one be, overlooked that. Thanks. Tom On 2012-10-21 22:07, Martin Kl?hn wrote: > Hi, > > it seems you've missed to iterate through the collected changes in that Change. if you wrap your for-loop in while(c.next()) it'll work. you can then optionally check if the change was caused by appointments being removed from the list or by something else. See http://docs.oracle.com/javafx/2/api/javafx/collections/ListChangeListener.Change.html for reference. > > Martin > > > On Sun, Oct 21, 2012 at 9:37 PM, Tom Eugelink > wrote: > > I have two observable lists; one containing appointments, the other containing selected appointments. If an appointment is removed from the first list, it also must be removed from the second. For this I setup a listener on the first list to handle this: > > // when appointments are removed, they can't be selected anymore > appointments.addListener(new ListChangeListener() > { > @Override > public void onChanged(javafx.collections.ListChangeListener.Change changes) > { > for (Appointment lAppointment : changes.getRemoved()) > { > selectedAppointments.remove(lAppointment); > } > } > }); > > when constructing the control I get the following exception on the getRemoved() call. > > Caused by: java.lang.IllegalStateException > at com.sun.javafx.collections.NonIterableChange.checkState(NonIterableChange.java:101) > at com.sun.javafx.collections.NonIterableChange$SimpleAddChange.getRemoved(NonIterableChange.java:158) > at jfxtras.labs.scene.control.Agenda$1.onChanged(Agenda.java:108) > at com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:134) > at com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:48) > at com.sun.javafx.collections.ObservableListWrapper.callObservers(ObservableListWrapper.java:97) > at com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:171) > at com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:160) > at com.sun.javafx.collections.ObservableListWrapper.addAll(ObservableListWrapper.java:309) > at jfxtras.labs.scene.control.AgendaTrial1.start(AgendaTrial1.java:122) > at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:319) > at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:206) > at com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173) > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29) > at com.sun.glass.ui.win.WinApplication$2$1.run(WinApplication.java:62) > ... 1 more > > Can someone explain why? And how to work around that? > > Tom > > > From omurata at ga2.so-net.ne.jp Sun Oct 21 15:47:31 2012 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Mon, 22 Oct 2012 07:47:31 +0900 Subject: ChoiceBoxBuilder.create() is error. How to fix? Message-ID: <50847B83.3010604@ga2.so-net.ne.jp> Hello everyone ChoiceBox choiceBox = ChoiceBoxBuilder.create() .items( FXCollections.observableArrayList("New", "Open", "Save", "Exit") ) .build(); The method create() is ambiguous for the type ChoiceBoxBuilder at Java8. It is OK at Java7. Plese teach me how to fix this error? Best regards Tadashi Ohmura From phidias51 at gmail.com Sun Oct 21 16:13:33 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Sun, 21 Oct 2012 16:13:33 -0700 Subject: IllegalStateException on an observable list In-Reply-To: <5084574B.6000108@tbee.org> References: <50844EEF.3070708@tbee.org> <5084574B.6000108@tbee.org> Message-ID: I guess part of the problem is the semantics of the word "Change". Perhaps "ChangeSet" or some kind of collective noun would make it more obvious that you have more than one item that you need to iterate through. Cheers, Mark On Sun, Oct 21, 2012 at 1:12 PM, Tom Eugelink wrote: > How blond can one be, overlooked that. Thanks. > > Tom > > > On 2012-10-21 22:07, Martin Kl?hn wrote: > >> Hi, >> >> it seems you've missed to iterate through the collected changes in that >> Change. if you wrap your for-loop in while(c.next()) it'll work. you can >> then optionally check if the change was caused by appointments being >> removed from the list or by something else. See >> http://docs.oracle.com/javafx/**2/api/javafx/collections/** >> ListChangeListener.Change.htmlfor reference. >> >> Martin >> >> >> >> On Sun, Oct 21, 2012 at 9:37 PM, Tom Eugelink > tbee at tbee.org>> wrote: >> >> I have two observable lists; one containing appointments, the other >> containing selected appointments. If an appointment is removed from the >> first list, it also must be removed from the second. For this I setup a >> listener on the first list to handle this: >> >> // when appointments are removed, they can't be selected >> anymore >> appointments.addListener(new ListChangeListener> Appointment>() >> { >> @Override >> public void onChanged(javafx.collections.**ListChangeListener.Change> extends Appointment> changes) >> { >> for (Appointment lAppointment : changes.getRemoved()) >> { >> selectedAppointments.remove(**lAppointment); >> } >> } >> }); >> >> when constructing the control I get the following exception on the >> getRemoved() call. >> >> Caused by: java.lang.**IllegalStateException >> at com.sun.javafx.collections.**NonIterableChange.checkState(** >> NonIterableChange.java:101) >> at com.sun.javafx.collections.**NonIterableChange$** >> SimpleAddChange.getRemoved(**NonIterableChange.java:158) >> at jfxtras.labs.scene.control.**Agenda$1.onChanged(Agenda.** >> java:108) >> at com.sun.javafx.collections.**ListListenerHelper$** >> SingleChange.**fireValueChangedEvent(**ListListenerHelper.java:134) >> at com.sun.javafx.collections.**ListListenerHelper.** >> fireValueChangedEvent(**ListListenerHelper.java:48) >> at com.sun.javafx.collections.**ObservableListWrapper.** >> callObservers(**ObservableListWrapper.java:97) >> at com.sun.javafx.collections.**ObservableListWrapper.addAll(** >> ObservableListWrapper.java:**171) >> at com.sun.javafx.collections.**ObservableListWrapper.addAll(** >> ObservableListWrapper.java:**160) >> at com.sun.javafx.collections.**ObservableListWrapper.addAll(** >> ObservableListWrapper.java:**309) >> at jfxtras.labs.scene.control.**AgendaTrial1.start(** >> AgendaTrial1.java:122) >> at com.sun.javafx.application.**LauncherImpl$5.run(** >> LauncherImpl.java:319) >> at com.sun.javafx.application.**PlatformImpl$5.run(** >> PlatformImpl.java:206) >> at com.sun.javafx.application.**PlatformImpl$4.run(** >> PlatformImpl.java:173) >> at com.sun.glass.ui.win.**WinApplication._runLoop(Native Method) >> at com.sun.glass.ui.win.**WinApplication.access$100(** >> WinApplication.java:29) >> at com.sun.glass.ui.win.**WinApplication$2$1.run(** >> WinApplication.java:62) >> ... 1 more >> >> Can someone explain why? And how to work around that? >> >> Tom >> >> >> >> > From lehmann at media-interactive.de Mon Oct 22 03:30:38 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 22 Oct 2012 12:30:38 +0200 Subject: Making JavaFX Development Faster In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> Message-ID: <5085204E.7090207@media-interactive.de> Basically FX likes to have observable properties, and POJOs (domain beans) should not have an FX dependency. Sounds like a contradiction. Without changing the POJOS we can only wrap or subclass them. A wrapper would delegate all getters and setters and introduce observable properties. The property objects must use the wrapped POJOs fields to keep their values instead of having their own value field. One problem is how to know when a POJO setter is called directly? A subclass would add the observable properties directly. It could also override the setters, thus triggering the property invalidations. The problem here is that data has to be copied from the POJO to an instance of the POJO subclass (and possibly also the other way). A code generator can be built for either approach. It would FXify a set of provided POJOs. I am not sure if that is really desirable though. I really don't want to deal with a "shadow" class for each POJO class. FWIW, it might also be possible to use a java.lang.Proxy. In this case we still need an interface for each POJO (consisting of getters, setters, observable properties). The proxy would act like an FX view to the POJO. It can intercept the setter calls and trigger invalidations. Still there is the requirement of having POJO specific interfaces (another code generator here). Werner On 21.10.2012 19:16, Mark Fortner wrote: > The article that Will pointed out was interesting. However, the developer > would still end up having to write code to make their POJOs or POJO > collections observable. It would be nice if there was a "dynamic proxy" > that automagically made any class you sent it observable. Not sure how > doable that is -- just thinking off the top of my head. > > The one thing that you would need to avoid is making your POJO have any > JavaFX dependencies. > > On the issue of RAD tooling, it sounds like the Griffon team is making some > progress with respect to making JavaFX easier. I'm not sure how well > Griffon's Service and Controller interfaces map to JavaFX's Controller. > > Cheers, > > Mark From kevin.rushforth at oracle.com Mon Oct 22 05:26:45 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Oct 2012 05:26:45 -0700 Subject: Memory Leaks In-Reply-To: References: <50831490.2030007@oracle.com> Message-ID: <50853B85.1000103@oracle.com> To elaborate on this a bit... With every JDK 7-update release there will be a corresponding JavaFX release. There are only a few security bug fixes in 2.2.3 beyond what is in 2.2.0 -- functionally they are the same, which is why there was no big announcement. With the recent release renaming(s) you almost need a secret decoder ring or a Rosetta stone to keep track of them, but basically it is this: JDK 7u10 / FX 2.2.4 -- very limited update release in December; any bug that isn't already fixed and doesn't cause your computer to catch fire isn't going to make this release. JDK 7u11 / FX 2.2.5 -- security release in February JDK 7u12 / FX 2.2.6 -- limited update release next spring (I'm not sure if the exact dates are nailed down); this is the next opportunity for non-security-related critical bug fixes. A memory leak would be a good candidate for this. As Jonathan indicated, our resources are focused on FX 8, but there is an opportunity to fix a few of the more serious bugs in 2.2.6. -- Kevin Scott Palmer wrote: > Thanks for the response. 8.0 is too far away. I need to ship my app in a > few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 > yesterday. We were on 7u7 and then I discovered that there was a new > JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too > long ago with 2.2.0 and I didn't see any sort of announcements that there > was anything newer. > > I will try to isolate the leak. We think we are seeing > com.sun.javafx.css.StyleHelper$CacheEntry and > com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least). > > jvisualvm shows the number of those objects are always growing. Comparing > heap dumps we have never observed the number to decrease. > > I'm currently only able to connect to the machine running my test via > Remote Desktop, and the screen saver probably keep kicking in, I think that > is affecting the test. Is JavaFX smart enough to not render when the > screen is blanked? > > I will try to produce a test case. But if anyone has knowledge about this > that wants to share, any info is appreciated. > > Thanks,, > Scott > > On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles > wrote: > > >> David Grieve is the go-to expert on all things CSS, but from a >> higher-level perspective the general answer is always: you tell us! :-) >> There might be a leak we don't know about, or can't easily reproduce, and >> you might have just the information we need to finally get rid of that >> annoying leak you mention. >> >> So, please, file Jira bugs on us and we'll get to looking at them as soon >> as possible. If you can provide a reproducible test case that would be >> hugely appreciated too. >> >> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've >> been actively developing in the 8.0 branch for quite a long time now, and >> one of our primary focuses during this time has been performance (CPU and >> memory). In other words, there is a chance it may already be resolved (or >> minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 >> builds available that you can test with. If you have the time and >> inclination, it might be worth testing against these builds to see if it is >> resolved. >> >> Thanks, >> -- Jonathan >> >> >> On 21/10/2012 2:10 a.m., Scott Palmer wrote: >> >> >>> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? >>> In my application I add and remove style classes to highlight objects in >>> the scene graph that are in various states (selected, active, disabled, >>> etc). It seems that every time the style class list is changed that there >>> is a small leak. Since while the app runs and process data (a process that >>> may run indefinitely) the state of objects in the graph changes as data is >>> processed, this is a significant issue. Our customers may have the app >>> fail after several hours or a few days because of these leaks. >>> >>> Scott >>> >>> >> From steve.x.northover at oracle.com Mon Oct 22 06:21:07 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 22 Oct 2012 09:21:07 -0400 Subject: TextField Document model In-Reply-To: <50836C4C.6050407@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> Message-ID: <50854843.3000602@oracle.com> Another idea is to have a TextField that validates using a RegEx. I expect that this would augment (not replace) the need for specific Date/Time validation classes etc. Steve On 20/10/2012 11:30 PM, Jonathan Giles wrote: > I'm coming into this discussion really late, but I've been sick, so > that's my excuse, and I'm sticking to it :-) > > Firstly, regarding the options Richard sets out below, my strong > preference is for option a (introduce a callback). It seems that it > supports the use cases that have been raised, and it does so without > introducing concerns around having a mutable Content. I think I would > only sway from this position if there is a use case that just can't be > done with this approach (which I'm totally willing to do if someone > has one). > > Secondly, Richard mentions an important point here: one of the things > that has been on the controls team backlog for way too long is support > for a FormattedTextField control, and important subclasses thereof > (e.g. Date/Time, Money, Zip code, etc). An ideal situation would be > (in my humble opinion) for JavaFX to ship with FormattedTextField and > the most critical subclasses, and for 3rd party projects such as > JFXtras / JIDE to bring out all the rest. > > This approach of shipping 'simple' controls is what we did with Button > / Hyperlink and RadioButton / ToggleButton - in many cases the > difference in code between these classes is minimal, but it allows for > way better discoverability of controls and functionality - rather than > having an uber control with miles of API to toggle state / features. > This approach works well, and it also looks great on our 'number of > controls' fact sheet :-) > > Zooming out even further, we need to expand this discussion in one > very important way: validation support. I don't have an answer for > validation yet (it is certainly not a JavaFX 8.0 feature), but we have > to keep it in the back of our minds lest we regret it later (ah, the > joys of API development!). > > Finally, FormattedTextField is _not_ planned for JavaFX 8.0. However, > I would love to have someone submit a FormattedTextField control via > OpenJFX. I am more than happy to work with anyone interested in doing > so, and from my perspective this would seem to be an easy control to > develop - so it would be ideal for someone to get up to speed with > JavaFX controls development. If anyone is interested please join the > discussion and let me know. > > Thanks, > -- Jonathan > > On 20/10/2012 6:05 a.m., Richard Bair wrote: >>> I did not have time to look at the Skin and Behavior paradigms yet, >>> so I >>> can't speak to the impact on them. I will try to brush up on those >>> this >>> weekend. However, if this subclassing to delegate becomes relatively >>> common, then it seems that whatever Skin and Behavior issues might >>> arise >>> would still need to be addressed. However now they would need to be >>> addressed by application designers instead of by the platform. >> In general, I'm not a fan of subclass to delegate (AWT required >> subclassing for all event handling. Whoops!). The question in this >> case however is, what are the use cases and what is the best way to >> expose support for those such that the API is consistent and doesn't >> have any odd corners or gotchas. Sometimes the only way to expose the >> required functionality is to create such gotchas. Other times we can >> do something simpler, although more constraining, that covers 95% of >> the usages, and then subclassing allows power users to squeeze out >> the extra 5%. >> >> So for example, I would expect people would prefer to have a >> SearchField, DateField, MoneyField, and TextField with a maxLength >> property, rather than having to use callbacks or having to configure >> a TextField with all the right properties. It is easier to pick a >> DateField from a palette and just use it than it is to setup custom >> Content or even using off-the-shelf Content but having to plug it >> into a TextField (since doing this requires a little more thought and >> understanding of the architecture). On the other hand, being able to >> plug in the content is more natural than having to subclass in order >> to plug in the content. >> >> My feeling on it has been, we ought to add (or JFXtras, or JIDE ought >> to add) SearchField, MoneyField, etc as Controls and we ought to give >> TextField a maxLength, and we ought to have a more general purpose >> FormattedTextField. Of course, that doesn't help address some of the >> other odd use cases like an all-caps field, so the question is, for >> such a use case, is it better to: >> >> a) Add some callbacks to all TextInputControl's that let you >> filter / modify changes to the text or >> b) Allow Content to be replaced or >> c) Restrict such features to sub classes >> >> Of these, my feeling was that (a) was the most useful in connection >> with built-in DateField, MoneyField, etc. I worry that by making >> Content mutable, we make it very easy for people to naively replace >> the Content with their own, rather than wrapping the existing >> Content, and thus adding bugs into their software such as what >> happens when you paste a \n into a TextField. That just isn't one of >> those things that people think about the first time around. That's >> why I liked (a) better, where Content was basically under the control >> of the Text control implementation, but developers had an easy way to >> insert code into the process and filter / reject / etc changes to the >> Content model. >> >> Richard > From tbee at tbee.org Mon Oct 22 06:28:53 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 22 Oct 2012 15:28:53 +0200 Subject: TextField Document model In-Reply-To: <50854843.3000602@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> Message-ID: <50854A15.4070600@tbee.org> With regexp there may be problems with internationalization; some write the month at the front, some in between, etc. So you need a place where that locale derived information is stored anyhow, why not just do the whole text parsing in there? (aka formatters) Tom On 2012-10-22 15:21, steve.x.northover at oracle.com wrote: > Another idea is to have a TextField that validates using a RegEx. I expect that this would augment (not replace) the need for specific Date/Time validation classes etc. > > Steve From steve.x.northover at oracle.com Mon Oct 22 06:40:26 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 22 Oct 2012 09:40:26 -0400 Subject: TextField Document model In-Reply-To: <50854A15.4070600@tbee.org> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <50854A15.4070600@tbee.org> Message-ID: <50854CCA.4010405@oracle.com> .. like I said, a TextField that validated using a RegEx would not be a replacement for Date/Time etc. validation classes. On 22/10/2012 9:28 AM, Tom Eugelink wrote: > With regexp there may be problems with internationalization; some > write the month at the front, some in between, etc. So you need a > place where that locale derived information is stored anyhow, why not > just do the whole text parsing in there? (aka formatters) > > Tom > > > > On 2012-10-22 15:21, steve.x.northover at oracle.com wrote: >> Another idea is to have a TextField that validates using a RegEx. I >> expect that this would augment (not replace) the need for specific >> Date/Time validation classes etc. >> >> Steve > From markclaassenx at gmail.com Mon Oct 22 07:01:10 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Mon, 22 Oct 2012 10:01:10 -0400 Subject: TextField Document model In-Reply-To: <50854843.3000602@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> Message-ID: Alright, so Suggestion 1 had mutable content, but not allowing unrestricted implementations Suggestion 1: (possibility) Add method in TextField public void setContent(TextFieldContent c); public class TextFieldContent { public void delete(int start, int end, boolean notifyListeners) { .... } public void insert(int index, String s, boolean notifyListeners) { .... } public final String get(int start, int end) { .... } final int length() { .... } } > my strong preference is for option a (introduce a callback). Suggestion 2: (possibility) public interface ContentFilter public void onDelete(Content content, TextInputControl control, int start, int end, boolean notifyListeners) { .... } public void onInsert(Content content, TextInputControl control, int index, String s, boolean notifyListeners) { .... } } I added the TextInputControl to the list of parameters so that cursor manipulation could be done. The above specification would also require the user to call content.delete() and content.insert() for anything to be changed. I thought about using boolean return values to signify whether or not the input was already handled or not, but that would just force a user to know how to used the booleans. This seemed nicer to me. This would allow I lot of power. * It has the safety of calling the insert and delete models on the rigorous implementation of Content * Allows the content to be replaced (if appropriate) at each event. * Allows for the Content variable to be final > This approach works well, and it also looks great on our 'number of controls' fact sheet :-) I agree that having several well named controls is a good idea. It makes the bar a lot lower for newbies... which I guess we all area right now! I would be interested in taking a stab at the FormattedTextField control. What are your feelings for how you think it should work? Mark From hang.vo at oracle.com Mon Oct 22 07:03:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 22 Oct 2012 14:03:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25753: toString() of gestures reports inertia. Message-ID: <20121022140340.8006E47496@hg.openjdk.java.net> Changeset: 99a390cd0ec5 Author: Pavel Safrata Date: 2012-10-22 15:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/99a390cd0ec5 RT-25753: toString() of gestures reports inertia. ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java From david.grieve at oracle.com Mon Oct 22 07:06:21 2012 From: david.grieve at oracle.com (David Grieve) Date: Mon, 22 Oct 2012 10:06:21 -0400 Subject: Memory Leaks In-Reply-To: References: <50831490.2030007@oracle.com> Message-ID: <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> There was a larger leak discovered late in the 2.2 release cycle. This leak was fixed but another, smaller, leak remained. Unfortunately, this smaller leak was not fixed because there simply wasn't enough time left in the release. The issue is being tracked by bug RT-23691. The issue is not yet resolved. On Oct 20, 2012, at 6:01 PM, Scott Palmer wrote: > Thanks for the response. 8.0 is too far away. I need to ship my app in a > few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 > yesterday. We were on 7u7 and then I discovered that there was a new > JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too > long ago with 2.2.0 and I didn't see any sort of announcements that there > was anything newer. > > I will try to isolate the leak. We think we are seeing > com.sun.javafx.css.StyleHelper$CacheEntry and > com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least). > > jvisualvm shows the number of those objects are always growing. Comparing > heap dumps we have never observed the number to decrease. > > I'm currently only able to connect to the machine running my test via > Remote Desktop, and the screen saver probably keep kicking in, I think that > is affecting the test. Is JavaFX smart enough to not render when the > screen is blanked? > > I will try to produce a test case. But if anyone has knowledge about this > that wants to share, any info is appreciated. > > Thanks,, > Scott > > On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles > wrote: > >> David Grieve is the go-to expert on all things CSS, but from a >> higher-level perspective the general answer is always: you tell us! :-) >> There might be a leak we don't know about, or can't easily reproduce, and >> you might have just the information we need to finally get rid of that >> annoying leak you mention. >> >> So, please, file Jira bugs on us and we'll get to looking at them as soon >> as possible. If you can provide a reproducible test case that would be >> hugely appreciated too. >> >> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've >> been actively developing in the 8.0 branch for quite a long time now, and >> one of our primary focuses during this time has been performance (CPU and >> memory). In other words, there is a chance it may already be resolved (or >> minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 >> builds available that you can test with. If you have the time and >> inclination, it might be worth testing against these builds to see if it is >> resolved. >> >> Thanks, >> -- Jonathan >> >> >> On 21/10/2012 2:10 a.m., Scott Palmer wrote: >> >>> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? >>> In my application I add and remove style classes to highlight objects in >>> the scene graph that are in various states (selected, active, disabled, >>> etc). It seems that every time the style class list is changed that there >>> is a small leak. Since while the app runs and process data (a process that >>> may run indefinitely) the state of objects in the graph changes as data is >>> processed, this is a significant issue. Our customers may have the app >>> fail after several hours or a few days because of these leaks. >>> >>> Scott >>> >> >> David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From danno.ferrin at shemnon.com Mon Oct 22 08:08:24 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 22 Oct 2012 09:08:24 -0600 Subject: Making JavaFX Development Faster In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> Message-ID: The controller doesn't map too well. We would need to write something custom to stand up the MVC Group in context of a FXML and inject into the FXML the controller, which is not always were the listeners live. My perspective is that the controller in FXML is more of a ViewModel from the MVVM pattern than a logic controller, which is what Griffon leans it's Controllers towards. It's not hard and fast, you can make either do the other approach, but structurally it biases the code in that direction. That being said, I do have a bug sitting in limbo ( http://javafx-jira.kenai.com/browse/RT-25559 - with a patch!) that would allow for easier integration of FXML into typical Griffon MV Groups. On Sun, Oct 21, 2012 at 11:16 AM, Mark Fortner wrote: > The article that Will pointed out was interesting. However, the developer > would still end up having to write code to make their POJOs or POJO > collections observable. It would be nice if there was a "dynamic proxy" > that automagically made any class you sent it observable. Not sure how > doable that is -- just thinking off the top of my head. > > The one thing that you would need to avoid is making your POJO have any > JavaFX dependencies. > > On the issue of RAD tooling, it sounds like the Griffon team is making some > progress with respect to making JavaFX easier. I'm not sure how well > Griffon's Service and Controller interfaces map to JavaFX's Controller. > > Cheers, > > Mark > > > > > On Thu, Oct 18, 2012 at 11:21 AM, Richard Bair >wrote: > > > Another option I would guess is to not use observable objects at all, but > > you can still use binding (the property adapters should work with that). > > Even with a list view, which has an ObservableList, you can add items > form > > a normal list and vice versa. > > > > On Oct 18, 2012, at 10:39 AM, Mark Fortner wrote: > > > > > One of the big timewasters when it comes to JavaFX projects taking your > > > server-side POJOs, creating Observable versions of them, and creating > > > forms, and controllers for them. If you've been doing JEE development > in > > > the past 5 years then you're probably already using Spring ROO, Grails, > > or > > > some other RAD tooling that makes this type of work trivial in the web > > > world. All of these artifacts are usually generated directly from the > > > POJOs. > > > > > > So I'm curious if anyone knows of any tools that make that process > easier > > > and faster? > > > > > > > > > Cheers, > > > > > > Mark > > > > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From swpalmer at gmail.com Mon Oct 22 08:39:02 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 22 Oct 2012 11:39:02 -0400 Subject: Memory Leaks In-Reply-To: <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> References: <50831490.2030007@oracle.com> <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> Message-ID: Thanks guys. RT-23691 might be related to what we are observing. We aren't even 100% convinced that FX is leaking. I need to study it a bit more. Attempts at creating a test case that reproduces our issue have not panned out yet. I see that there is a patch attached to that bug. What is the state of the patch? Is it going to be applied to 2.2.6? Sound like it is already too late for 2.2.4, but even that is probably too late for my release anyway, so I'm more interested in workarounds at this point. Is there an easy way to get a list of issues resolved between releases? Thanks, Scott On 2012-10-22, at 10:06 AM, David Grieve wrote: > There was a larger leak discovered late in the 2.2 release cycle. This leak was fixed but another, smaller, leak remained. Unfortunately, this smaller leak was not fixed because there simply wasn't enough time left in the release. The issue is being tracked by bug RT-23691. The issue is not yet resolved. > > On Oct 20, 2012, at 6:01 PM, Scott Palmer wrote: > >> Thanks for the response. 8.0 is too far away. I need to ship my app in a >> few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 >> yesterday. We were on 7u7 and then I discovered that there was a new >> JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too >> long ago with 2.2.0 and I didn't see any sort of announcements that there >> was anything newer. >> >> I will try to isolate the leak. We think we are seeing >> com.sun.javafx.css.StyleHelper$CacheEntry and >> com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least). >> >> jvisualvm shows the number of those objects are always growing. Comparing >> heap dumps we have never observed the number to decrease. >> >> I'm currently only able to connect to the machine running my test via >> Remote Desktop, and the screen saver probably keep kicking in, I think that >> is affecting the test. Is JavaFX smart enough to not render when the >> screen is blanked? >> >> I will try to produce a test case. But if anyone has knowledge about this >> that wants to share, any info is appreciated. >> >> Thanks,, >> Scott >> >> On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles >> wrote: >> >>> David Grieve is the go-to expert on all things CSS, but from a >>> higher-level perspective the general answer is always: you tell us! :-) >>> There might be a leak we don't know about, or can't easily reproduce, and >>> you might have just the information we need to finally get rid of that >>> annoying leak you mention. >>> >>> So, please, file Jira bugs on us and we'll get to looking at them as soon >>> as possible. If you can provide a reproducible test case that would be >>> hugely appreciated too. >>> >>> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've >>> been actively developing in the 8.0 branch for quite a long time now, and >>> one of our primary focuses during this time has been performance (CPU and >>> memory). In other words, there is a chance it may already be resolved (or >>> minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 >>> builds available that you can test with. If you have the time and >>> inclination, it might be worth testing against these builds to see if it is >>> resolved. >>> >>> Thanks, >>> -- Jonathan >>> >>> >>> On 21/10/2012 2:10 a.m., Scott Palmer wrote: >>> >>>> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? >>>> In my application I add and remove style classes to highlight objects in >>>> the scene graph that are in various states (selected, active, disabled, >>>> etc). It seems that every time the style class list is changed that there >>>> is a small leak. Since while the app runs and process data (a process that >>>> may run indefinitely) the state of objects in the graph changes as data is >>>> processed, this is a significant issue. Our customers may have the app >>>> fail after several hours or a few days because of these leaks. >>>> >>>> Scott >>>> >>> >>> > > > David Grieve | Principal Member of Technical Staff > Mobile: +16033121013 > Oracle Java Client UI and Tools > Durham, NH 03824 > Oracle is committed to developing practices and products that help protect the environment > From david.grieve at oracle.com Mon Oct 22 08:56:05 2012 From: david.grieve at oracle.com (David Grieve) Date: Mon, 22 Oct 2012 11:56:05 -0400 Subject: Memory Leaks In-Reply-To: References: <50831490.2030007@oracle.com> <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> Message-ID: <17E2873B-D09E-4422-8904-6C5A0A45B915@oracle.com> The bug was cloned from another and that patch is the one for the larger leak and is in 2.2 already. There is no plan for a patch for this issue in any 2.2.x release, as far as I know. If you can use existing pseudo class (selected, disabled, focused, etc.) state in your styles, rather than style classes, that will help. On Oct 22, 2012, at 11:39 AM, Scott Palmer wrote: > Thanks guys. RT-23691 might be related to what we are observing. We aren't even 100% convinced that FX is leaking. I need to study it a bit more. Attempts at creating a test case that reproduces our issue have not panned out yet. > > I see that there is a patch attached to that bug. What is the state of the patch? Is it going to be applied to 2.2.6? Sound like it is already too late for 2.2.4, but even that is probably too late for my release anyway, so I'm more interested in workarounds at this point. > > Is there an easy way to get a list of issues resolved between releases? > > Thanks, > > Scott > > On 2012-10-22, at 10:06 AM, David Grieve wrote: > >> There was a larger leak discovered late in the 2.2 release cycle. This leak was fixed but another, smaller, leak remained. Unfortunately, this smaller leak was not fixed because there simply wasn't enough time left in the release. The issue is being tracked by bug RT-23691. The issue is not yet resolved. >> >> On Oct 20, 2012, at 6:01 PM, Scott Palmer wrote: >> >>> Thanks for the response. 8.0 is too far away. I need to ship my app in a >>> few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 >>> yesterday. We were on 7u7 and then I discovered that there was a new >>> JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too >>> long ago with 2.2.0 and I didn't see any sort of announcements that there >>> was anything newer. >>> >>> I will try to isolate the leak. We think we are seeing >>> com.sun.javafx.css.StyleHelper$CacheEntry and >>> com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least). >>> >>> jvisualvm shows the number of those objects are always growing. Comparing >>> heap dumps we have never observed the number to decrease. >>> >>> I'm currently only able to connect to the machine running my test via >>> Remote Desktop, and the screen saver probably keep kicking in, I think that >>> is affecting the test. Is JavaFX smart enough to not render when the >>> screen is blanked? >>> >>> I will try to produce a test case. But if anyone has knowledge about this >>> that wants to share, any info is appreciated. >>> >>> Thanks,, >>> Scott >>> >>> On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles >>> wrote: >>> >>>> David Grieve is the go-to expert on all things CSS, but from a >>>> higher-level perspective the general answer is always: you tell us! :-) >>>> There might be a leak we don't know about, or can't easily reproduce, and >>>> you might have just the information we need to finally get rid of that >>>> annoying leak you mention. >>>> >>>> So, please, file Jira bugs on us and we'll get to looking at them as soon >>>> as possible. If you can provide a reproducible test case that would be >>>> hugely appreciated too. >>>> >>>> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've >>>> been actively developing in the 8.0 branch for quite a long time now, and >>>> one of our primary focuses during this time has been performance (CPU and >>>> memory). In other words, there is a chance it may already be resolved (or >>>> minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 >>>> builds available that you can test with. If you have the time and >>>> inclination, it might be worth testing against these builds to see if it is >>>> resolved. >>>> >>>> Thanks, >>>> -- Jonathan >>>> >>>> >>>> On 21/10/2012 2:10 a.m., Scott Palmer wrote: >>>> >>>>> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? >>>>> In my application I add and remove style classes to highlight objects in >>>>> the scene graph that are in various states (selected, active, disabled, >>>>> etc). It seems that every time the style class list is changed that there >>>>> is a small leak. Since while the app runs and process data (a process that >>>>> may run indefinitely) the state of objects in the graph changes as data is >>>>> processed, this is a significant issue. Our customers may have the app >>>>> fail after several hours or a few days because of these leaks. >>>>> >>>>> Scott >>>>> >>>> >>>> >> >> >> David Grieve | Principal Member of Technical Staff >> Mobile: +16033121013 >> Oracle Java Client UI and Tools >> Durham, NH 03824 >> Oracle is committed to developing practices and products that help protect the environment >> > David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From richard.bair at oracle.com Mon Oct 22 08:07:42 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 08:07:42 -0700 Subject: JavaFX Maven Plugin In-Reply-To: <50839AED.3060801@tbee.org> References: <50839AED.3060801@tbee.org> Message-ID: <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> +1 Here's the basic problem I have. The deployment team is neck deep in security audits & security fixes. What parts of the deployment code need to be open sourced in order to make forward progress on this without waiting on the deployment team? Is that a possibility, or are the changes deep in deployment code? Thanks Richard On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote: > Thanks for sharing Daniel! > > > On 2012-10-21 06:30, Daniel Zwolenski wrote: >> I have tidied up, and open sourced my JavaFX Maven plugin enough that it >> builds executable JARs (equivalent to the fx:jar ant task) and native >> bundles (equivalent to a subset of fx:deploy ant task): >> >> https://github.com/zonski/javafx-maven-plugin >> >> >> I was waiting for the bootclasspath issue to get resolved to fix this up >> properly, but since I'm getting further and further away from JFX I figured >> better to tidy it up and hand it over to the community. >> >> It does work perfectly well enough that you can use it to build real >> distributables of your app via Maven. >> >> However it wraps only the basic JavaFX plugin features (i.e. you can't >> customise many of the settings), does not support Applets (dead anyway) or >> JNLP (I've never had success getting JNLP to actually work with JFX). It >> likely also has some platform specific bugs and problems, since I have >> tested only on Windows and building MSI's. >> >> It would be relatively trivial (but time consuming) to extend it further. >> The code is simple but inelegant. Great improvements could be made if the >> JFX deployment team were to make some minor changes to their packaging API >> to make it easier to integrate with. And massive clean-ups could be made if >> they put their tools JAR in a Maven repo that they maintained. >> >> I don't have any intention to develop this further or maintain it. It is a >> good base but it would be up to someone from the community to do this if >> they want it to do anything more than it does. >> >> Note this plugin is to address the packaging/assembly issue. It does NOT >> solve the getting-jfx-on-the-classpath-issue. You still need to do whatever >> workaround you're doing now on that front. > From richard.bair at oracle.com Mon Oct 22 08:16:54 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 08:16:54 -0700 Subject: Icon Theme Support In-Reply-To: References: <50835FCB.90703@oracle.com> Message-ID: > Sorry about not sending this directly to the list. I keep tripping over > the fact that by default it only sends the reply directly to the sender. > Somebody please fix this. I'm afraid this is like tabs vs. spaces -- there will always be arguments over it but nothing will ever change :-). > ** > The Less library that Dan pointed out looks particularly interesting. I > like that you can dynamically change the style sheet. One of the things > that I currently find bothersome is that you can't map arbitrary states to > pseudo selectors. Currently you have a pseudo selector like ":hover", but > it would be nice if the developer could map any state or combination of > states to a style. > ** The reason we didn't allow for arbitrary pseudo classes was because the implementation was slower and the heuristics a harder to implement (which is also why we don't support selectors based on arbitrary property values). But in 8 the plan was to expose API so any subclass of Node could define its own set of supported pseudo classes. From richard.bair at oracle.com Mon Oct 22 08:47:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 08:47:49 -0700 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> Message-ID: <7D3F7E98-7133-45CE-BEAD-0E7E47A777AF@oracle.com> > Would you consider having a setContent(TextFieldDocument doc) method in > TextField? The length() method and the get(int, int) method could be > final, making it necessary to call super.insert() or super.delete() to get > anything done. This would provide the flexibility (likely all the > flexibility) and yet would prevent a developer from making a fairly large > set of mistakes. That is a very interesting proposal as well. Why don't we list the types of text input control scenario's we're interested in (the force all caps case is one I wouldn't have thought of, I'm sure you've seen tons of others in your time developing apps). Once we've got something of a comprehensive list, I think a clear solution that weighs the pros / cons will become more obvious to us. Richard From richard.bair at oracle.com Mon Oct 22 08:50:04 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 08:50:04 -0700 Subject: TextField Document model In-Reply-To: <50836C4C.6050407@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> Message-ID: > Firstly, regarding the options Richard sets out below, my strong preference is for option a (introduce a callback). It seems that it supports the use cases that have been raised, and it does so without introducing concerns around having a mutable Content. I think I would only sway from this position if there is a use case that just can't be done with this approach (which I'm totally willing to do if someone has one). > > Secondly, Richard mentions an important point here: one of the things that has been on the controls team backlog for way too long is support for a FormattedTextField control, and important subclasses thereof (e.g. Date/Time, Money, Zip code, etc). An ideal situation would be (in my humble opinion) for JavaFX to ship with FormattedTextField and the most critical subclasses, and for 3rd party projects such as JFXtras / JIDE to bring out all the rest. > > This approach of shipping 'simple' controls is what we did with Button / Hyperlink and RadioButton / ToggleButton - in many cases the difference in code between these classes is minimal, but it allows for way better discoverability of controls and functionality - rather than having an uber control with miles of API to toggle state / features. This approach works well, and it also looks great on our 'number of controls' fact sheet :-) > > Zooming out even further, we need to expand this discussion in one very important way: validation support. I don't have an answer for validation yet (it is certainly not a JavaFX 8.0 feature), but we have to keep it in the back of our minds lest we regret it later (ah, the joys of API development!). > > Finally, FormattedTextField is _not_ planned for JavaFX 8.0. However, I would love to have someone submit a FormattedTextField control via OpenJFX. I am more than happy to work with anyone interested in doing so, and from my perspective this would seem to be an easy control to develop - so it would be ideal for someone to get up to speed with JavaFX controls development. If anyone is interested please join the discussion and let me know. +1 to the above. I'm not opposed to having mutable content, but if the use cases are easier for people by a combination of callback / specific property additions / new controls, then I think that would be my preference. But having TextField have mutable content, rather than TextInputControl, is also an interesting twist on the idea and would perhaps be another option to weigh. Richard From richard.bair at oracle.com Mon Oct 22 08:38:21 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 08:38:21 -0700 Subject: Making JavaFX Development Faster In-Reply-To: <5085204E.7090207@media-interactive.de> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> Message-ID: This is a problem I've had with client Java since I joined the Swing team in 2004. The basic issue is that POJO's rule the day, but if you want to do binding on a POJO, how do you do it? You really have three options: - Use observable POJOs (either using JavaBean's property change listeners, or JavaFX property objects) - Wrap a POJO - Use dynamic code mangling I have at various times been lobbied for each of the above approaches. I suspect that the first and last approaches are the most pragmatic, although the dynamic code mangling solution, because it introduces black magic, is also the most unsettling. If the implementation was rock solid and always "just worked" as one would expect, then it would be an acceptable approach (but not something you'd likely see in JavaSE, which tries to avoid black magic). So for example: MyObject obj = new MyObject(); obj = BlackMagic.makeObservable(obj); obj would now magically have old-school PropertyChangeListenter methods added to it, etc, such that you could use the javafx.beans adapters. However, the javafx beans package and collections and such are part of the "base" module -- ie: they could be separated from the rest of javafx and safely used on the server side or elsewhere. Why not just use properties and such on the server side definition of classes? Or are those classes being auto-generated and thus not taking observable properties into account? Richard On Oct 22, 2012, at 3:30 AM, Werner Lehmann wrote: > Basically FX likes to have observable properties, and POJOs (domain beans) should not have an FX dependency. Sounds like a contradiction. > > Without changing the POJOS we can only wrap or subclass them. > > A wrapper would delegate all getters and setters and introduce observable properties. The property objects must use the wrapped POJOs fields to keep their values instead of having their own value field. One problem is how to know when a POJO setter is called directly? > > A subclass would add the observable properties directly. It could also override the setters, thus triggering the property invalidations. The problem here is that data has to be copied from the POJO to an instance of the POJO subclass (and possibly also the other way). > > A code generator can be built for either approach. It would FXify a set of provided POJOs. I am not sure if that is really desirable though. I really don't want to deal with a "shadow" class for each POJO class. > > FWIW, it might also be possible to use a java.lang.Proxy. In this case we still need an interface for each POJO (consisting of getters, setters, observable properties). The proxy would act like an FX view to the POJO. It can intercept the setter calls and trigger invalidations. Still there is the requirement of having POJO specific interfaces (another code generator here). > > Werner > > On 21.10.2012 19:16, Mark Fortner wrote: >> The article that Will pointed out was interesting. However, the developer >> would still end up having to write code to make their POJOs or POJO >> collections observable. It would be nice if there was a "dynamic proxy" >> that automagically made any class you sent it observable. Not sure how >> doable that is -- just thinking off the top of my head. >> >> The one thing that you would need to avoid is making your POJO have any >> JavaFX dependencies. >> >> On the issue of RAD tooling, it sounds like the Griffon team is making some >> progress with respect to making JavaFX easier. I'm not sure how well >> Griffon's Service and Controller interfaces map to JavaFX's Controller. >> >> Cheers, >> >> Mark From eva.krejcirova at oracle.com Mon Oct 22 10:06:48 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Mon, 22 Oct 2012 19:06:48 +0200 Subject: ChoiceBoxBuilder.create() is error. How to fix? In-Reply-To: <50847B83.3010604@ga2.so-net.ne.jp> References: <50847B83.3010604@ga2.so-net.ne.jp> Message-ID: <50857D28.7080104@oracle.com> Hi, This is a bug on JavaFX side, it's reported in JIRA as http://javafx-jira.kenai.com/browse/RT-24272 and we need to fix it. Unfortunately, currently there is no other solution for this than to create ChoiceBox directly (and not to use the builder). Regards, Eva On 22.10.2012 0:47, Tadashi Ohmura wrote: > Hello everyone > > ChoiceBox choiceBox = ChoiceBoxBuilder.create() > .items( FXCollections.observableArrayList("New", "Open", "Save", "Exit") ) > .build(); > > > The method create() is ambiguous for the type ChoiceBoxBuilder at Java8. > It is OK at Java7. > > Plese teach me how to fix this error? > > Best regards > Tadashi Ohmura > From markclaassenx at gmail.com Mon Oct 22 10:22:03 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Mon, 22 Oct 2012 13:22:03 -0400 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> Message-ID: I'll try to provide some examples, but, in general I think my main thing is not to box in the developer more than necessary. I don't appreciate tools that don't allow me to complete a task because they think they are smarter than me. (Which, maybe they are...but in the end I need to accomplish my goals with the tools help or not.) Even though I was pushing for the mutable content, I am leaning toward the ContentFilter approach now. If the passing of the control as a parameter is acceptable, then I think it makes a nice encapsulation; where an implementer can, in one class, deal with the data model and cursor position without needing to subclass anything. Hopefully this does not conflict with the Control / Behavior / Skin concepts. On Mon, Oct 22, 2012 at 11:50 AM, Richard Bair wrote: > > Firstly, regarding the options Richard sets out below, my strong > preference is for option a (introduce a callback). It seems that it > supports the use cases that have been raised, and it does so without > introducing concerns around having a mutable Content. I think I would only > sway from this position if there is a use case that just can't be done with > this approach (which I'm totally willing to do if someone has one). > > > > Secondly, Richard mentions an important point here: one of the things > that has been on the controls team backlog for way too long is support for > a FormattedTextField control, and important subclasses thereof (e.g. > Date/Time, Money, Zip code, etc). An ideal situation would be (in my humble > opinion) for JavaFX to ship with FormattedTextField and the most critical > subclasses, and for 3rd party projects such as JFXtras / JIDE to bring out > all the rest. > > > > This approach of shipping 'simple' controls is what we did with Button / > Hyperlink and RadioButton / ToggleButton - in many cases the difference in > code between these classes is minimal, but it allows for way better > discoverability of controls and functionality - rather than having an uber > control with miles of API to toggle state / features. This approach works > well, and it also looks great on our 'number of controls' fact sheet :-) > > > > Zooming out even further, we need to expand this discussion in one very > important way: validation support. I don't have an answer for validation > yet (it is certainly not a JavaFX 8.0 feature), but we have to keep it in > the back of our minds lest we regret it later (ah, the joys of API > development!). > > > > Finally, FormattedTextField is _not_ planned for JavaFX 8.0. However, I > would love to have someone submit a FormattedTextField control via OpenJFX. > I am more than happy to work with anyone interested in doing so, and from > my perspective this would seem to be an easy control to develop - so it > would be ideal for someone to get up to speed with JavaFX controls > development. If anyone is interested please join the discussion and let me > know. > > +1 to the above. I'm not opposed to having mutable content, but if the use > cases are easier for people by a combination of callback / specific > property additions / new controls, then I think that would be my > preference. But having TextField have mutable content, rather than > TextInputControl, is also an interesting twist on the idea and would > perhaps be another option to weigh. > > Richard From lehmann at media-interactive.de Mon Oct 22 10:23:38 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 22 Oct 2012 19:23:38 +0200 Subject: Making JavaFX Development Faster In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> Message-ID: <5085811A.4050103@media-interactive.de> Richard, On 22.10.2012 17:38, Richard Bair wrote: > MyObject obj = new MyObject(); > obj = BlackMagic.makeObservable(obj); I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) > However, the javafx beans package and collections and such are part > of the "base" module -- ie: they could be separated from the rest of > javafx and safely used on the server side or elsewhere. Why not just > use properties and such on the server side definition of classes? Or > are those classes being auto-generated and thus not taking observable > properties into account? Currently I want to avoid requiring customers to install the FX runtime serverside. That will be a moot point with JRE 7+. Which does not help the 6.x customers, especially if they are on WebLogic which is usually tied to a specific major version. Another aspect is the footprint regarding memory and bandwidth. Obviously a StringProperty requires more bytes than a String. This is not an issue (usually) when I want to display a relatively short list of beans in the UI. It gets noticeable when the server suddenly needs +X megabytes, the instantion of objects needs +Y ms (also affects deserialization), and sending them over the network takes +Z ms... Werner From kevin.rushforth at oracle.com Mon Oct 22 10:38:01 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Oct 2012 10:38:01 -0700 Subject: Memory Leaks In-Reply-To: References: <50831490.2030007@oracle.com> <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> Message-ID: <50858479.3010600@oracle.com> > Is there an easy way to get a list of issues resolved between releases? Here is a JIRA query that should do what you want (for public issues). It lists all of the issues marked as "Fixed" in the 2.2.4 release: http://javafx-jira.kenai.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+RT+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%222.2.4%22+AND+component+not+in+%28Tests%2CBuild%29+AND+issuetype+not+in+%28Test%2CTask%2CSub-task%29 Here is the same query for 2.2.6: http://javafx-jira.kenai.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+RT+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%222.2.6%22+AND+component+not+in+%28Tests%2CBuild%29+AND+issuetype+not+in+%28Test%2CTask%2CSub-task%29 -- Kevin Scott Palmer wrote: > Thanks guys. RT-23691 might be related to what we are observing. We aren't even 100% convinced that FX is leaking. I need to study it a bit more. Attempts at creating a test case that reproduces our issue have not panned out yet. > > I see that there is a patch attached to that bug. What is the state of the patch? Is it going to be applied to 2.2.6? Sound like it is already too late for 2.2.4, but even that is probably too late for my release anyway, so I'm more interested in workarounds at this point. > > Is there an easy way to get a list of issues resolved between releases? > > Thanks, > > Scott > > On 2012-10-22, at 10:06 AM, David Grieve wrote: > > >> There was a larger leak discovered late in the 2.2 release cycle. This leak was fixed but another, smaller, leak remained. Unfortunately, this smaller leak was not fixed because there simply wasn't enough time left in the release. The issue is being tracked by bug RT-23691. The issue is not yet resolved. >> >> On Oct 20, 2012, at 6:01 PM, Scott Palmer wrote: >> >> >>> Thanks for the response. 8.0 is too far away. I need to ship my app in a >>> few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 >>> yesterday. We were on 7u7 and then I discovered that there was a new >>> JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too >>> long ago with 2.2.0 and I didn't see any sort of announcements that there >>> was anything newer. >>> >>> I will try to isolate the leak. We think we are seeing >>> com.sun.javafx.css.StyleHelper$CacheEntry and >>> com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least). >>> >>> jvisualvm shows the number of those objects are always growing. Comparing >>> heap dumps we have never observed the number to decrease. >>> >>> I'm currently only able to connect to the machine running my test via >>> Remote Desktop, and the screen saver probably keep kicking in, I think that >>> is affecting the test. Is JavaFX smart enough to not render when the >>> screen is blanked? >>> >>> I will try to produce a test case. But if anyone has knowledge about this >>> that wants to share, any info is appreciated. >>> >>> Thanks,, >>> Scott >>> >>> On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles >>> wrote: >>> >>> >>>> David Grieve is the go-to expert on all things CSS, but from a >>>> higher-level perspective the general answer is always: you tell us! :-) >>>> There might be a leak we don't know about, or can't easily reproduce, and >>>> you might have just the information we need to finally get rid of that >>>> annoying leak you mention. >>>> >>>> So, please, file Jira bugs on us and we'll get to looking at them as soon >>>> as possible. If you can provide a reproducible test case that would be >>>> hugely appreciated too. >>>> >>>> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've >>>> been actively developing in the 8.0 branch for quite a long time now, and >>>> one of our primary focuses during this time has been performance (CPU and >>>> memory). In other words, there is a chance it may already be resolved (or >>>> minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0 >>>> builds available that you can test with. If you have the time and >>>> inclination, it might be worth testing against these builds to see if it is >>>> resolved. >>>> >>>> Thanks, >>>> -- Jonathan >>>> >>>> >>>> On 21/10/2012 2:10 a.m., Scott Palmer wrote: >>>> >>>> >>>>> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff? >>>>> In my application I add and remove style classes to highlight objects in >>>>> the scene graph that are in various states (selected, active, disabled, >>>>> etc). It seems that every time the style class list is changed that there >>>>> is a small leak. Since while the app runs and process data (a process that >>>>> may run indefinitely) the state of objects in the graph changes as data is >>>>> processed, this is a significant issue. Our customers may have the app >>>>> fail after several hours or a few days because of these leaks. >>>>> >>>>> Scott >>>>> >>>>> >>>> >> >> David Grieve | Principal Member of Technical Staff >> Mobile: +16033121013 >> Oracle Java Client UI and Tools >> Durham, NH 03824 >> Oracle is committed to developing practices and products that help protect the environment >> >> > > From mp at jugs.org Mon Oct 22 11:39:02 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Mon, 22 Oct 2012 20:39:02 +0200 Subject: ChoiceBoxBuilder.create() is error. How to fix? In-Reply-To: <50857D28.7080104@oracle.com> References: <50847B83.3010604@ga2.so-net.ne.jp> <50857D28.7080104@oracle.com> Message-ID: <508592C6.5060808@jugs.org> And why is this JIRA entry again secrect so that nobody outside of Oracle can read it? Am 22.10.2012 19:06, schrieb Eva Krejcirova: > Hi, > > This is a bug on JavaFX side, it's reported in JIRA as > http://javafx-jira.kenai.com/browse/RT-24272 and we need to fix it. > Unfortunately, currently there is no other solution for this than to > create ChoiceBox directly (and not to use the builder). > > Regards, > Eva > > On 22.10.2012 0:47, Tadashi Ohmura wrote: >> Hello everyone >> >> ChoiceBox choiceBox = ChoiceBoxBuilder.create() >> .items( FXCollections.observableArrayList("New", "Open", "Save", "Exit") ) >> .build(); >> >> >> The method create() is ambiguous for the type ChoiceBoxBuilder at Java8. >> It is OK at Java7. >> >> Plese teach me how to fix this error? >> >> Best regards >> Tadashi Ohmura >> -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From jonathan.giles at oracle.com Mon Oct 22 11:42:08 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 23 Oct 2012 07:42:08 +1300 Subject: ChoiceBoxBuilder.create() is error. How to fix? In-Reply-To: <508592C6.5060808@jugs.org> References: <50847B83.3010604@ga2.so-net.ne.jp> <50857D28.7080104@oracle.com> <508592C6.5060808@jugs.org> Message-ID: <50859380.7070100@oracle.com> I've made it public. Almost always internal issues are made so by mistake - I would assume it was the case here also. -- Jonathan On 23/10/2012 7:39 a.m., Dr. Michael Paus wrote: > And why is this JIRA entry again secrect so that nobody outside of > Oracle can read it? > > Am 22.10.2012 19:06, schrieb Eva Krejcirova: >> Hi, >> >> This is a bug on JavaFX side, it's reported in JIRA as >> http://javafx-jira.kenai.com/browse/RT-24272 and we need to fix it. >> Unfortunately, currently there is no other solution for this than to >> create ChoiceBox directly (and not to use the builder). >> >> Regards, >> Eva >> >> On 22.10.2012 0:47, Tadashi Ohmura wrote: >>> Hello everyone >>> >>> ChoiceBox choiceBox = ChoiceBoxBuilder.create() >>> .items( FXCollections.observableArrayList("New", "Open", "Save", "Exit") ) >>> .build(); >>> >>> >>> The method create() is ambiguous for the type ChoiceBoxBuilder at Java8. >>> It is OK at Java7. >>> >>> Plese teach me how to fix this error? >>> >>> Best regards >>> Tadashi Ohmura >>> > From danno.ferrin at shemnon.com Mon Oct 22 11:44:25 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 22 Oct 2012 12:44:25 -0600 Subject: JavaFX Maven Plugin In-Reply-To: <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> Message-ID: Don't mean to threadjack, as I am not sure what Daniel Zwolenski may want, but for my Gradle plugin there are some hard coded values that get in the way: * The parts that decide that "package/" is the magic directory to look for native support files, so I can just point it at a different directory for package * The parts that decide which pieces to assemble, so I can turn off JNLP generation and just generate .app or .exe * The parts that decide the native packages should go into the 'bundles' directory, so I can point it somewhere else. * The parts that tie the need icon names in the native bundles to the app name, so I can always name the files"applicationIcon," "installerIcon", or whatever the build configures them to. I wouldn't be surprised if these were deep in the code subject to audit. On Mon, Oct 22, 2012 at 9:07 AM, Richard Bair wrote: > +1 > > Here's the basic problem I have. The deployment team is neck deep in > security audits & security fixes. What parts of the deployment code need to > be open sourced in order to make forward progress on this without waiting > on the deployment team? Is that a possibility, or are the changes deep in > deployment code? > > Thanks > Richard > > On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote: > > > Thanks for sharing Daniel! > > > > > > On 2012-10-21 06:30, Daniel Zwolenski wrote: > >> I have tidied up, and open sourced my JavaFX Maven plugin enough that it > >> builds executable JARs (equivalent to the fx:jar ant task) and native > >> bundles (equivalent to a subset of fx:deploy ant task): > >> > >> https://github.com/zonski/javafx-maven-plugin > >> > >> > >> I was waiting for the bootclasspath issue to get resolved to fix this up > >> properly, but since I'm getting further and further away from JFX I > figured > >> better to tidy it up and hand it over to the community. > >> > >> It does work perfectly well enough that you can use it to build real > >> distributables of your app via Maven. > >> > >> However it wraps only the basic JavaFX plugin features (i.e. you can't > >> customise many of the settings), does not support Applets (dead anyway) > or > >> JNLP (I've never had success getting JNLP to actually work with JFX). It > >> likely also has some platform specific bugs and problems, since I have > >> tested only on Windows and building MSI's. > >> > >> It would be relatively trivial (but time consuming) to extend it > further. > >> The code is simple but inelegant. Great improvements could be made if > the > >> JFX deployment team were to make some minor changes to their packaging > API > >> to make it easier to integrate with. And massive clean-ups could be > made if > >> they put their tools JAR in a Maven repo that they maintained. > >> > >> I don't have any intention to develop this further or maintain it. It > is a > >> good base but it would be up to someone from the community to do this if > >> they want it to do anything more than it does. > >> > >> Note this plugin is to address the packaging/assembly issue. It does NOT > >> solve the getting-jfx-on-the-classpath-issue. You still need to do > whatever > >> workaround you're doing now on that front. > > > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From jonathan.giles at oracle.com Mon Oct 22 11:52:54 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 23 Oct 2012 07:52:54 +1300 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> Message-ID: <50859606.9000600@oracle.com> On 23/10/2012 6:22 a.m., Mark Claassen wrote: > Even though I was pushing for the mutable content, I am leaning toward the > ContentFilter approach now. If the passing of the control as a parameter > is acceptable, then I think it makes a nice encapsulation; where an > implementer can, in one class, deal with the data model and cursor position > without needing to subclass anything. Hopefully this does not conflict > with the Control / Behavior / Skin concepts. No, this approach wouldn't impact on the Control / Skin / Behavior concept - it seems totally reasonable. Everything you're discussing would be API on the Control. I'm not entirely clear on your ContentFilter specification, but I figure we can cross that bridge when we get nearer to it, rather than try to design API from afar. -- Jonathan From markclaassenx at gmail.com Mon Oct 22 12:41:58 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Mon, 22 Oct 2012 15:41:58 -0400 Subject: TextField Document model In-Reply-To: <50859606.9000600@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50859606.9000600@oracle.com> Message-ID: Looking at the source for TextInputControl, I see I need to refine my API ideas a bit. The cursor control is, of course, also manipulated from other methods (like replaceSelection) in the controls. I need to reconcile these regardless of which API we choose. On Mon, Oct 22, 2012 at 2:52 PM, Jonathan Giles wrote: > On 23/10/2012 6:22 a.m., Mark Claassen wrote: > >> Even though I was pushing for the mutable content, I am leaning toward the >> ContentFilter approach now. If the passing of the control as a parameter >> is acceptable, then I think it makes a nice encapsulation; where an >> implementer can, in one class, deal with the data model and cursor >> position >> without needing to subclass anything. Hopefully this does not conflict >> with the Control / Behavior / Skin concepts. >> > No, this approach wouldn't impact on the Control / Skin / Behavior concept > - it seems totally reasonable. Everything you're discussing would be API on > the Control. > > I'm not entirely clear on your ContentFilter specification, but I figure > we can cross that bridge when we get nearer to it, rather than try to > design API from afar. > > -- Jonathan > From zonski at gmail.com Mon Oct 22 13:44:00 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 23 Oct 2012 07:44:00 +1100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> Message-ID: Similar issues (give or take) for Maven as Danno has outlined. More specifically, I use the classes in: com.sun.javafx.tools.packager.* com.sun.javafx.tools.packager.bundlers.* Mostly this code just needs minor tweaks. As Danno said, things like it's not possible to turn off JNLP, and there are some assumptions about directories and the like that would ideally be configurable. The (native) Bundler stuff is pretty hard to work with. It's suffering a little from being an after thought I think, so not quite as clean as the rest. It may just be that I'm missing something (working it out through a decompiler is not the best way to understand someone else's code) but I struggled to customise much of the native installer steps. As well as needing changes, ideally someone writing this plugin would have docco on this, and/or be able to shoot Igor questions like "How do I set the vendor for a native installer?" and "How come when I override the app-name it throws this error?", etc. The other side of it is that I can't distribute this JAR (i.e. put it in a Maven repo). The old legal problem. As such, I have to use reflection for everything, which is a slow and painful way to code it. e.g. Object deployParams = newInstance(deployParamsClass); invoke(deployParams, "setOutdir", outputDir); invoke(deployParams, "setOutfile", appDistributionName); invoke(deployParams, "setApplicationClass", mainClass); Instead of DeployParams params = new DeployParams(); params.setOutdir(outDir); params.setOutfile(appDistributionName); params.setApplicationClass(mainClass); See this: https://github.com/zonski/javafx-maven-plugin/blob/master/src/main/java/com/zenjava/javafx/maven/plugin/JfxToolsWrapper.java Obviously makes it slower to write and harder and a disincentive to anyone wanting to develop it further. Simple solution, you guys put the 'tools' JAR up on a Maven repo (a "Maven Repo" is any public webserver - you do NOT need to install anything or run any processes other than an Apace, just follow a simple directory structure, ridiculously easy, done in 10 minutes). Alternatively, you relax the licence on this JAR and say it's ok for us plebs to put it in a Maven repo. The reflection works though. On Tue, Oct 23, 2012 at 5:44 AM, Danno Ferrin wrote: > Don't mean to threadjack, as I am not sure what Daniel Zwolenski may want, > but for my Gradle plugin there are some hard coded values that get in the > way: > > * The parts that decide that "package/" is the magic directory to > look for native support files, so I can just point it at a different > directory for package > * The parts that decide which pieces to assemble, so I can turn off JNLP > generation and just generate .app or .exe > * The parts that decide the native packages should go into the 'bundles' > directory, so I can point it somewhere else. > * The parts that tie the need icon names in the native bundles to the app > name, so I can always name the files"applicationIcon," "installerIcon", or > whatever the build configures them to. > > I wouldn't be surprised if these were deep in the code subject to audit. > > On Mon, Oct 22, 2012 at 9:07 AM, Richard Bair >wrote: > > > +1 > > > > Here's the basic problem I have. The deployment team is neck deep in > > security audits & security fixes. What parts of the deployment code need > to > > be open sourced in order to make forward progress on this without waiting > > on the deployment team? Is that a possibility, or are the changes deep in > > deployment code? > > > > Thanks > > Richard > > > > On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote: > > > > > Thanks for sharing Daniel! > > > > > > > > > On 2012-10-21 06:30, Daniel Zwolenski wrote: > > >> I have tidied up, and open sourced my JavaFX Maven plugin enough that > it > > >> builds executable JARs (equivalent to the fx:jar ant task) and native > > >> bundles (equivalent to a subset of fx:deploy ant task): > > >> > > >> https://github.com/zonski/javafx-maven-plugin > > >> > > >> > > >> I was waiting for the bootclasspath issue to get resolved to fix this > up > > >> properly, but since I'm getting further and further away from JFX I > > figured > > >> better to tidy it up and hand it over to the community. > > >> > > >> It does work perfectly well enough that you can use it to build real > > >> distributables of your app via Maven. > > >> > > >> However it wraps only the basic JavaFX plugin features (i.e. you can't > > >> customise many of the settings), does not support Applets (dead > anyway) > > or > > >> JNLP (I've never had success getting JNLP to actually work with JFX). > It > > >> likely also has some platform specific bugs and problems, since I have > > >> tested only on Windows and building MSI's. > > >> > > >> It would be relatively trivial (but time consuming) to extend it > > further. > > >> The code is simple but inelegant. Great improvements could be made if > > the > > >> JFX deployment team were to make some minor changes to their packaging > > API > > >> to make it easier to integrate with. And massive clean-ups could be > > made if > > >> they put their tools JAR in a Maven repo that they maintained. > > >> > > >> I don't have any intention to develop this further or maintain it. It > > is a > > >> good base but it would be up to someone from the community to do this > if > > >> they want it to do anything more than it does. > > >> > > >> Note this plugin is to address the packaging/assembly issue. It does > NOT > > >> solve the getting-jfx-on-the-classpath-issue. You still need to do > > whatever > > >> workaround you're doing now on that front. > > > > > > > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > From zonski at gmail.com Mon Oct 22 14:54:58 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 23 Oct 2012 08:54:58 +1100 Subject: Memory Leaks In-Reply-To: <50858479.3010600@oracle.com> References: <50831490.2030007@oracle.com> <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> <50858479.3010600@oracle.com> Message-ID: https://confluence.atlassian.com/display/JIRA/Creating+Release+Notes On Tue, Oct 23, 2012 at 4:38 AM, Kevin Rushforth wrote: > > Is there an easy way to get a list of issues resolved between releases? > > Here is a JIRA query that should do what you want (for public issues). It > lists all of the issues marked as "Fixed" in the 2.2.4 release: > > http://javafx-jira.kenai.com/**secure/IssueNavigator.jspa?** > reset=true&jqlQuery=project+%**3D+RT+AND+resolution+%3D+** > Fixed+AND+fixVersion+%3D+%222.**2.4%22+AND+component+not+in+%** > 28Tests%2CBuild%29+AND+**issuetype+not+in+%28Test%**2CTask%2CSub-task%29 > > Here is the same query for 2.2.6: > > http://javafx-jira.kenai.com/**secure/IssueNavigator.jspa?** > reset=true&jqlQuery=project+%**3D+RT+AND+resolution+%3D+** > Fixed+AND+fixVersion+%3D+%222.**2.6%22+AND+component+not+in+%** > 28Tests%2CBuild%29+AND+**issuetype+not+in+%28Test%**2CTask%2CSub-task%29 > > > -- Kevin > > > Scott Palmer wrote: > >> Thanks guys. RT-23691 might be related to what we are observing. We >> aren't even 100% convinced that FX is leaking. I need to study it a bit >> more. Attempts at creating a test case that reproduces our issue have not >> panned out yet. >> >> I see that there is a patch attached to that bug. What is the state of >> the patch? Is it going to be applied to 2.2.6? Sound like it is already >> too late for 2.2.4, but even that is probably too late for my release >> anyway, so I'm more interested in workarounds at this point. >> >> Is there an easy way to get a list of issues resolved between releases? >> >> Thanks, >> >> Scott >> >> On 2012-10-22, at 10:06 AM, David Grieve wrote: >> >> >> >>> There was a larger leak discovered late in the 2.2 release cycle. This >>> leak was fixed but another, smaller, leak remained. Unfortunately, this >>> smaller leak was not fixed because there simply wasn't enough time left in >>> the release. The issue is being tracked by bug RT-23691. The issue is not >>> yet resolved. >>> >>> On Oct 20, 2012, at 6:01 PM, Scott Palmer wrote: >>> >>> >>> >>>> Thanks for the response. 8.0 is too far away. I need to ship my app >>>> in a >>>> few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3 >>>> yesterday. We were on 7u7 and then I discovered that there was a new >>>> JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not >>>> too >>>> long ago with 2.2.0 and I didn't see any sort of announcements that >>>> there >>>> was anything newer. >>>> >>>> I will try to isolate the leak. We think we are seeing >>>> com.sun.javafx.css.**StyleHelper$CacheEntry and >>>> com.sun.javafx.css.**StyleHelper$CalculatedValue leaking (at least). >>>> >>>> jvisualvm shows the number of those objects are always growing. >>>> Comparing >>>> heap dumps we have never observed the number to decrease. >>>> >>>> I'm currently only able to connect to the machine running my test via >>>> Remote Desktop, and the screen saver probably keep kicking in, I think >>>> that >>>> is affecting the test. Is JavaFX smart enough to not render when the >>>> screen is blanked? >>>> >>>> I will try to produce a test case. But if anyone has knowledge about >>>> this >>>> that wants to share, any info is appreciated. >>>> >>>> Thanks,, >>>> Scott >>>> >>>> On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles >>>> **wrote: >>>> >>>> >>>> >>>>> David Grieve is the go-to expert on all things CSS, but from a >>>>> higher-level perspective the general answer is always: you tell us! :-) >>>>> There might be a leak we don't know about, or can't easily reproduce, >>>>> and >>>>> you might have just the information we need to finally get rid of that >>>>> annoying leak you mention. >>>>> >>>>> So, please, file Jira bugs on us and we'll get to looking at them as >>>>> soon >>>>> as possible. If you can provide a reproducible test case that would be >>>>> hugely appreciated too. >>>>> >>>>> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've >>>>> been actively developing in the 8.0 branch for quite a long time now, >>>>> and >>>>> one of our primary focuses during this time has been performance (CPU >>>>> and >>>>> memory). In other words, there is a chance it may already be resolved >>>>> (or >>>>> minimised) in the 8.0 branch. I know it is a lot to ask, but there are >>>>> 8.0 >>>>> builds available that you can test with. If you have the time and >>>>> inclination, it might be worth testing against these builds to see if >>>>> it is >>>>> resolved. >>>>> >>>>> Thanks, >>>>> -- Jonathan >>>>> >>>>> >>>>> On 21/10/2012 2:10 a.m., Scott Palmer wrote: >>>>> >>>>> >>>>> >>>>>> Are there known leaks in 2.2.3 with regards to CSS and style cache >>>>>> stuff? >>>>>> In my application I add and remove style classes to highlight objects >>>>>> in >>>>>> the scene graph that are in various states (selected, active, >>>>>> disabled, >>>>>> etc). It seems that every time the style class list is changed that >>>>>> there >>>>>> is a small leak. Since while the app runs and process data (a >>>>>> process that >>>>>> may run indefinitely) the state of objects in the graph changes as >>>>>> data is >>>>>> processed, this is a significant issue. Our customers may have the >>>>>> app >>>>>> fail after several hours or a few days because of these leaks. >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> David Grieve | Principal Member of Technical Staff >>> Mobile: +16033121013 Oracle Java Client UI and Tools >>> Durham, NH 03824 Oracle is committed to >>> developing practices and products that help protect the environment >>> >>> >>> >> >> >> > From omurata at ga2.so-net.ne.jp Mon Oct 22 15:49:33 2012 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Tue, 23 Oct 2012 07:49:33 +0900 Subject: ChoiceBoxBuilder.create() is error. How to fix? In-Reply-To: <50857D28.7080104@oracle.com> References: <50847B83.3010604@ga2.so-net.ne.jp> <50857D28.7080104@oracle.com> Message-ID: <5085CD7D.7050505@ga2.so-net.ne.jp> Thank you, Eva Krejcirova I m waiting for fixing. Best Regards Tadashi Ohmura (2012/10/23 2:06), Eva Krejcirova wrote: > Hi, > > This is a bug on JavaFX side, it's reported in JIRA as > http://javafx-jira.kenai.com/browse/RT-24272 and we need to fix it. > Unfortunately, currently there is no other solution for this than to > create ChoiceBox directly (and not to use the builder). > > Regards, > Eva > > On 22.10.2012 0:47, Tadashi Ohmura wrote: >> Hello everyone >> >> ChoiceBox choiceBox = ChoiceBoxBuilder.create() >> .items( FXCollections.observableArrayList("New", "Open", "Save", "Exit") ) >> .build(); >> >> >> The method create() is ambiguous for the type ChoiceBoxBuilder at Java8. >> It is OK at Java7. >> >> Plese teach me how to fix this error? >> >> Best regards >> Tadashi Ohmura >> > > From pedro.duquevieira at gmail.com Mon Oct 22 16:34:53 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 23 Oct 2012 00:34:53 +0100 Subject: Oracle ADF Mobile Message-ID: Hi, I saw this article about Oracle ADF Mobile: http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 saying this would help extend Java applications to mobile platforms like ios and android. As i know nothing about ADF, I was wondering whether JavaFX developers will get anything out of it? Thanks in advance, best regards, -- Pedro Duque Vieira From John_Smith at symantec.com Mon Oct 22 16:36:17 2012 From: John_Smith at symantec.com (John Smith) Date: Mon, 22 Oct 2012 16:36:17 -0700 Subject: Ensemble in Mac App Store In-Reply-To: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Really nice work on packaging Ensemble and placing it in the Mac App Store. If one wants to package an application for the Mac App Store, which build must be used? I'm guessing it is JDK 7u12 / FX 2.2.6 because that fixes specific Jira's which were targeted towards packaging native binaries for the Mac App Store? At https://forums.oracle.com/forums/message.jspa?messageID=10621531 on Oct 8, igor stated "JavaFX tools is way to go. At least long term (as you need to use current beta from http://jdk7.java.net/download.html and it might have bugs)." However, if you use a non-production release, like http://jdk7.java.net/download.html or http://jdk8.java.net/download.html, then you must agree to the pre-production license http://jdk7.java.net/license.html. This license obviously wouldn't work for something packaged for app store delivery due to the following clause: "We grant You a revocable, nonexclusive, nontransferable, royalty-free and limited right to (a) use one (1) copy of the binary portions of the Programs for the sole purpose of internal non-production and non-commercial evaluation and testing of the Programs, including, developing no more than a single prototype of each of Your applications" So, currently, is it only Oracle which can publish JavaFX applications in the Mac App Store? And the rest of the world will be able to do the packaging in Spring when JDK 7u12 / FX 2.2.6 is released? Or is there some other way around this? How was Ensemble packaged for instance? From pedro.duquevieira at gmail.com Mon Oct 22 16:42:00 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 23 Oct 2012 00:42:00 +0100 Subject: TableView - listening to events on table headers Message-ID: Hi, In my app I have to listen to mouse events on table headers, I've tried to come up with a good solution to this but haven't found any. Posting in the JavaFX OTN forums also did not bring any better solution. As it is the only solution I see is replacing the headers via setGraphic method of TableColumn and attaching listeners to what I pass in to the setGraphic, even though I will end up replacing the TableColumn header with the same type of node as was previously present, so I end up calling setGraphic only for the sake of being able to attach listeners. This looks ugly. Is there any better solution for this? My use case is: 1- user mouse clicks the a table header to select a column 2- column gets selected. 3- Selected column is visually highlighted. Thanks, -- Pedro Duque Vieira From hang.vo at oracle.com Mon Oct 22 17:18:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 23 Oct 2012 00:18:35 +0000 Subject: hg: openjfx/8/graphics/rt: Added com.sun API for listening to cell changes on a VirtualFlow. Also VirtualFlow performance improvements. Both by Richard Bair from JavaOne demo work. Message-ID: <20121023001839.07425474AD@hg.openjdk.java.net> Changeset: 732db3a8f698 Author: "Jasper Potts" Date: 2012-10-22 17:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/732db3a8f698 Added com.sun API for listening to cell changes on a VirtualFlow. Also VirtualFlow performance improvements. Both by Richard Bair from JavaOne demo work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Mon Oct 22 17:47:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 23 Oct 2012 00:47:40 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed com.sun API for listening to cell changes on a VirtualFlow, should have had getters and setters not public field. Message-ID: <20121023004741.BF2E2474AF@hg.openjdk.java.net> Changeset: 7e671f637e68 Author: "Jasper Potts" Date: 2012-10-22 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7e671f637e68 Fixed com.sun API for listening to cell changes on a VirtualFlow, should have had getters and setters not public field. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Mon Oct 22 18:32:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 23 Oct 2012 01:32:37 +0000 Subject: hg: openjfx/8/graphics/rt: Added ConferenceScheduleApp that was demoed at JavaOne 2012 to new apps experiments directory Message-ID: <20121023013239.401FB474B2@hg.openjdk.java.net> Changeset: 3a9f57c30378 Author: "Jasper Potts" Date: 2012-10-22 18:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3a9f57c30378 Added ConferenceScheduleApp that was demoed at JavaOne 2012 to new apps experiments directory + apps/experiments/ConferenceScheduleApp/build.xml + apps/experiments/ConferenceScheduleApp/manifest.mf + apps/experiments/ConferenceScheduleApp/nbproject/build-impl.xml + apps/experiments/ConferenceScheduleApp/nbproject/configs/Run_as_WebStart.properties + apps/experiments/ConferenceScheduleApp/nbproject/configs/Run_in_Browser.properties + apps/experiments/ConferenceScheduleApp/nbproject/configs/Test_Mode.properties + apps/experiments/ConferenceScheduleApp/nbproject/genfiles.properties + apps/experiments/ConferenceScheduleApp/nbproject/jfx-impl.xml + apps/experiments/ConferenceScheduleApp/nbproject/project.properties + apps/experiments/ConferenceScheduleApp/nbproject/project.xml + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/AutoLogoutLightBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/ConferenceScheduleApp.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/Page.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/PageContainer.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/PlatformIntegration.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet-Desktop.css + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet.css + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/Theme.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/TouchClickedEventAvoider.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/TouchScrollEventSynthesizer.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/AsciiBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/CheckBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/EmailBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/EventPopoverPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/LoginProgressBarSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/NoopScrollBarSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/Popover.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverTreeList.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/ResizableWrappingText.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/ScrollPaneSkin3.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SearchBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SimpleVBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SymbolBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TestPopover.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TestVirtualKeyboard.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TreeBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/VirtualKeyboard.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/VirtualKeyboardSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/DataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/SessionManagement.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/TwitterJson.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/DevoxxDataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/GetConferenceDataTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/LoginTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/TestDataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/UpdateScheduleTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/back-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/backspace-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/blue-linen.jpg + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/cancel.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/cancel at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/capslock-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/done.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/done at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/duke48.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/enter-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-popover.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-popover at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-shadow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-shadow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/ios-list-transparent.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/ios-list-transparent at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-blue-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-blue-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-gray-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-grey-button-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-red-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-red-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-background-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-background.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-strap-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-strap.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-guest-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-guest-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-login-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-login-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-title-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-title.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/need-to-be-logged-in.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/pic-shadow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/pic-shadow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-blue-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-blue-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-light-blue-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-light-blue-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-list-border.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-list-border at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow-empty.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow-empty at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/refresh-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/refresh-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/rough_diagonal.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/rough_diagonal_blue.jpg + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search-clear.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search-clear at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/shift-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/short-key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/short-key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/special-key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/special-key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/star.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tick.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tick at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bottom-fade.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble-tooth.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble-tooth at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-dot.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-dot at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-presentation.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-presentation at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-top-fade.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-dark-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-dark.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-hide.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-light-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-light.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-medium-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-medium.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Availability.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Event.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/FilterType.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Level.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Room.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Session.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/SessionTime.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/SessionType.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Speaker.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Track.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Tweet.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Venue.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/CatalogPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/FilterSessionsByTrackPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/FilterSessionsByTypePage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/LoginScreen.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SearchFilterPopoverPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SessionFilterCriteria.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SessionListPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SocialPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SpeakersPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/TimelinePage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/TracksPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/VenueRoomPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/VenuesPage.java From Richard.Bair at oracle.com Mon Oct 22 18:30:43 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 18:30:43 -0700 Subject: Ensemble in Mac App Store In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Scott, can you fill us in on the story around how you went about packaging Ensemble? What version of Java did you have to use? Cheers Richard On Oct 22, 2012, at 4:36 PM, John Smith wrote: > Really nice work on packaging Ensemble and placing it in the Mac App Store. > > If one wants to package an application for the Mac App Store, which build must be used? > > I'm guessing it is JDK 7u12 / FX 2.2.6 because that fixes specific Jira's which were targeted towards packaging native binaries for the Mac App Store? > > At https://forums.oracle.com/forums/message.jspa?messageID=10621531 on Oct 8, igor stated "JavaFX tools is way to go. At least long term (as you need to use current beta from http://jdk7.java.net/download.html and it might have bugs)." > > However, if you use a non-production release, like http://jdk7.java.net/download.html or http://jdk8.java.net/download.html, then you must agree to the pre-production license http://jdk7.java.net/license.html. This license obviously wouldn't work for something packaged for app store delivery due to the following clause: "We grant You a revocable, nonexclusive, nontransferable, royalty-free and limited right to (a) use one (1) copy of the binary portions of the Programs for the sole purpose of internal non-production and non-commercial evaluation and testing of the Programs, including, developing no more than a single prototype of each of Your applications" > > So, currently, is it only Oracle which can publish JavaFX applications in the Mac App Store? > And the rest of the world will be able to do the packaging in Spring when JDK 7u12 / FX 2.2.6 is released? > Or is there some other way around this? How was Ensemble packaged for instance? From richard.bair at oracle.com Mon Oct 22 18:34:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 18:34:31 -0700 Subject: Oracle ADF Mobile In-Reply-To: References: Message-ID: ADF Mobile, at present, is implemented such that there is a JVM and version of some Java libraries (I believe CDC subset), and uses the native web browser for rendering content. We are in close communication with the ADF mobile team. Richard On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: > Hi, > > I saw this article about Oracle ADF Mobile: > http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 > saying > this would help extend Java applications to mobile platforms like ios and > android. > > As i know nothing about ADF, I was wondering whether JavaFX developers will > get anything out of it? > > Thanks in advance, best regards, > > -- > Pedro Duque Vieira From richard.bair at oracle.com Mon Oct 22 18:41:43 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 22 Oct 2012 18:41:43 -0700 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> Message-ID: <89603DFD-28A4-4AD1-B8A5-69D8DFB18BD5@oracle.com> OK, I will follow up. I'm out of the office the rest of the week on a customer visit, but will attempt to follow up on all the other threads while I'm out. Cheers Richard On Oct 22, 2012, at 1:44 PM, Daniel Zwolenski wrote: > Similar issues (give or take) for Maven as Danno has outlined. > > More specifically, I use the classes in: > > com.sun.javafx.tools.packager.* > com.sun.javafx.tools.packager.bundlers.* > > Mostly this code just needs minor tweaks. As Danno said, things like it's not possible to turn off JNLP, and there are some assumptions about directories and the like that would ideally be configurable. > > The (native) Bundler stuff is pretty hard to work with. It's suffering a little from being an after thought I think, so not quite as clean as the rest. It may just be that I'm missing something (working it out through a decompiler is not the best way to understand someone else's code) but I struggled to customise much of the native installer steps. As well as needing changes, ideally someone writing this plugin would have docco on this, and/or be able to shoot Igor questions like "How do I set the vendor for a native installer?" and "How come when I override the app-name it throws this error?", etc. > > The other side of it is that I can't distribute this JAR (i.e. put it in a Maven repo). The old legal problem. As such, I have to use reflection for everything, which is a slow and painful way to code it. > > e.g. > > Object deployParams = newInstance(deployParamsClass); > invoke(deployParams, "setOutdir", outputDir); > invoke(deployParams, "setOutfile", appDistributionName); > invoke(deployParams, "setApplicationClass", mainClass); > > Instead of > > DeployParams params = new DeployParams(); > params.setOutdir(outDir); > params.setOutfile(appDistributionName); > params.setApplicationClass(mainClass); > > See this: https://github.com/zonski/javafx-maven-plugin/blob/master/src/main/java/com/zenjava/javafx/maven/plugin/JfxToolsWrapper.java > > Obviously makes it slower to write and harder and a disincentive to anyone wanting to develop it further. > > Simple solution, you guys put the 'tools' JAR up on a Maven repo (a "Maven Repo" is any public webserver - you do NOT need to install anything or run any processes other than an Apace, just follow a simple directory structure, ridiculously easy, done in 10 minutes). > > Alternatively, you relax the licence on this JAR and say it's ok for us plebs to put it in a Maven repo. > > The reflection works though. > > > > > > > On Tue, Oct 23, 2012 at 5:44 AM, Danno Ferrin wrote: > Don't mean to threadjack, as I am not sure what Daniel Zwolenski may want, > but for my Gradle plugin there are some hard coded values that get in the > way: > > * The parts that decide that "package/" is the magic directory to > look for native support files, so I can just point it at a different > directory for package > * The parts that decide which pieces to assemble, so I can turn off JNLP > generation and just generate .app or .exe > * The parts that decide the native packages should go into the 'bundles' > directory, so I can point it somewhere else. > * The parts that tie the need icon names in the native bundles to the app > name, so I can always name the files"applicationIcon," "installerIcon", or > whatever the build configures them to. > > I wouldn't be surprised if these were deep in the code subject to audit. > > On Mon, Oct 22, 2012 at 9:07 AM, Richard Bair wrote: > > > +1 > > > > Here's the basic problem I have. The deployment team is neck deep in > > security audits & security fixes. What parts of the deployment code need to > > be open sourced in order to make forward progress on this without waiting > > on the deployment team? Is that a possibility, or are the changes deep in > > deployment code? > > > > Thanks > > Richard > > > > On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote: > > > > > Thanks for sharing Daniel! > > > > > > > > > On 2012-10-21 06:30, Daniel Zwolenski wrote: > > >> I have tidied up, and open sourced my JavaFX Maven plugin enough that it > > >> builds executable JARs (equivalent to the fx:jar ant task) and native > > >> bundles (equivalent to a subset of fx:deploy ant task): > > >> > > >> https://github.com/zonski/javafx-maven-plugin > > >> > > >> > > >> I was waiting for the bootclasspath issue to get resolved to fix this up > > >> properly, but since I'm getting further and further away from JFX I > > figured > > >> better to tidy it up and hand it over to the community. > > >> > > >> It does work perfectly well enough that you can use it to build real > > >> distributables of your app via Maven. > > >> > > >> However it wraps only the basic JavaFX plugin features (i.e. you can't > > >> customise many of the settings), does not support Applets (dead anyway) > > or > > >> JNLP (I've never had success getting JNLP to actually work with JFX). It > > >> likely also has some platform specific bugs and problems, since I have > > >> tested only on Windows and building MSI's. > > >> > > >> It would be relatively trivial (but time consuming) to extend it > > further. > > >> The code is simple but inelegant. Great improvements could be made if > > the > > >> JFX deployment team were to make some minor changes to their packaging > > API > > >> to make it easier to integrate with. And massive clean-ups could be > > made if > > >> they put their tools JAR in a Maven repo that they maintained. > > >> > > >> I don't have any intention to develop this further or maintain it. It > > is a > > >> good base but it would be up to someone from the community to do this if > > >> they want it to do anything more than it does. > > >> > > >> Note this plugin is to address the packaging/assembly issue. It does NOT > > >> solve the getting-jfx-on-the-classpath-issue. You still need to do > > whatever > > >> workaround you're doing now on that front. > > > > > > > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > From goddard at seznam.cz Tue Oct 23 03:27:35 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Tue, 23 Oct 2012 12:27:35 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Oracle=20ADF=20Mobile?= In-Reply-To: Message-ID: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> Is this a reaction on IBM Worklight? http://www-01.ibm.com/software/mobile-solutions/worklight/ In any case, ADF sounds promising :) Jiri ------------ P?vodn? zpr?va ------------ Od: Richard Bair P?edm?t: Re: Oracle ADF Mobile Datum: 23.10.2012 05:11:41 ---------------------------------------- ADF Mobile, at present, is implemented such that there is a JVM and version of some Java libraries (I believe CDC subset), and uses the native web browser for rendering content. We are in close communication with the ADF mobile team. Richard On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: > Hi, > > I saw this article about Oracle ADF Mobile: > http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 > saying > this would help extend Java applications to mobile platforms like ios and > android. > > As i know nothing about ADF, I was wondering whether JavaFX developers will > get anything out of it? > > Thanks in advance, best regards, > > -- > Pedro Duque Vieira From lehmann at media-interactive.de Tue Oct 23 04:01:44 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 23 Oct 2012 13:01:44 +0200 Subject: MenuButton arrow position Message-ID: <50867918.5060403@media-interactive.de> Hi, MenuButton does not play nice if the graphic is displayed TOP or BOTTOM: http://www.imagebam.com/image/8c4a8b216588054 Usually the arrow button is located to the right of the button text. Instead it is on the far right side, with too much gap in between. Should this be treated as a bug, or is this on purpose? Also, is there a workaround to move the arrow to the "right" position? Thanks. Werner From richard.bair at oracle.com Tue Oct 23 07:28:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 23 Oct 2012 07:28:39 -0700 Subject: Oracle ADF Mobile In-Reply-To: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> Message-ID: As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. Richard On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: > Is this a reaction on IBM Worklight? > http://www-01.ibm.com/software/mobile-solutions/worklight/ > > In any case, ADF sounds promising :) > > Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Richard Bair > P?edm?t: Re: Oracle ADF Mobile > Datum: 23.10.2012 05:11:41 > ---------------------------------------- > ADF Mobile, at present, is implemented such that there is a JVM and version of > some Java libraries (I believe CDC subset), and uses the native web browser for > rendering content. We are in close communication with the ADF mobile team. > > Richard > > On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: > >> Hi, >> >> I saw this article about Oracle ADF Mobile: >> > http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >> saying >> this would help extend Java applications to mobile platforms like ios and >> android. >> >> As i know nothing about ADF, I was wondering whether JavaFX developers will >> get anything out of it? >> >> Thanks in advance, best regards, >> >> -- >> Pedro Duque Vieira > > > From tbee at tbee.org Tue Oct 23 07:52:47 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 23 Oct 2012 16:52:47 +0200 Subject: Oracle ADF Mobile In-Reply-To: References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> Message-ID: <5086AF3F.5010507@tbee.org> Seems that ADF and JavaFX are possibly aiming at the same market; cross-platform mobile apps. Tom On 2012-10-23 16:28, Richard Bair wrote: > As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. > > Richard > > On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: > >> Is this a reaction on IBM Worklight? >> http://www-01.ibm.com/software/mobile-solutions/worklight/ >> >> In any case, ADF sounds promising :) >> >> Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Richard Bair >> P?edm?t: Re: Oracle ADF Mobile >> Datum: 23.10.2012 05:11:41 >> ---------------------------------------- >> ADF Mobile, at present, is implemented such that there is a JVM and version of >> some Java libraries (I believe CDC subset), and uses the native web browser for >> rendering content. We are in close communication with the ADF mobile team. >> >> Richard >> >> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >> >>> Hi, >>> >>> I saw this article about Oracle ADF Mobile: >>> >> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>> saying >>> this would help extend Java applications to mobile platforms like ios and >>> android. >>> >>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>> get anything out of it? >>> >>> Thanks in advance, best regards, >>> >>> -- >>> Pedro Duque Vieira >> >> From richard.bair at oracle.com Tue Oct 23 08:04:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 23 Oct 2012 08:04:22 -0700 Subject: Oracle ADF Mobile In-Reply-To: <5086AF3F.5010507@tbee.org> References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> <5086AF3F.5010507@tbee.org> Message-ID: I think they are quite different. ADF is really aimed at folks who are using / extending Oracle Middleware, whereas JavaFX is a platform play. Richard On Oct 23, 2012, at 7:52 AM, Tom Eugelink wrote: > Seems that ADF and JavaFX are possibly aiming at the same market; cross-platform mobile apps. > > Tom > > > > On 2012-10-23 16:28, Richard Bair wrote: >> As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. >> >> Richard >> >> On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: >> >>> Is this a reaction on IBM Worklight? >>> http://www-01.ibm.com/software/mobile-solutions/worklight/ >>> >>> In any case, ADF sounds promising :) >>> >>> Jiri >>> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Richard Bair >>> P?edm?t: Re: Oracle ADF Mobile >>> Datum: 23.10.2012 05:11:41 >>> ---------------------------------------- >>> ADF Mobile, at present, is implemented such that there is a JVM and version of >>> some Java libraries (I believe CDC subset), and uses the native web browser for >>> rendering content. We are in close communication with the ADF mobile team. >>> >>> Richard >>> >>> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >>> >>>> Hi, >>>> >>>> I saw this article about Oracle ADF Mobile: >>>> >>> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>>> saying >>>> this would help extend Java applications to mobile platforms like ios and >>>> android. >>>> >>>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>>> get anything out of it? >>>> >>>> Thanks in advance, best regards, >>>> >>>> -- >>>> Pedro Duque Vieira >>> >>> > From randahl at rockit.dk Tue Oct 23 08:13:27 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 23 Oct 2012 17:13:27 +0200 Subject: Oracle ADF Mobile In-Reply-To: <5086AF3F.5010507@tbee.org> References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> <5086AF3F.5010507@tbee.org> Message-ID: Tom, as someone who has worked extensively with both JSF and JavaFX, I can assure you that a JSF-based approach like ADF will never get even close to the flexibility and power of JavaFX. Its like comparing bamboo scaffolds to the Burj Khalifa. We need a true, rich client approach on mobile devices, and only JavaFX has a real chance of delivering that at the moment. Randahl On Oct 23, 2012, at 16:52 , Tom Eugelink wrote: > Seems that ADF and JavaFX are possibly aiming at the same market; cross-platform mobile apps. > > Tom > > > > On 2012-10-23 16:28, Richard Bair wrote: >> As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. >> >> Richard >> >> On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: >> >>> Is this a reaction on IBM Worklight? >>> http://www-01.ibm.com/software/mobile-solutions/worklight/ >>> >>> In any case, ADF sounds promising :) >>> >>> Jiri >>> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Richard Bair >>> P?edm?t: Re: Oracle ADF Mobile >>> Datum: 23.10.2012 05:11:41 >>> ---------------------------------------- >>> ADF Mobile, at present, is implemented such that there is a JVM and version of >>> some Java libraries (I believe CDC subset), and uses the native web browser for >>> rendering content. We are in close communication with the ADF mobile team. >>> >>> Richard >>> >>> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >>> >>>> Hi, >>>> >>>> I saw this article about Oracle ADF Mobile: >>>> >>> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>>> saying >>>> this would help extend Java applications to mobile platforms like ios and >>>> android. >>>> >>>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>>> get anything out of it? >>>> >>>> Thanks in advance, best regards, >>>> >>>> -- >>>> Pedro Duque Vieira >>> >>> > From tobi at ultramixer.com Tue Oct 23 08:45:08 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 23 Oct 2012 17:45:08 +0200 Subject: Oracle ADF Mobile In-Reply-To: References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> Message-ID: I absolutely agree. The ADF approach is yet another htm5/JS/CSS-framework like Codemeter, Sencha Touch, JQuery Mobile, ... to name a few. These frameworks are useful, but only for form based apps. Richard: I would like to confirm our commercial interest in JavaFX for iOS, Android and Windows 8 metro. We are developing commercial software for desktop and mobile/tablet like our music software "UltraMixer" (www.ultramixer.com) or our sampling software "SampleDecks" (www.sampledecks.com) which do we want to bring to iPad & Co. On the other side we are developing business applications for mobile phones and tablets and currently we are using ObjectiveC, Java (Android) or HTML5 (Sencha Touch) but we are not happy about that. HTML5 has a poor performance, JavaScript is not type safe and the main problem is, we have to use different languages like JavaScript, HTML and Java/PHP. So we really looking forward to JavaFX2 for iOS & co so that we could decrease our development time... btw: you and your guys from the JavaFX team make a really good job! JavaFX2 is the best platform we have seen for a while. So please bring JavaFX2 to real world success and port it to the most important platforms iOS, android (and windows 8). Best regards, -- Tobias Bley Chief Executive Officer http://www.ultramixer.com Am 23.10.2012 um 16:28 schrieb Richard Bair : > As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. > > Richard > > On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: > >> Is this a reaction on IBM Worklight? >> http://www-01.ibm.com/software/mobile-solutions/worklight/ >> >> In any case, ADF sounds promising :) >> >> Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Richard Bair >> P?edm?t: Re: Oracle ADF Mobile >> Datum: 23.10.2012 05:11:41 >> ---------------------------------------- >> ADF Mobile, at present, is implemented such that there is a JVM and version of >> some Java libraries (I believe CDC subset), and uses the native web browser for >> rendering content. We are in close communication with the ADF mobile team. >> >> Richard >> >> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >> >>> Hi, >>> >>> I saw this article about Oracle ADF Mobile: >>> >> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>> saying >>> this would help extend Java applications to mobile platforms like ios and >>> android. >>> >>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>> get anything out of it? >>> >>> Thanks in advance, best regards, >>> >>> -- >>> Pedro Duque Vieira >> >> >> > From richard.bair at oracle.com Tue Oct 23 08:52:08 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 23 Oct 2012 08:52:08 -0700 Subject: Oracle ADF Mobile In-Reply-To: References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> Message-ID: <0071ADAC-892C-4525-BC03-34105949CD72@oracle.com> Thanks Tobias, I really appreciate all the support, and thanks for the patience. I know it is frustrating waiting for Oracle to say anything, because we don't say anything until it is all approved and whatnot going all the way up the chain, but when we do make an announcement / roadmap, you can have perfect assurance in knowing we will deliver on it. Thanks Richard On Oct 23, 2012, at 8:45 AM, Tobias Bley wrote: > I absolutely agree. The ADF approach is yet another htm5/JS/CSS-framework like Codemeter, Sencha Touch, JQuery Mobile, ... to name a few. These frameworks are useful, but only for form based apps. > > Richard: I would like to confirm our commercial interest in JavaFX for iOS, Android and Windows 8 metro. We are developing commercial software for desktop and mobile/tablet like our music software "UltraMixer" (www.ultramixer.com) or our sampling software "SampleDecks" (www.sampledecks.com) which do we want to bring to iPad & Co. > > On the other side we are developing business applications for mobile phones and tablets and currently we are using ObjectiveC, Java (Android) or HTML5 (Sencha Touch) but we are not happy about that. HTML5 has a poor performance, JavaScript is not type safe and the main problem is, we have to use different languages like JavaScript, HTML and Java/PHP. > > So we really looking forward to JavaFX2 for iOS & co so that we could decrease our development time... > > btw: you and your guys from the JavaFX team make a really good job! JavaFX2 is the best platform we have seen for a while. So please bring JavaFX2 to real world success and port it to the most important platforms iOS, android (and windows 8). > > > Best regards, > > -- > Tobias Bley > Chief Executive Officer > http://www.ultramixer.com > > > > > Am 23.10.2012 um 16:28 schrieb Richard Bair : > >> As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. >> >> Richard >> >> On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: >> >>> Is this a reaction on IBM Worklight? >>> http://www-01.ibm.com/software/mobile-solutions/worklight/ >>> >>> In any case, ADF sounds promising :) >>> >>> Jiri >>> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Richard Bair >>> P?edm?t: Re: Oracle ADF Mobile >>> Datum: 23.10.2012 05:11:41 >>> ---------------------------------------- >>> ADF Mobile, at present, is implemented such that there is a JVM and version of >>> some Java libraries (I believe CDC subset), and uses the native web browser for >>> rendering content. We are in close communication with the ADF mobile team. >>> >>> Richard >>> >>> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >>> >>>> Hi, >>>> >>>> I saw this article about Oracle ADF Mobile: >>>> >>> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>>> saying >>>> this would help extend Java applications to mobile platforms like ios and >>>> android. >>>> >>>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>>> get anything out of it? >>>> >>>> Thanks in advance, best regards, >>>> >>>> -- >>>> Pedro Duque Vieira >>> >>> >>> >> > From tobi at ultramixer.com Tue Oct 23 09:03:53 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 23 Oct 2012 18:03:53 +0200 Subject: Oracle ADF Mobile In-Reply-To: <0071ADAC-892C-4525-BC03-34105949CD72@oracle.com> References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> <0071ADAC-892C-4525-BC03-34105949CD72@oracle.com> Message-ID: <34A74670-9E3C-48E9-9B62-936893665DC7@ultramixer.com> Yes Richard,you are right. We believe in your team, your knowledge and your JavaFX platform! Best regards, Tobias -- Tobias Bley Chief Executive Officer http://www.ultramixer.com Am 23.10.2012 um 17:52 schrieb Richard Bair : > Thanks Tobias, I really appreciate all the support, and thanks for the patience. I know it is frustrating waiting for Oracle to say anything, because we don't say anything until it is all approved and whatnot going all the way up the chain, but when we do make an announcement / roadmap, you can have perfect assurance in knowing we will deliver on it. > > Thanks > Richard > > On Oct 23, 2012, at 8:45 AM, Tobias Bley wrote: > >> I absolutely agree. The ADF approach is yet another htm5/JS/CSS-framework like Codemeter, Sencha Touch, JQuery Mobile, ... to name a few. These frameworks are useful, but only for form based apps. >> >> Richard: I would like to confirm our commercial interest in JavaFX for iOS, Android and Windows 8 metro. We are developing commercial software for desktop and mobile/tablet like our music software "UltraMixer" (www.ultramixer.com) or our sampling software "SampleDecks" (www.sampledecks.com) which do we want to bring to iPad & Co. >> >> On the other side we are developing business applications for mobile phones and tablets and currently we are using ObjectiveC, Java (Android) or HTML5 (Sencha Touch) but we are not happy about that. HTML5 has a poor performance, JavaScript is not type safe and the main problem is, we have to use different languages like JavaScript, HTML and Java/PHP. >> >> So we really looking forward to JavaFX2 for iOS & co so that we could decrease our development time... >> >> btw: you and your guys from the JavaFX team make a really good job! JavaFX2 is the best platform we have seen for a while. So please bring JavaFX2 to real world success and port it to the most important platforms iOS, android (and windows 8). >> >> >> Best regards, >> >> -- >> Tobias Bley >> Chief Executive Officer >> http://www.ultramixer.com >> >> >> >> >> Am 23.10.2012 um 16:28 schrieb Richard Bair : >> >>> As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. >>> >>> Richard >>> >>> On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: >>> >>>> Is this a reaction on IBM Worklight? >>>> http://www-01.ibm.com/software/mobile-solutions/worklight/ >>>> >>>> In any case, ADF sounds promising :) >>>> >>>> Jiri >>>> >>>> ------------ P?vodn? zpr?va ------------ >>>> Od: Richard Bair >>>> P?edm?t: Re: Oracle ADF Mobile >>>> Datum: 23.10.2012 05:11:41 >>>> ---------------------------------------- >>>> ADF Mobile, at present, is implemented such that there is a JVM and version of >>>> some Java libraries (I believe CDC subset), and uses the native web browser for >>>> rendering content. We are in close communication with the ADF mobile team. >>>> >>>> Richard >>>> >>>> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >>>> >>>>> Hi, >>>>> >>>>> I saw this article about Oracle ADF Mobile: >>>>> >>>> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>>>> saying >>>>> this would help extend Java applications to mobile platforms like ios and >>>>> android. >>>>> >>>>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>>>> get anything out of it? >>>>> >>>>> Thanks in advance, best regards, >>>>> >>>>> -- >>>>> Pedro Duque Vieira >>>> >>>> >>>> >>> >> > From james.weaver at oracle.com Tue Oct 23 09:06:32 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Tue, 23 Oct 2012 12:06:32 -0400 Subject: Oracle ADF Mobile In-Reply-To: <0071ADAC-892C-4525-BC03-34105949CD72@oracle.com> References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> <0071ADAC-892C-4525-BC03-34105949CD72@oracle.com> Message-ID: <5086C088.7020309@oracle.com> I'm definitely looking forward to seeing (and using) the JavaFX version of UltraMixer, Tobias! Please keep us posted on new developments! Regards, Jim Weaver Java Technology Evangelist and Musical Hacker james.weaver at oracle.com On 10/23/12 11:52 AM, Richard Bair wrote: > Thanks Tobias, I really appreciate all the support, and thanks for the patience. I know it is frustrating waiting for Oracle to say anything, because we don't say anything until it is all approved and whatnot going all the way up the chain, but when we do make an announcement / roadmap, you can have perfect assurance in knowing we will deliver on it. > > Thanks > Richard > > On Oct 23, 2012, at 8:45 AM, Tobias Bley wrote: > >> I absolutely agree. The ADF approach is yet another htm5/JS/CSS-framework like Codemeter, Sencha Touch, JQuery Mobile, ... to name a few. These frameworks are useful, but only for form based apps. >> >> Richard: I would like to confirm our commercial interest in JavaFX for iOS, Android and Windows 8 metro. We are developing commercial software for desktop and mobile/tablet like our music software "UltraMixer" (www.ultramixer.com) or our sampling software "SampleDecks" (www.sampledecks.com) which do we want to bring to iPad & Co. >> >> On the other side we are developing business applications for mobile phones and tablets and currently we are using ObjectiveC, Java (Android) or HTML5 (Sencha Touch) but we are not happy about that. HTML5 has a poor performance, JavaScript is not type safe and the main problem is, we have to use different languages like JavaScript, HTML and Java/PHP. >> >> So we really looking forward to JavaFX2 for iOS & co so that we could decrease our development time... >> >> btw: you and your guys from the JavaFX team make a really good job! JavaFX2 is the best platform we have seen for a while. So please bring JavaFX2 to real world success and port it to the most important platforms iOS, android (and windows 8). >> >> >> Best regards, >> >> -- >> Tobias Bley >> Chief Executive Officer >> http://www.ultramixer.com >> >> >> >> >> Am 23.10.2012 um 16:28 schrieb Richard Bair : >> >>> As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. >>> >>> Richard >>> >>> On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: >>> >>>> Is this a reaction on IBM Worklight? >>>> http://www-01.ibm.com/software/mobile-solutions/worklight/ >>>> >>>> In any case, ADF sounds promising :) >>>> >>>> Jiri >>>> >>>> ------------ P?vodn? zpr?va ------------ >>>> Od: Richard Bair >>>> P?edm?t: Re: Oracle ADF Mobile >>>> Datum: 23.10.2012 05:11:41 >>>> ---------------------------------------- >>>> ADF Mobile, at present, is implemented such that there is a JVM and version of >>>> some Java libraries (I believe CDC subset), and uses the native web browser for >>>> rendering content. We are in close communication with the ADF mobile team. >>>> >>>> Richard >>>> >>>> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >>>> >>>>> Hi, >>>>> >>>>> I saw this article about Oracle ADF Mobile: >>>>> >>>> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>>>> saying >>>>> this would help extend Java applications to mobile platforms like ios and >>>>> android. >>>>> >>>>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>>>> get anything out of it? >>>>> >>>>> Thanks in advance, best regards, >>>>> >>>>> -- >>>>> Pedro Duque Vieira >>>> >>>> -- Regards, Jim Weaver Java Evangelist Oracle Corporation james.weaver at oracle.com From lehmann at media-interactive.de Tue Oct 23 09:12:50 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 23 Oct 2012 18:12:50 +0200 Subject: ContextMenu styling (esp. for MenuButton) Message-ID: <5086C202.5020304@media-interactive.de> Hi, I want to show a button with a custom node dropdown. Seems like a good job for a MenuButton with a single CustomMenuItem. This works ok but styling is difficult - how can I style the menuitem/contextmenu used by the MenuButton skin? Apparently I cannot access it from the MenuButton control. Basically I just want to remove the blue hover and reduce the borders to get something like a "PopupButton". According to the Javadoc it was possible at some point to use the custom node directly in MenuButton.items. This is obviously not the case anymore because items is generically typed to MenuItem elements (RT-25770). Too bad for me, this is probably just what I need here. On a more general note, is this the correct and simplest way to style a ContextMenu (once I have a reference to it)? contextmenu .getScene() .getRoot() .getStylesheets() .addAll(...stylesheet...) It would be nice if the contextmenu could inherit the stylesheet of the scene it is used on - or in the case of controls like MenuButton, inherit the stylesheet of the control's scene. Any thoughts about that? Rgds Werner From scott.kovatch at oracle.com Tue Oct 23 09:22:57 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 23 Oct 2012 09:22:57 -0700 Subject: Ensemble in Mac App Store In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: On Oct 22, 2012, at 4:36 PM, John Smith wrote: > Really nice work on packaging Ensemble and placing it in the Mac App Store. > > If one wants to package an application for the Mac App Store, which build must be used? Well, I should come clean here, and admit that it wasn't just a simple matter of downloading a JDK release and packaging everything up. I checked out the source of OpenJDK (jdk7u branch) and built a JDK myself. There were some known issues in the AWT that I patched locally. All of those changes have been checked in, so there should be an upcoming release (probably 7u12) with all of the fixes. I also took what should have been FX 2.2.4 and combined that with the JDK. > So, currently, is it only Oracle which can publish JavaFX applications in the Mac App Store? > And the rest of the world will be able to do the packaging in Spring when JDK 7u12 / FX 2.2.6 is released? The answer to these two questions is yes. Ensemble should be seen right now as proof that 'yes, a JRE and JavaFX can be put into the OS X app store.' We have a chicken-and-egg problem in that we can't stand up and say it can be done unless we do it ourselves first. So, that's what we did. Unfortunately things didn't line up schedule-wise, so the community can't do it yet. We are still on track to have a release that is ready to use by anyone for packaging -- nothing has changed there. You can start with the pre-release of 7u10, which *should* have all of the JDK and JavaFX fixes that would have kept you from submitting to the store, but I'd have to check to see if all of the ones we know about made it. 7u12 will definitely have all of them. -- Scott K. From philip.race at oracle.com Tue Oct 23 09:34:57 2012 From: philip.race at oracle.com (Phil Race) Date: Tue, 23 Oct 2012 09:34:57 -0700 Subject: Ensemble in Mac App Store In-Reply-To: References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <5086C731.7090006@oracle.com> If you are comfortable with the GPL then you can create your own build from openjdk sources ... -phil. On 10/22/12 6:30 PM, Richard Bair wrote: > Scott, can you fill us in on the story around how you went about packaging Ensemble? What version of Java did you have to use? > > Cheers > Richard > > On Oct 22, 2012, at 4:36 PM, John Smith wrote: > >> Really nice work on packaging Ensemble and placing it in the Mac App Store. >> >> If one wants to package an application for the Mac App Store, which build must be used? >> >> I'm guessing it is JDK 7u12 / FX 2.2.6 because that fixes specific Jira's which were targeted towards packaging native binaries for the Mac App Store? >> >> At https://forums.oracle.com/forums/message.jspa?messageID=10621531 on Oct 8, igor stated "JavaFX tools is way to go. At least long term (as you need to use current beta from http://jdk7.java.net/download.html and it might have bugs)." >> >> However, if you use a non-production release, like http://jdk7.java.net/download.html or http://jdk8.java.net/download.html, then you must agree to the pre-production license http://jdk7.java.net/license.html. This license obviously wouldn't work for something packaged for app store delivery due to the following clause: "We grant You a revocable, nonexclusive, nontransferable, royalty-free and limited right to (a) use one (1) copy of the binary portions of the Programs for the sole purpose of internal non-production and non-commercial evaluation and testing of the Programs, including, developing no more than a single prototype of each of Your applications" >> >> So, currently, is it only Oracle which can publish JavaFX applications in the Mac App Store? >> And the rest of the world will be able to do the packaging in Spring when JDK 7u12 / FX 2.2.6 is released? >> Or is there some other way around this? How was Ensemble packaged for instance? From kittyburrito at googlemail.com Sun Oct 7 06:47:54 2012 From: kittyburrito at googlemail.com (Andy Till) Date: Sun, 07 Oct 2012 13:47:54 -0000 Subject: No SimpleStringProperty.bind(Property, StringConverter) method Message-ID: <50718800.3000607@googlemail.com> Is there a reason why no SimpleStringProperty.bind(Property, StringConverter) exists but SimpleStringProperty.bindBidirectional(Property, StringConverter) does or is this just an omission that I could perhaps request to be implemented? I have a SimpleIntegerProperty that is bound to a NumberBinding. A TextField.textProperty is then bound to the SimpleIntegerProperty but it throws the following exception: java.lang.RuntimeException: A bound value cannot be set. at javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:159) at javafx.beans.property.IntegerProperty.setValue(IntegerProperty.java:80) at javafx.beans.property.IntegerProperty.setValue(IntegerProperty.java:72) at com.sun.javafx.binding.BidirectionalBinding$StringConversionBidirectionalBinding.changed(BidirectionalBinding.java:550) at com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:367) at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:100) at javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1034) at javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1038) at javafx.scene.control.TextInputControl$TextProperty.invalidate(TextInputControl.java:978) at javafx.scene.control.TextInputControl$TextProperty.access$200(TextInputControl.java:950) at javafx.scene.control.TextInputControl$1.invalidated(TextInputControl.java:119) at com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:155) at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:100) at javafx.scene.control.TextField$TextFieldContent.insert(TextField.java:79) at javafx.scene.control.TextInputControl$TextProperty.doSet(TextInputControl.java:1047) at javafx.scene.control.TextInputControl$TextProperty.set(TextInputControl.java:973) at javafx.scene.control.TextInputControl$TextProperty.set(TextInputControl.java:950) at javafx.beans.property.StringProperty.setValue(StringProperty.java:84) at javafx.beans.property.StringProperty.setValue(StringProperty.java:76) at com.sun.javafx.binding.BidirectionalBinding.bind(BidirectionalBinding.java:108) at javafx.beans.binding.Bindings.bindBidirectional(Bindings.java:655) at javafx.beans.property.StringProperty.bindBidirectional(StringProperty.java:128) From stephen.chin at oracle.com Tue Oct 23 09:44:15 2012 From: stephen.chin at oracle.com (Stephen Chin) Date: Tue, 23 Oct 2012 09:44:15 -0700 Subject: Oracle ADF Mobile In-Reply-To: References: <136940.14421.50634-8828-408912836-1350988054@seznam.cz> <5086AF3F.5010507@tbee.org> Message-ID: ADF is a development framework intended to build Java EE application, and is the base for all Oracle Fusion Middleware and Applications products. ADF mobile is a cross-platform mobile development framework that allows you to develop in ADF, and then package the application and deploy it to an iOS or Android device. Technically, the packaged application uses a HTML5 UI and a Java application library (currently based on the Java ME CDC profile). It is a great development environment for extending Oracle middleware and applications to mobile devices, but it is not intended to be a a general-purpose Java platform. The underlying technology that Oracle used for ADF mobile is interesting and could be extended to become a generic Java SE runtime framework with a web front-end and/or a JavaFX front-end. If that happens, then the obvious thing is for ADF mobile to be based on a generic Java+web platform. We have not announced any such plans yet - Oracle is very conservative and only announces plans when we have a concrete development schedule to GA. The unfortunate reality is that building a product with a specific purpose such as ADF mobile is a lot less work than building a general-purpose Java platform for mobile. The good news is that JavaFX is on a path to be fully open sourced, which will enable the community to chip in and help. Hint, hint. ;) Cheers, --Steve On 23 Oct 2012, at 08:13 , Randahl Fink Isaksen wrote: > Tom, as someone who has worked extensively with both JSF and JavaFX, I can assure you that a JSF-based approach like ADF will never get even close to the flexibility and power of JavaFX. > > Its like comparing bamboo scaffolds to the Burj Khalifa. > > We need a true, rich client approach on mobile devices, and only JavaFX has a real chance of delivering that at the moment. > > Randahl > > > On Oct 23, 2012, at 16:52 , Tom Eugelink wrote: > >> Seems that ADF and JavaFX are possibly aiming at the same market; cross-platform mobile apps. >> >> Tom >> >> >> >> On 2012-10-23 16:28, Richard Bair wrote: >>> As you may know, Oracle uses ADF (a variant of JSF) for the Fusion Middleware applications. Having piles and piles of code / tools developed for ADF, having some means to leverage that for mobile development is, I believe, the main driver for ADF Mobile. For example, JDeveloper provides tooling both for ADF and ADF Mobile, using the same databinding support etc. >>> >>> Richard >>> >>> On Oct 23, 2012, at 3:27 AM, goddard at seznam.cz wrote: >>> >>>> Is this a reaction on IBM Worklight? >>>> http://www-01.ibm.com/software/mobile-solutions/worklight/ >>>> >>>> In any case, ADF sounds promising :) >>>> >>>> Jiri >>>> >>>> ------------ P?vodn? zpr?va ------------ >>>> Od: Richard Bair >>>> P?edm?t: Re: Oracle ADF Mobile >>>> Datum: 23.10.2012 05:11:41 >>>> ---------------------------------------- >>>> ADF Mobile, at present, is implemented such that there is a JVM and version of >>>> some Java libraries (I believe CDC subset), and uses the native web browser for >>>> rendering content. We are in close communication with the ADF mobile team. >>>> >>>> Richard >>>> >>>> On Oct 22, 2012, at 4:34 PM, Pedro Duque Vieira wrote: >>>> >>>>> Hi, >>>>> >>>>> I saw this article about Oracle ADF Mobile: >>>>> >>>> http://www.infoworld.com/d/application-development/oracle-brings-cross-platform-java-dev-mobile-devices-205369 >>>>> saying >>>>> this would help extend Java applications to mobile platforms like ios and >>>>> android. >>>>> >>>>> As i know nothing about ADF, I was wondering whether JavaFX developers will >>>>> get anything out of it? >>>>> >>>>> Thanks in advance, best regards, >>>>> >>>>> -- >>>>> Pedro Duque Vieira >>>> >>>> >> > Stephen Chin (@steveonjava) | Java Technology Ambassador and JavaOne Conference Chair | +1.510.323.6097 Oracle Java Product Management http://steveonjava.com/ From swpalmer at gmail.com Sun Oct 21 15:49:46 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 21 Oct 2012 18:49:46 -0400 Subject: Native crash on OS X while trying to reproduce memory leak. Message-ID: Running 7u10-b12 ea (With JavaFX 2.2.4-ea) My test app didn't appear to leak on the Java Heap.. so I walked away for a while and when I came back the following crash report was waiting for me: I can't tell if it is a JFX issue or not? It looks like it may be a video card driver issue. But I figured I would un it by you guys just in case. Scott Process: java [90221] Path: /usr/bin/java Identifier: net.java.openjdk.cmd Version: 1.0 (1.0) Code Type: X86-64 (Native) Parent Process: java [89500] User ID: 501 PlugIn Path: /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/server/libjvm.dylib PlugIn Identifier: libjvm.dylib PlugIn Version: ??? (1) Date/Time: 2012-10-21 18:40:05.554 -0400 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Interval Since Last Report: 303045 sec Crashes Since Last Report: 2 Per-App Interval Since Last Report: 46716 sec Per-App Crashes Since Last Report: 2 Anonymous UUID: 5537324E-00BF-DEEE-612A-01B7BD799C83 Crashed Thread: 28 CVDisplayLink Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x00007fcbe01ad918 VM Regions Near 0x7fcbe01ad918: MALLOC_SMALL 00007fcbdd800000-00007fcbe0000000 [ 40.0M] rw-/rwx SM=PRV --> STACK GUARD 00007fff4ce3b000-00007fff5063b000 [ 56.0M] ---/rwx SM=NUL stack guard for thread 0 Application Specific Information: abort() called Thread 0:: AppKit Thread Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a14a9 Parker::park(bool, long long) + 501 3 libjvm.dylib 0x000000010f37ccad Unsafe_Park + 122 4 ??? 0x000000010fb7df90 0 + 4558675856 5 ??? 0x000000010fd854d8 0 + 4560803032 Thread 1: 0 libsystem_kernel.dylib 0x00007fff8f68a386 __semwait_signal + 10 1 libsystem_c.dylib 0x00007fff8e24ccbd pthread_join + 847 2 java 0x000000010edcba2d ContinueInNewThread0 + 102 3 java 0x000000010edc7847 ContinueInNewThread + 201 4 java 0x000000010edcb790 JVMInit + 251 5 java 0x000000010edc75c5 JLI_Launch + 4489 6 java 0x000000010edcc78a main + 101 7 java 0x000000010edcc0bf apple_main + 92 8 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 9 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 2: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28418a Monitor::wait(bool, long, bool) + 246 6 libjvm.dylib 0x000000010f367168 Threads::destroy_vm() + 80 7 libjvm.dylib 0x000000010f1922ba jni_DestroyJavaVM + 223 8 java 0x000000010edc7b86 JavaMain + 805 9 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 10 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 3:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff8f68ad16 kevent + 10 1 libdispatch.dylib 0x00007fff87804dea _dispatch_mgr_invoke + 883 2 libdispatch.dylib 0x00007fff878049ee _dispatch_mgr_thread + 54 Thread 4: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010f3a342f GangWorker::loop() + 179 7 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 8 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 9 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 5: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010f3a342f GangWorker::loop() + 179 7 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 8 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 9 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 6: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010f3a342f GangWorker::loop() + 179 7 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 8 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 9 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 7: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010f3a342f GangWorker::loop() + 179 7 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 8 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 9 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 8: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010f0965bf ConcurrentMarkSweepThread::icms_wait() + 89 7 libjvm.dylib 0x000000010f0964e5 ConcurrentMarkSweepThread::run() + 407 8 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 9 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 10 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 9: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a16b3 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 4 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 5 libjvm.dylib 0x000000010f397f2c VMThread::loop() + 444 6 libjvm.dylib 0x000000010f397a47 VMThread::run() + 121 7 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 8 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 9 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 10:: Java: Reference Handler 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fdb6188 0 + 4561002888 Thread 11:: Java: Finalizer 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fb72158 0 + 4558627160 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb72333 0 + 4558627635 10 ??? 0x000000010fb6c4f7 0 + 4558603511 11 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 13 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 15 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 17 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 18 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 19 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 12:: Java: Surrogate Locker Thread (Concurrent GC) 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f284172 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x000000010f07c381 SurrogateLockerThread::loop() + 141 7 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 8 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 9 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 10 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 11 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 13:: Java: Signal Dispatcher 0 libsystem_kernel.dylib 0x00007fff8f6886c2 semaphore_wait_trap + 10 1 libjvm.dylib 0x000000010f2a2a13 check_pending_signals(bool) + 128 2 libjvm.dylib 0x000000010f29f799 signal_thread_entry(JavaThread*, Thread*) + 642 3 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 4 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 5 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 6 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 7 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 14:: Java: C2 CompilerThread0 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f284172 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x000000010f075a1b CompileQueue::get() + 153 7 libjvm.dylib 0x000000010f076494 CompileBroker::compiler_thread_loop() + 410 8 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 9 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 10 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 11 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 12 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 15:: Java: C2 CompilerThread1 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f284172 Monitor::wait(bool, long, bool) + 222 6 libjvm.dylib 0x000000010f075a1b CompileQueue::get() + 153 7 libjvm.dylib 0x000000010f076494 CompileBroker::compiler_thread_loop() + 410 8 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 9 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 10 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 11 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 12 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 16:: Java: Service Thread 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f2837bc ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010f283fae Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010f28420b Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010f2f2e53 ServiceThread::service_thread_entry(JavaThread*, Thread*) + 109 7 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 8 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 9 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 10 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 11 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 17: 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a16b3 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x000000010f2a1867 os::sleep(Thread*, long long, bool) + 321 4 libjvm.dylib 0x000000010f368333 WatcherThread::run() + 165 5 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 6 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 7 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 18:: Java: AWT-Shutdown 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fb72158 0 + 4558627160 8 ??? 0x000000010fb72158 0 + 4558627160 9 ??? 0x000000010fb72806 0 + 4558628870 10 ??? 0x000000010fb6c4f7 0 + 4558603511 11 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 13 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 15 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 17 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 18 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 19 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 19:: Java: AWT-EventQueue-0 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a14a9 Parker::park(bool, long long) + 501 3 libjvm.dylib 0x000000010f37ccad Unsafe_Park + 122 4 ??? 0x000000010fb7df90 0 + 4558675856 5 ??? 0x000000010fd9a4d8 0 + 4560889048 Thread 20:: Java: Java2D Disposer 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fb72158 0 + 4558627160 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb72333 0 + 4558627635 10 ??? 0x000000010fb72806 0 + 4558628870 11 ??? 0x000000010fb6c4f7 0 + 4558603511 12 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 13 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 14 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 15 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 16 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 17 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 18 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 19 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 20 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 21:: Java: Java2D Queue Flusher 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a16b3 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x000000010f29ace7 ObjectMonitor::wait(long long, bool, Thread*) + 637 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fdafd10 0 + 4560977168 Thread 22:: Java: TimerQueue 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a14a9 Parker::park(bool, long long) + 501 3 libjvm.dylib 0x000000010f37ccad Unsafe_Park + 122 4 ??? 0x000000010fb7df90 0 + 4558675856 5 ??? 0x000000010fb72158 0 + 4558627160 6 ??? 0x000000010fb72158 0 + 4558627160 7 ??? 0x000000010fb72806 0 + 4558628870 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb72806 0 + 4558628870 10 ??? 0x000000010fb6c4f7 0 + 4558603511 11 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 13 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 14 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 15 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 16 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 17 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 18 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 19 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 23:: Java: QuantumRenderer-0 0 libsystem_kernel.dylib 0x00007fff8f68a122 __psynch_mutexwait + 10 1 libsystem_c.dylib 0x00007fff8e1c7d9d pthread_mutex_lock + 536 2 com.apple.GeForceGLDriver 0x00000002000b252e gldUpdateDispatch + 75 3 GLEngine 0x0000000120f95352 gleDoSelectiveDispatchCore + 504 4 GLEngine 0x0000000120e8dc28 glClear_Exec + 399 5 libprism-es2.dylib 0x000000012176330d clearBuffers + 363 6 libprism-es2.dylib 0x00000001217635dd Java_com_sun_prism_es2_gl_GLContext_nClearBuffers + 126 7 ??? 0x000000010fb7df90 0 + 4558675856 8 ??? 0x000000010fb72158 0 + 4558627160 9 ??? 0x000000010fb72158 0 + 4558627160 10 ??? 0x000000010fb72158 0 + 4558627160 11 ??? 0x000000010fb72806 0 + 4558628870 12 ??? 0x000000010fb72158 0 + 4558627160 13 ??? 0x000000010fb72158 0 + 4558627160 14 ??? 0x000000010fb72806 0 + 4558628870 15 ??? 0x000000010fb729e1 0 + 4558629345 16 ??? 0x000000010fe18b78 0 + 4561406840 Thread 24:: Java: Disposer 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fb72158 0 + 4558627160 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb72333 0 + 4558627635 10 ??? 0x000000010fb72806 0 + 4558628870 11 ??? 0x000000010fb6c4f7 0 + 4558603511 12 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 13 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 14 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 15 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 16 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 17 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 18 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 19 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 20 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 25:: Java: Thread-2 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fdf0bd0 0 + 4561243088 Thread 26:: Glass Timer Thread 0 libsystem_kernel.dylib 0x00007fff8f68a386 __semwait_signal + 10 1 libsystem_c.dylib 0x00007fff8e24c800 nanosleep + 163 2 libsystem_c.dylib 0x00007fff8e24c717 usleep + 54 3 libglass.dylib 0x0000000121f81327 _GlassTimerTask + 343 4 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 5 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 27:: Java: Prism Font Disposer 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a0547 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010f29acdd ObjectMonitor::wait(long long, bool, Thread*) + 627 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fb72158 0 + 4558627160 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb72333 0 + 4558627635 10 ??? 0x000000010fb72806 0 + 4558628870 11 ??? 0x000000010fb6c4f7 0 + 4558603511 12 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 13 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 14 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 15 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 16 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 17 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 18 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 19 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 20 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 28 Crashed:: CVDisplayLink 0 libsystem_kernel.dylib 0x00007fff8f68a212 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff8e1c3af4 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff8e207dce abort + 143 3 libjvm.dylib 0x000000010f2a3c93 os::abort(bool) + 25 4 libjvm.dylib 0x000000010f39244e VMError::report_and_die() + 2306 5 libjvm.dylib 0x000000010f2a5387 JVM_handle_bsd_signal + 1073 6 libsystem_c.dylib 0x00007fff8e1b08ea _sigtramp + 26 7 com.apple.GeForceGLDriver 0x00000002000a8e05 0x200000000 + 691717 8 com.apple.GeForceGLDriver 0x00000002000d9545 0x200000000 + 890181 9 libGPUSupport.dylib 0x00000001211e24d5 gldDestroyTexture + 26 10 libGFXShared.dylib 0x00007fff91256fd1 gfxDestroyPluginTexture + 55 11 GLEngine 0x0000000120fda3f8 gleFreeTextureObject + 37 12 GLEngine 0x0000000120fac868 gleUnbindDeleteHashNamesAndObjects + 166 13 GLEngine 0x0000000120e8c854 glDeleteTextures_Exec + 732 14 com.apple.QuartzCore 0x00007fff8fc7d707 CA::OGL::CGLContext::delete_image(CA::OGL::Image*) + 121 15 com.apple.QuartzCore 0x00007fff8fc6e0e3 CA::OGL::Context::collect(bool) + 361 16 com.apple.QuartzCore 0x00007fff8fc6df55 CA::OGL::GLContext::collect(bool) + 25 17 com.apple.QuartzCore 0x00007fff8fc6df1b CA::OGL::CGLContext::collect(bool) + 21 18 com.apple.QuartzCore 0x00007fff8fc65eec view_draw(_CAView*, double, CVTimeStamp const*, bool) + 3982 19 com.apple.QuartzCore 0x00007fff8fc6ecd7 view_display_link(double, CVTimeStamp const*, void*) + 139 20 com.apple.QuartzCore 0x00007fff8fc6ebc2 link_callback + 244 21 com.apple.CoreVideo 0x00007fff8717403d CVDisplayLink::performIO(CVTimeStamp*) + 203 22 com.apple.CoreVideo 0x00007fff871732a4 CVDisplayLink::runIOThread() + 632 23 com.apple.CoreVideo 0x00007fff87173013 startIOThread(void*) + 148 24 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 25 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 29:: Java: RMI TCP Accept-0 0 libsystem_kernel.dylib 0x00007fff8f68a322 __select + 10 1 libnet.dylib 0x000000011f37406e NET_Timeout + 618 2 libnet.dylib 0x000000011f3757e1 Java_java_net_PlainSocketImpl_socketAccept + 445 3 ??? 0x000000010fb7df90 0 + 4558675856 4 ??? 0x000000010fb72158 0 + 4558627160 5 ??? 0x000000010fb72158 0 + 4558627160 6 ??? 0x000000010fb72158 0 + 4558627160 7 ??? 0x000000010fb72333 0 + 4558627635 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb72158 0 + 4558627160 10 ??? 0x000000010fb72806 0 + 4558628870 11 ??? 0x000000010fb6c4f7 0 + 4558603511 12 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 13 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 14 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 15 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 16 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 17 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 18 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 19 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 20 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 30:: Java: RMI Scheduler(0) 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a14ba Parker::park(bool, long long) + 518 3 libjvm.dylib 0x000000010f37ccad Unsafe_Park + 122 4 ??? 0x000000010fb7df90 0 + 4558675856 5 ??? 0x000000010fb72158 0 + 4558627160 6 ??? 0x000000010fb72158 0 + 4558627160 7 ??? 0x000000010fb72923 0 + 4558629155 8 ??? 0x000000010fb72333 0 + 4558627635 9 ??? 0x000000010fb729e1 0 + 4558629345 10 ??? 0x000000010fb72333 0 + 4558627635 11 ??? 0x000000010fb72158 0 + 4558627160 12 ??? 0x000000010fb72806 0 + 4558628870 13 ??? 0x000000010fb6c4f7 0 + 4558603511 14 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 15 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 16 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 17 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 18 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 19 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 20 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 21 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 22 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 31:: Java: JMX server connection timeout 26 0 libsystem_kernel.dylib 0x00007fff8f68a0fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8e1c6f89 _pthread_cond_wait + 869 2 libjvm.dylib 0x000000010f2a16b3 os::PlatformEvent::park(long long) + 385 3 libjvm.dylib 0x000000010f29ace7 ObjectMonitor::wait(long long, bool, Thread*) + 637 4 libjvm.dylib 0x000000010f337b31 ObjectSynchronizer::wait(Handle, long long, Thread*) + 203 5 libjvm.dylib 0x000000010f1b305a JVM_MonitorWait + 154 6 ??? 0x000000010fb7df90 0 + 4558675856 7 ??? 0x000000010fb72158 0 + 4558627160 8 ??? 0x000000010fb72806 0 + 4558628870 9 ??? 0x000000010fb6c4f7 0 + 4558603511 10 libjvm.dylib 0x000000010f17755f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 11 libjvm.dylib 0x000000010f177a3c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 12 libjvm.dylib 0x000000010f177b76 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 13 libjvm.dylib 0x000000010f1ae4f0 thread_entry(JavaThread*, Thread*) + 169 14 libjvm.dylib 0x000000010f3672b4 JavaThread::thread_main_inner() + 134 15 libjvm.dylib 0x000000010f36879a JavaThread::run() + 440 16 libjvm.dylib 0x000000010f2a41b5 java_start(Thread*) + 173 17 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 18 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 Thread 32:: Java: RMI TCP Connection(idle) 0 libsystem_kernel.dylib 0x00007fff8f68a322 __select + 10 1 libnet.dylib 0x000000011f37406e NET_Timeout + 618 2 libnet.dylib 0x000000011f371dbe Java_java_net_SocketInputStream_socketRead0 + 246 3 ??? 0x000000010fb7df90 0 + 4558675856 4 ??? 0x000000010fb722d4 0 + 4558627540 5 ??? 0x000000010fb722d4 0 + 4558627540 6 ??? 0x000000010fb722d4 0 + 4558627540 7 ??? 0x000000010fc0423c 0 + 4559225404 Thread 33: 0 libsystem_kernel.dylib 0x00007fff8f68a6d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff8e1c4eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff8e1c4cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff8e1af171 start_wqthread + 13 Thread 28 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x0000000124d8dc58 rdx: 0x0000000000000000 rdi: 0x000000000000c303 rsi: 0x0000000000000006 rbp: 0x0000000124d8dc80 rsp: 0x0000000124d8dc58 r8: 0x00007fff7692e278 r9: 0x0000000124d8dc30 r10: 0x0000000020000000 r11: 0x0000000000000206 r12: 0x000000010f63a0c0 r13: 0x0000000000000002 r14: 0x0000000124d90000 r15: 0x000000010f2a71e0 rip: 0x00007fff8f68a212 rfl: 0x0000000000000206 cr2: 0x00007fff76927fe8 Logical CPU: 0 Binary Images: 0x10edc5000 - 0x10edd5fff +java (1.0 - 1.0) <027B3079-2402-36E0-BB3E-AE7CB98ACCFA> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/bin/java 0x10eeef000 - 0x10f579fff +libjvm.dylib (1) <6FBAE7F8-3E06-3EA9-853C-60DCC9B77B1E> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/server/libjvm.dylib 0x10fa99000 - 0x10faa1fff +libverify.dylib (1) <0A501F59-6010-31D7-8FD8-A3BDA7A1728C> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libverify.dylib 0x10faa6000 - 0x10fac7fef +libjava.dylib (1) /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libjava.dylib 0x10fb63000 - 0x10fb68fff +libzip.dylib (1) /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libzip.dylib 0x11c299000 - 0x11c2a2ff7 com.apple.java.JavaRuntimeSupport (14.5.0 - 14.5.0) /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport 0x11c2b1000 - 0x11c2bbfff JavaNativeFoundation (1) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation 0x11c2c6000 - 0x11c2cbfff com.apple.JavaVM (14.5.0 - 14.5.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM 0x11c2d3000 - 0x11c2d8fff JavaLaunching (1) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching 0x11cab3000 - 0x11cab3fff +librmi.dylib (1) <44F12E5F-4353-3F13-8467-947905D0FEB6> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/librmi.dylib 0x11cbb6000 - 0x11cc21fff +libawt.dylib (1) <4B21E187-8701-33D4-8171-0B4F62A881A0> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libawt.dylib 0x11cc65000 - 0x11cd2afff +libmlib_image.dylib (1) <092ACB42-F7AC-3E1D-AFCE-6BFA1655D849> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libmlib_image.dylib 0x11cd31000 - 0x11cda0ff7 +liblwawt.dylib (1) <86D44ED9-E36C-3C90-9805-290E9D4F7298> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib 0x11cde3000 - 0x11cde9fff +libosxapp.dylib (1) /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libosxapp.dylib 0x11cdff000 - 0x11ce01fff com.apple.ExceptionHandling (1.5 - 10) <47FF83ED-0C07-308C-A375-2A2189DB1056> /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling 0x11e292000 - 0x11e2ddfe7 +libjavafx-font.dylib (0) <1826D271-1AA4-790C-7D3B-3D2BE7911C1E> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libjavafx-font.dylib 0x11e332000 - 0x11e335fff +libmanagement.dylib (1) <93CA1924-0CA8-37F7-AA45-80762C9B1B48> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libmanagement.dylib 0x11e344000 - 0x11e344ff1 +cl_kernels (???) cl_kernels 0x11e40d000 - 0x11e424fe7 +libinstrument.dylib (1) <8ADCC8AB-3395-3991-8FC5-98185E1E392B> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libinstrument.dylib 0x11f10d000 - 0x11f110ff7 libCoreFSCache.dylib (24.4) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib 0x11f36d000 - 0x11f37bff7 +libnet.dylib (1) /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libnet.dylib 0x1208fe000 - 0x12092fff7 +libfontmanager.dylib (1) <6054A5A7-EB8D-361E-A3D2-7AF80DB50058> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libfontmanager.dylib 0x120e76000 - 0x12102dfff GLEngine (8.6.1) <94C4C4C0-E96C-30B2-8CD7-DE8D82CA74F1> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine 0x121064000 - 0x1211a6fff libGLProgrammability.dylib (8.6.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x1211da000 - 0x1211e8ff7 libGPUSupport.dylib (8.6.1) /System/Library/PrivateFrameworks/GPUSupport.framework/Versions/A/Libraries/libGPUSupport.dylib 0x1211ef000 - 0x12157fff7 com.apple.driver.AppleIntelHDGraphicsGLDriver (8.0.61 - 8.0.0) <2234684B-E475-356D-9A5F-F69F5DE6C76B> /System/Library/Extensions/AppleIntelHDGraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHDGraphicsGLDriver 0x12169a000 - 0x1216c7fff GLRendererFloat (8.6.1) /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat 0x1216d0000 - 0x1216d9fe7 libcldcpuengine.dylib (2.1.19) <50800DA2-7233-32E5-9553-A02171B68399> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib 0x121762000 - 0x121768ff7 +libprism-es2.dylib (0) <382D3E05-E6AD-5481-94DF-93DC0D57B7C3> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libprism-es2.dylib 0x121f6c000 - 0x121fa8fef +libglass.dylib (0) /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libglass.dylib 0x122572000 - 0x12257afff +libnio.dylib (1) /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/libnio.dylib 0x1226b6000 - 0x1226b7ff3 +cl_kernels (???) <99E19283-0BA4-4036-99EA-13F6E133CBB5> cl_kernels 0x12693d000 - 0x1269d8ff7 unorm8_bgra.dylib (2.1.19) <904EA51D-225A-38AF-B66C-84493C55C065> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/ImageFormats/unorm8_bgra.dylib 0x200000000 - 0x200822ff7 com.apple.GeForceGLDriver (8.0.61 - 8.0.0) /System/Library/Extensions/GeForceGLDriver.bundle/Contents/MacOS/GeForceGLDriver 0x7fff6e9c5000 - 0x7fff6e9f993f dyld (210.2.3) /usr/lib/dyld 0x7fff85679000 - 0x7fff8569bff7 libxpc.dylib (140.41) /usr/lib/system/libxpc.dylib 0x7fff857e0000 - 0x7fff857e1fff liblangid.dylib (116) <864C409D-D56B-383E-9B44-A435A47F2346> /usr/lib/liblangid.dylib 0x7fff85864000 - 0x7fff858a7ff7 com.apple.bom (12.0 - 192) <0BF1F2D2-3648-36B7-BE4B-551A0173209B> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x7fff85900000 - 0x7fff8590bfff com.apple.CommonAuth (3.0 - 2.0) <74A86DDD-57D0-3178-AB74-E1F31DBFFC39> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x7fff85965000 - 0x7fff85965fff com.apple.vecLib (3.8 - vecLib 3.8) <794317C7-4E38-338A-A874-5E18001C8503> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff859ad000 - 0x7fff85b48fef com.apple.vImage (6.0 - 6.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff85b49000 - 0x7fff85c39ff7 com.apple.DiskImagesFramework (10.8 - 344) <3A30B9B5-5099-35E2-9DCD-C96764FA2D26> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages 0x7fff85c3a000 - 0x7fff85c51fff com.apple.CFOpenDirectory (10.8 - 151.10) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff85dd2000 - 0x7fff85e8fff7 com.apple.ColorSync (4.8.0 - 4.8.0) <6CE333AE-EDDB-3768-9598-9DB38041DC55> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff85e90000 - 0x7fff86004fff com.apple.CFNetwork (596.2.3 - 596.2.3) <6A16C2BD-1035-30F9-AE96-D9E3BB54A976> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff86005000 - 0x7fff86014ff7 libxar.1.dylib (105) <370ED355-E516-311E-BAFD-D80633A84BE1> /usr/lib/libxar.1.dylib 0x7fff86015000 - 0x7fff8601dfff liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib 0x7fff8601e000 - 0x7fff8609cff7 com.apple.securityfoundation (6.0 - 55115.4) /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff87139000 - 0x7fff8714bff7 libz.1.dylib (43) <2A1551E8-A272-3DE5-B692-955974FE1416> /usr/lib/libz.1.dylib 0x7fff87171000 - 0x7fff8719bff7 com.apple.CoreVideo (1.8 - 99.3) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff87245000 - 0x7fff8724bfff com.apple.DiskArbitration (2.5.1 - 2.5.1) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff873be000 - 0x7fff873c2fff com.apple.IOSurface (86.0.3 - 86.0.3) /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff873c3000 - 0x7fff873d0fff com.apple.AppleFSCompression (49 - 1.0) <5508344A-2A7E-3122-9562-6F363910A80E> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x7fff87652000 - 0x7fff8776bff7 com.apple.ImageIO.framework (3.2.0 - 845) <553B9828-A7D9-3AE4-A214-1C33417545FD> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff8776c000 - 0x7fff877bbff7 libFontRegistry.dylib (100) <2E03D7DA-9B8F-31BB-8FB5-3D3B6272127F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff877bc000 - 0x7fff877c3fff libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib 0x7fff877c4000 - 0x7fff877f0ff7 libRIP.A.dylib (324.6) <5A7EB5C2-BA60-36D7-BF41-9853F37837AA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x7fff877f1000 - 0x7fff877ffff7 libkxld.dylib (2050.18.24) <7027CE49-007D-3553-8FFA-3E3B428B2316> /usr/lib/system/libkxld.dylib 0x7fff87800000 - 0x7fff87815ff7 libdispatch.dylib (228.23) /usr/lib/system/libdispatch.dylib 0x7fff87bb5000 - 0x7fff87c37fff com.apple.Heimdal (3.0 - 2.0) <660A6C64-4912-32C8-A332-B64164032A2D> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x7fff87c43000 - 0x7fff87c60fff com.apple.openscripting (1.3.6 - 148.2) <33B87CFB-CACC-3EBC-893D-38AECB94FB8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff87c61000 - 0x7fff87ca1fff com.apple.MediaKit (13 - 659) <0C56D7FF-0430-3199-9952-CF8577519449> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit 0x7fff87d56000 - 0x7fff87ea7fff com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <833DA682-A3C1-39E7-AEC3-9EDC734DE2A9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff88018000 - 0x7fff8811afff libcrypto.0.9.8.dylib (47) <74F165AD-4572-3B26-B0E2-A97477FE59D0> /usr/lib/libcrypto.0.9.8.dylib 0x7fff8811b000 - 0x7fff88226fff libFontParser.dylib (84.5) <617A7D30-C7BC-39FC-A1FE-59367B4A5719> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff88227000 - 0x7fff8826bfff libcups.2.dylib (327) <9B3F3321-D2BC-3195-BF20-4008FC52A390> /usr/lib/libcups.2.dylib 0x7fff8826f000 - 0x7fff88349ff7 com.apple.backup.framework (1.4.1 - 1.4.1) /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x7fff8834a000 - 0x7fff88392fff libcurl.4.dylib (69.2) /usr/lib/libcurl.4.dylib 0x7fff88393000 - 0x7fff883bafff com.apple.framework.familycontrols (4.1 - 410) /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x7fff883c0000 - 0x7fff883e7ff7 com.apple.PerformanceAnalysis (1.16 - 16) /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x7fff883e8000 - 0x7fff883e8fff com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff883ed000 - 0x7fff88437ff7 libGLU.dylib (8.6.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff8843c000 - 0x7fff8845cfff libPng.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff8845d000 - 0x7fff8852fff7 com.apple.CoreText (260.0 - 275.16) <5BFC1D67-6A6F-38BC-9D90-9C712684EDAC> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff885a7000 - 0x7fff885feff7 com.apple.ScalableUserInterface (1.0 - 1) /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface 0x7fff8873d000 - 0x7fff88741fff libCGXType.A.dylib (324.6) <2FC25246-A69F-3F81-9AC6-0A1753E1C6A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x7fff89051000 - 0x7fff89094fff com.apple.RemoteViewServices (2.0 - 80.5) /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x7fff890c2000 - 0x7fff890d0fff com.apple.Librarian (1.1 - 1) <1635162F-239A-341E-83C7-710C55E254AF> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian 0x7fff890d1000 - 0x7fff8913afff libstdc++.6.dylib (56) /usr/lib/libstdc++.6.dylib 0x7fff8913b000 - 0x7fff8914ffff libGL.dylib (8.6.1) <2E00615F-97F5-34EB-BE07-75A24F3C18D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff89150000 - 0x7fff89ae0c67 com.apple.CoreGraphics (1.600.0 - 324.6) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff89ae1000 - 0x7fff89ae9ff7 libsystem_dnssd.dylib (379.32.1) <62AA0B84-188A-348B-8F9E-3E2DB08DB93C> /usr/lib/system/libsystem_dnssd.dylib 0x7fff89aea000 - 0x7fff89af0ff7 libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib 0x7fff89b0a000 - 0x7fff89b1dff7 libbsm.0.dylib (32) /usr/lib/libbsm.0.dylib 0x7fff89b1e000 - 0x7fff89b8bfff com.apple.datadetectorscore (4.0 - 269.1) /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x7fff89b8c000 - 0x7fff89bc2fff libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib 0x7fff89c72000 - 0x7fff89c80fff libcommonCrypto.dylib (60026) <2D6537F5-1B5E-305C-A1CF-D1FA80CA3939> /usr/lib/system/libcommonCrypto.dylib 0x7fff89c81000 - 0x7fff89d7efff libsqlite3.dylib (138.1) /usr/lib/libsqlite3.dylib 0x7fff8a539000 - 0x7fff8a593fff com.apple.print.framework.PrintCore (8.1 - 387.1) <1FA17B75-33E6-35BD-9198-35F92E37B248> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff8a5db000 - 0x7fff8a5f2fff com.apple.GenerationalStorage (1.1 - 132.2) <3F5C87BD-D866-3732-8CB9-D23ED9784D6E> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x7fff8a5f3000 - 0x7fff8a779fff libBLAS.dylib (1073.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff8a80c000 - 0x7fff8a849fe7 libGLImage.dylib (8.6.1) <7F31DD61-3110-3541-A9BB-035CD1262E50> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff8a856000 - 0x7fff8a85aff7 com.apple.CommonPanels (1.2.5 - 94) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff8a85b000 - 0x7fff8a860fff libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib 0x7fff8b016000 - 0x7fff8b01aff7 com.apple.TCC (1.0 - 1) /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x7fff8b043000 - 0x7fff8b04afff com.apple.NetFS (5.0 - 4.0) <82E24B9A-7742-3DA3-9E99-ED267D98C05E> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff8b05e000 - 0x7fff8b05ffff libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff8b060000 - 0x7fff8b065fff libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib 0x7fff8b066000 - 0x7fff8b0d3ff7 com.apple.framework.IOKit (2.0 - 755.18.10) <142E19DD-1C8D-3D61-ABC8-83994A73279F> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff8b0d4000 - 0x7fff8b155fff com.apple.Metadata (10.7.0 - 707.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff8b156000 - 0x7fff8b159ff7 libdyld.dylib (210.2.3) /usr/lib/system/libdyld.dylib 0x7fff8b15a000 - 0x7fff8b188ff7 libsystem_m.dylib (3022.6) /usr/lib/system/libsystem_m.dylib 0x7fff8bcaa000 - 0x7fff8bd37ff7 com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff8bd38000 - 0x7fff8bd38fff libkeymgr.dylib (25) /usr/lib/system/libkeymgr.dylib 0x7fff8bd39000 - 0x7fff8bd4cff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <2F2694E9-A7BC-33C7-B4CF-8EC907DF0FEB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff8be6c000 - 0x7fff8be6ffff com.apple.help (1.3.2 - 42) <343904FE-3022-3573-97D6-5FE17F8643BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff8be72000 - 0x7fff8bf0cfff com.apple.CoreSymbolication (3.0 - 87) <75F2C0DD-549A-36F6-BD9E-FB40A924344F> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x7fff8bf1b000 - 0x7fff8c010fff libiconv.2.dylib (34) /usr/lib/libiconv.2.dylib 0x7fff8c011000 - 0x7fff8c2b5fff com.apple.CoreImage (8.2.2 - 1.0.1) <930B0B23-DD84-3B0C-B5A9-C09B7068A6F0> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x7fff8c2bb000 - 0x7fff8c2bbfff com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff8c2bc000 - 0x7fff8c2bcffd com.apple.audio.units.AudioUnit (1.8 - 1.8) <29E2C990-3617-3FA2-BDD7-DB7DF493E443> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff8c2bd000 - 0x7fff8c2bffff com.apple.securityhi (4.0 - 55002) <34E45C60-DC7E-3FCC-A1ED-EBF48B77C559> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff8c544000 - 0x7fff8c575ff7 com.apple.DictionaryServices (1.2 - 184.4) <054F2D6F-9CFF-3EF1-9778-25C551B616C1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff8c5d6000 - 0x7fff8c7bffff com.apple.CoreFoundation (6.8 - 744.12) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8c7ce000 - 0x7fff8c7cefff com.apple.Cocoa (6.7 - 19) <1F77945C-F37A-3171-B22E-F7AB0FCBB4D4> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x7fff8c81b000 - 0x7fff8ca1bfff libicucore.A.dylib (491.11.1) /usr/lib/libicucore.A.dylib 0x7fff8ca65000 - 0x7fff8cb67fff libJP2.dylib (845) <405CAF25-0AA5-3C6B-A4A6-94471A1EDD2F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x7fff8cddd000 - 0x7fff8d1fafff FaceCoreLight (2.4.1) /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight 0x7fff8d1fb000 - 0x7fff8d24aff7 libcorecrypto.dylib (106.2) /usr/lib/system/libcorecrypto.dylib 0x7fff8d438000 - 0x7fff8d473fff com.apple.LDAPFramework (2.4.28 - 194.5) <0190B746-F684-3F43-B4D0-148EFE386CA4> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff8d474000 - 0x7fff8d47dfff com.apple.CommerceCore (1.0 - 26) <997CD214-BC78-3C61-A1B8-813EA1CB9997> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x7fff8d4b1000 - 0x7fff8e0deff7 com.apple.AppKit (6.8 - 1187.34) <1FF64844-EB62-3F96-AED7-6525B7CCEC23> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff8e139000 - 0x7fff8e13dfff libpam.2.dylib (20) /usr/lib/libpam.2.dylib 0x7fff8e1ae000 - 0x7fff8e27afe7 libsystem_c.dylib (825.25) <8CBCF9B9-EBB7-365E-A3FF-2F3850763C6B> /usr/lib/system/libsystem_c.dylib 0x7fff8e27b000 - 0x7fff8e29cff7 libCRFSuite.dylib (33) <736ABE58-8DED-3289-A042-C25AF7AE5B23> /usr/lib/libCRFSuite.dylib 0x7fff8e29d000 - 0x7fff8e2aaff7 com.apple.NetAuth (4.0 - 4.0) /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x7fff8e2ab000 - 0x7fff8e6a2fff libLAPACK.dylib (1073.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff8e6a3000 - 0x7fff8e6b0fff libbz2.1.0.dylib (29) /usr/lib/libbz2.1.0.dylib 0x7fff8e6b1000 - 0x7fff8e6b3fff libquarantine.dylib (52) <4BE2E642-A14F-340A-B482-5BD2AEFD9C24> /usr/lib/system/libquarantine.dylib 0x7fff8e705000 - 0x7fff8e7abff7 com.apple.CoreServices.OSServices (557.4 - 557.4) <841878A8-6F3E-300D-8F01-444B3CC1F41D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff8e7ac000 - 0x7fff8e7f8ff7 libauto.dylib (185.1) <73CDC482-16E3-3FC7-9BB4-FBA2DA44DBC2> /usr/lib/libauto.dylib 0x7fff8e8b2000 - 0x7fff8e8d1ff7 com.apple.ChunkingLibrary (2.0 - 133.2) /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x7fff8e8d2000 - 0x7fff8e927ff7 libTIFF.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff8ec39000 - 0x7fff8ec3bfff com.apple.TrustEvaluationAgent (2.0 - 23) /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff8ec3c000 - 0x7fff8f37eff7 libclh.dylib (4.0.3 - 4.0.3) <16FC7127-61C7-3F3A-870E-16CD38E5BB37> /System/Library/Extensions/GeForceGLDriver.bundle/Contents/MacOS/libclh.dylib 0x7fff8f37f000 - 0x7fff8f380ff7 libdnsinfo.dylib (453.18) /usr/lib/system/libdnsinfo.dylib 0x7fff8f381000 - 0x7fff8f38cff7 com.apple.bsd.ServiceManagement (2.0 - 2.0) /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x7fff8f45e000 - 0x7fff8f47ffff com.apple.Ubiquity (1.2 - 243.10) /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity 0x7fff8f4d0000 - 0x7fff8f4d4fff libCoreVMClient.dylib (24.4) <55F71158-ADEE-3863-92E9-4772DCEA8E31> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff8f4d5000 - 0x7fff8f4e6ff7 libsasl2.2.dylib (166) <649CAE0E-8FFE-3C60-A849-BE6300E4B726> /usr/lib/libsasl2.2.dylib 0x7fff8f4e7000 - 0x7fff8f598fff com.apple.LaunchServices (539.7 - 539.7) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff8f599000 - 0x7fff8f59bff7 com.apple.print.framework.Print (8.0 - 258) <34666CC2-B86D-3313-B3B6-A9977AD593DA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff8f59c000 - 0x7fff8f5a6fff com.apple.speech.recognition.framework (4.1.5 - 4.1.5) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff8f5a7000 - 0x7fff8f641fff libvMisc.dylib (380.6) <714336EA-1C0E-3735-B31C-19DFDAAF6221> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff8f656000 - 0x7fff8f675ff7 libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib 0x7fff8f676000 - 0x7fff8f677ff7 libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib 0x7fff8f678000 - 0x7fff8f693ff7 libsystem_kernel.dylib (2050.18.24) /usr/lib/system/libsystem_kernel.dylib 0x7fff8f694000 - 0x7fff8f6e5ff7 com.apple.SystemConfiguration (1.12.2 - 1.12.2) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff8f6e6000 - 0x7fff8f74efff libvDSP.dylib (380.6) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff8f7db000 - 0x7fff8f843ff7 libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib 0x7fff8f844000 - 0x7fff8f844fff com.apple.Accelerate (1.8 - Accelerate 1.8) <6AD48543-0864-3D40-80CE-01F184F24B45> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff8f877000 - 0x7fff8fb47fff com.apple.security (7.0 - 55179.1) <639641EF-8156-3190-890C-1053658E044A> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff8fb8c000 - 0x7fff8fbaeff7 com.apple.Kerberos (2.0 - 1) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff8fbb2000 - 0x7fff8fbc8fff com.apple.MultitouchSupport.framework (235.28 - 235.28) /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff8fbc9000 - 0x7fff8fbcdfff libGIF.dylib (845) <2690CE83-E934-3EF8-A30A-996EDADCE3E4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff8fc29000 - 0x7fff8fdd7fff com.apple.QuartzCore (1.8 - 304.0) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff8fdd8000 - 0x7fff8fe00fff libJPEG.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff8fe01000 - 0x7fff8fe03ff7 libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib 0x7fff8fe04000 - 0x7fff8fe04fff com.apple.ApplicationServices (45 - 45) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff8fe05000 - 0x7fff8fe62fff com.apple.audio.CoreAudio (4.1.0 - 4.1.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff9024f000 - 0x7fff902cfff7 com.apple.ApplicationServices.ATS (332 - 341.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff902d0000 - 0x7fff90505ff7 com.apple.CoreData (106.1 - 407.7) <24E0A6B4-9ECA-3D12-B26A-72B9DCF09768> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff9096e000 - 0x7fff909a4fff com.apple.DebugSymbols (98 - 98) <14E788B1-4EB2-3FD7-934B-849534DFC198> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x7fff909a5000 - 0x7fff90a01ff7 com.apple.Symbolication (1.3 - 93) /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x7fff90a5f000 - 0x7fff90a5ffff libOpenScriptingUtil.dylib (148.2) /usr/lib/libOpenScriptingUtil.dylib 0x7fff90a60000 - 0x7fff90a8efff com.apple.CoreServicesInternal (154.2 - 154.2) <3E6196E6-F3B4-316F-9E1F-13B6B9694C7E> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0x7fff90a8f000 - 0x7fff90dbfff7 com.apple.HIToolbox (2.0 - 625) <317F75F7-4B0F-35F5-89A7-F20BA60AC944> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff90dcc000 - 0x7fff90ec9ff7 libxml2.2.dylib (22.3) <47B09CB2-C636-3024-8B55-6040F7829B4C> /usr/lib/libxml2.2.dylib 0x7fff90f25000 - 0x7fff90f3afff com.apple.ImageCapture (8.0 - 8.0) <17A45CE6-7DA3-36A5-B7EF-72BC136981AE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff90f3b000 - 0x7fff91252ff7 com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff91253000 - 0x7fff91259fff libGFXShared.dylib (8.6.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff9125a000 - 0x7fff9125dfff libRadiance.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff91297000 - 0x7fff912abfff com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <94EDF2AB-809C-3D15-BED5-7AD45B2A7C16> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff912ac000 - 0x7fff912aefff libCVMSPluginSupport.dylib (8.6.1) <7EFDA31E-E463-3897-A8DC-7FD266EB713E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x7fff9133c000 - 0x7fff9133dfff libsystem_blocks.dylib (59) /usr/lib/system/libsystem_blocks.dylib 0x7fff9133e000 - 0x7fff9139bff7 com.apple.AE (645.3 - 645.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff9139c000 - 0x7fff913f2fff com.apple.HIServices (1.20 - 417) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff91431000 - 0x7fff91456ff7 libc++abi.dylib (24.4) /usr/lib/libc++abi.dylib 0x7fff91457000 - 0x7fff91496ff7 com.apple.QD (3.42 - 285) <8DF36FCA-C06B-30F4-A631-7BE2FF7E56D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff914ac000 - 0x7fff914b7fff libsystem_notify.dylib (98.5) /usr/lib/system/libsystem_notify.dylib 0x7fff914b8000 - 0x7fff914c4fff com.apple.CrashReporterSupport (10.8.2 - 415) <55783BF9-125E-3F9C-A412-6A095ECD9353> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x7fff914c5000 - 0x7fff914f0fff libxslt.1.dylib (11.3) <441776B8-9130-3893-956F-39C85FFA644F> /usr/lib/libxslt.1.dylib 0x7fff914f1000 - 0x7fff9152bfff com.apple.GSS (3.0 - 2.0) <0BDF8090-5EF4-3759-94DE-8521D74188AA> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x7fff9152c000 - 0x7fff9164492f libobjc.A.dylib (532.2) <90D31928-F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib 0x7fff91645000 - 0x7fff91651fff libCSync.A.dylib (324.6) <2033247A-CABC-3E20-8498-7367A8F44A08> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x7fff91652000 - 0x7fff91661ff7 com.apple.opengl (1.8.6 - 1.8.6) <720CC06C-0D01-37AE-BB3D-D7F0242B262A> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff91662000 - 0x7fff91667fff com.apple.OpenDirectory (10.8 - 151.10) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff91668000 - 0x7fff9172dff7 com.apple.coreui (2.0 - 181.1) <83D2C92D-6842-3C9D-9289-39D5B4554C3A> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff9172e000 - 0x7fff9172fff7 libremovefile.dylib (23.1) /usr/lib/system/libremovefile.dylib 0x7fff919b7000 - 0x7fff91a55ff7 com.apple.ink.framework (10.8.2 - 150) <84B9825C-3822-375F-BE58-A753444FBDE2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff91afe000 - 0x7fff91bd1ff7 com.apple.DiscRecording (7.0 - 7000.2.4) <49FD2D2F-4F2C-39B6-877B-6E3172577D18> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording 0x7fff91bd2000 - 0x7fff91cf2fff com.apple.desktopservices (1.7.2 - 1.7.2) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff91cf3000 - 0x7fff9204ffff com.apple.Foundation (6.8 - 945.11) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff92050000 - 0x7fff920a6ff7 com.apple.opencl (2.1.20 - 2.1.20) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff920a7000 - 0x7fff920b5ff7 libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib 0x7fff920b6000 - 0x7fff920b6fff com.apple.CoreServices (57 - 57) <9DD44CB0-C644-35C3-8F57-0B41B3EC147D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff921d1000 - 0x7fff921d7fff libmacho.dylib (829) /usr/lib/system/libmacho.dylib 0x7fff92531000 - 0x7fff92568ff7 libssl.0.9.8.dylib (47) <923945E6-C489-3406-903B-A362410753F8> /usr/lib/libssl.0.9.8.dylib 0x7fff925f7000 - 0x7fff925f8ff7 libsystem_sandbox.dylib (220) <3C3B03CF-C525-3CB3-8557-62E91B93AC95> /usr/lib/system/libsystem_sandbox.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 2 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 23944 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=185.9M resident=145.0M(78%) swapped_out_or_unallocated=40.9M(22%) Writable regions: Total=452.0M written=61.6M(14%) resident=157.9M(35%) swapped_out=0K(0%) unallocated=294.1M(65%) REGION TYPE VIRTUAL =========== ======= (null) (reserved) 105.1M reserved VM address space (unallocated) ATS (font support) 31.9M ATS (font support) (reserved) 4K reserved VM address space (unallocated) CG backing stores 828K CG image 1036K CG shared images 192K CoreAnimation 368K CoreImage 8K CoreServices 2940K IOKit 74.3M MALLOC 103.6M MALLOC guard page 48K MALLOC_LARGE (reserved) 400K reserved VM address space (unallocated) Memory tag=242 12K OpenCL 20K OpenGL GLSL 1024K STACK GUARD 56.1M Stack 38.8M VM_ALLOCATE 91.7M __DATA 19.9M __IMAGE 528K __LINKEDIT 59.1M __TEXT 126.8M __UNICODE 544K mapped file 44.2M shared memory 3932K =========== ======= TOTAL 763.0M TOTAL, minus reserved VM space 657.5M Model: MacBookPro6,2, BootROM MBP61.0057.B0F, 2 processors, Intel Core i5, 2.53 GHz, 8 GB, SMC 1.58f16 Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 256 MB Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x0198, 0x393930353432382D3030352E4130324C4620 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x0198, 0x393930353432382D3030352E4130324C4620 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.106.98.81.22) Bluetooth: Version 4.0.9f33 10885, 2 service, 11 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: TOSHIBA MK5055GSXF, 500.11 GB Serial ATA Device: MATSHITADVD-R UJ-898 USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfa100000 / 2 USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0236, 0xfa120000 / 5 USB Device: Internal Memory Card Reader, apple_vendor_id, 0x8403, 0xfa130000 / 4 USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 3 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8218, 0xfa113000 / 6 USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfd100000 / 2 USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd120000 / 4 USB Device: Built-in iSight, apple_vendor_id, 0x8507, 0xfd110000 / 3 From johan at lodgon.com Tue Oct 23 10:05:56 2012 From: johan at lodgon.com (Johan Vos) Date: Tue, 23 Oct 2012 19:05:56 +0200 Subject: Where is development branch for the source code and is it open for contribution In-Reply-To: <20120915201124.242840@gmx.com> References: <20120915201124.242840@gmx.com> Message-ID: I'm using http://hg.openjdk.java.net/openjfx/8/masterand that works with the latest OpenJDK (jdk8) build. - Johan 2012/9/15 Tom Rhodes > Hi! > > openJFX page points to the http://hg.openjdk.java.net/openjfx/2.2/master or > http://hg.openjdk.java.net/openjfx/2.1/master > http://hg.openjdk.java.net/openjfx/2.2/master - but these repositories > has quite old (more than 6 months) changes only. What is the address of the > repository where the ongoing chances are commited. (I tried to guess > address - like http://hg.openjdk.java.net/openjfx/3.0 - but it has lead > to errors). > > And is this development repository open for contributions? > > I am interested in development of advanced JavaFX grid (tableView) > control and I feel that from time to time it would be nice to see what > happens with the original TableView or maybe even to contribute to it. > > Thanks! > TomR > From scott.kovatch at oracle.com Tue Oct 23 10:26:00 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 23 Oct 2012 10:26:00 -0700 Subject: Native crash on OS X while trying to reproduce memory leak. In-Reply-To: References: Message-ID: <0957BDEF-41F7-48C2-AFAD-9E5AD9F7C225@oracle.com> On Oct 21, 2012, at 3:49 PM, Scott Palmer wrote: > Running 7u10-b12 ea (With JavaFX 2.2.4-ea) > > My test app didn't appear to leak on the Java Heap.. so I walked away for a while and when I came back the following crash report was waiting for me: > I can't tell if it is a JFX issue or not? It looks like it may be a video card driver issue. But I figured I would un it by you guys just in case. > > Scott The crashed thread: > Thread 28 Crashed:: CVDisplayLink > 0 libsystem_kernel.dylib 0x00007fff8f68a212 __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff8e1c3af4 pthread_kill + 90 > 2 libsystem_c.dylib 0x00007fff8e207dce abort + 143 > 3 libjvm.dylib 0x000000010f2a3c93 os::abort(bool) + 25 > 4 libjvm.dylib 0x000000010f39244e VMError::report_and_die() + 2306 > 5 libjvm.dylib 0x000000010f2a5387 JVM_handle_bsd_signal + 1073 > 6 libsystem_c.dylib 0x00007fff8e1b08ea _sigtramp + 26 > 7 com.apple.GeForceGLDriver 0x00000002000a8e05 0x200000000 + 691717 > 8 com.apple.GeForceGLDriver 0x00000002000d9545 0x200000000 + 890181 > 9 libGPUSupport.dylib 0x00000001211e24d5 gldDestroyTexture + 26 > 10 libGFXShared.dylib 0x00007fff91256fd1 gfxDestroyPluginTexture + 55 > 11 GLEngine 0x0000000120fda3f8 gleFreeTextureObject + 37 > 12 GLEngine 0x0000000120fac868 gleUnbindDeleteHashNamesAndObjects + 166 > 13 GLEngine 0x0000000120e8c854 glDeleteTextures_Exec + 732 > 14 com.apple.QuartzCore 0x00007fff8fc7d707 CA::OGL::CGLContext::delete_image(CA::OGL::Image*) + 121 > 15 com.apple.QuartzCore 0x00007fff8fc6e0e3 CA::OGL::Context::collect(bool) + 361 > 16 com.apple.QuartzCore 0x00007fff8fc6df55 CA::OGL::GLContext::collect(bool) + 25 > 17 com.apple.QuartzCore 0x00007fff8fc6df1b CA::OGL::CGLContext::collect(bool) + 21 > 18 com.apple.QuartzCore 0x00007fff8fc65eec view_draw(_CAView*, double, CVTimeStamp const*, bool) + 3982 > 19 com.apple.QuartzCore 0x00007fff8fc6ecd7 view_display_link(double, CVTimeStamp const*, void*) + 139 > 20 com.apple.QuartzCore 0x00007fff8fc6ebc2 link_callback + 244 > 21 com.apple.CoreVideo 0x00007fff8717403d CVDisplayLink::performIO(CVTimeStamp*) + 203 > 22 com.apple.CoreVideo 0x00007fff871732a4 CVDisplayLink::runIOThread() + 632 > 23 com.apple.CoreVideo 0x00007fff87173013 startIOThread(void*) + 148 > 24 libsystem_c.dylib 0x00007fff8e1c2742 _pthread_start + 327 > 25 libsystem_c.dylib 0x00007fff8e1af181 thread_start + 13 All of that, except for the signal handling code, is Apple code. It's probably going to be hard to know if we fed it garbage or a bug in the GL driver. Another thing I noticed, but probably not related to this specific problem: > 0x11c299000 - 0x11c2a2ff7 com.apple.java.JavaRuntimeSupport (14.5.0 - 14.5.0) /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport > 0x11c2b1000 - 0x11c2bbfff JavaNativeFoundation (1) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation > 0x11c2c6000 - 0x11c2cbfff com.apple.JavaVM (14.5.0 - 14.5.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM > 0x11c2d3000 - 0x11c2d8fff JavaLaunching (1) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching How are you getting this code to load? Is this a bundled application? I would only expect to see this code with Apple's application stub. It could be that JavaVM.framework is pulling it in -- JavaNativeFoundation and JavaRuntimeSupport rely on it. Just curious?. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From swpalmer at gmail.com Tue Oct 23 12:05:50 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 23 Oct 2012 15:05:50 -0400 Subject: Native crash on OS X while trying to reproduce memory leak. In-Reply-To: <0957BDEF-41F7-48C2-AFAD-9E5AD9F7C225@oracle.com> References: <0957BDEF-41F7-48C2-AFAD-9E5AD9F7C225@oracle.com> Message-ID: <93360AB7-26AB-4792-924D-4BBB1F579592@gmail.com> On 2012-10-23, at 1:26 PM, Scott Kovatch wrote: > > On Oct 21, 2012, at 3:49 PM, Scott Palmer wrote: > > The crashed thread: > >> Thread 28 Crashed:: CVDisplayLink >> 0 libsystem_kernel.dylib 0x00007fff8f68a212 __pthread_kill + 10 >> > > All of that, except for the signal handling code, is Apple code. It's probably going to be hard to know if we fed it garbage or a bug in the GL driver. What I expected. Perhaps the crash report will eventually trickle down to somebody at Apple that can do something more. > Another thing I noticed, but probably not related to this specific problem: > >> 0x11c299000 - 0x11c2a2ff7 com.apple.java.JavaRuntimeSupport (14.5.0 - 14.5.0) /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport >> 0x11c2b1000 - 0x11c2bbfff JavaNativeFoundation (1) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation >> 0x11c2c6000 - 0x11c2cbfff com.apple.JavaVM (14.5.0 - 14.5.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM >> 0x11c2d3000 - 0x11c2d8fff JavaLaunching (1) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching > > How are you getting this code to load? It is a NetBeans 7.2 Swing + JavaFX project that was run from the IDE. > Is this a bundled application? No. But I haven't looked into the magic that the NB Ant script is doing for Swing + JavaFX it even makes a main class derived from Applet for some reason.. I didn't bother to sanitize it. > I would only expect to see this code with Apple's application stub. It could be that JavaVM.framework is pulling it in -- JavaNativeFoundation and JavaRuntimeSupport rely on it. > > Just curious?. Now you've got me curious too. Scott P. From swingler at apple.com Tue Oct 23 12:12:14 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 23 Oct 2012 12:12:14 -0700 Subject: Native crash on OS X while trying to reproduce memory leak. In-Reply-To: <93360AB7-26AB-4792-924D-4BBB1F579592@gmail.com> References: <0957BDEF-41F7-48C2-AFAD-9E5AD9F7C225@oracle.com> <93360AB7-26AB-4792-924D-4BBB1F579592@gmail.com> Message-ID: <21826FC9-8B09-4D4E-8E2E-87DEC8DCB243@apple.com> On Oct 23, 2012, at 12:05 PM, Scott Palmer wrote: > > On 2012-10-23, at 1:26 PM, Scott Kovatch wrote: > >> >> On Oct 21, 2012, at 3:49 PM, Scott Palmer wrote: >> >> The crashed thread: >> >>> Thread 28 Crashed:: CVDisplayLink >>> 0 libsystem_kernel.dylib 0x00007fff8f68a212 __pthread_kill + 10 >>> >> >> All of that, except for the signal handling code, is Apple code. It's probably going to be hard to know if we fed it garbage or a bug in the GL driver. > > What I expected. Perhaps the crash report will eventually trickle down to somebody at Apple that can do something more. Not if the JVM is catching it. HotSpot should actually not catch crashes that are on threads that are not attached to the JVM. >> Another thing I noticed, but probably not related to this specific problem: >> >>> 0x11c299000 - 0x11c2a2ff7 com.apple.java.JavaRuntimeSupport (14.5.0 - 14.5.0) /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport >>> 0x11c2b1000 - 0x11c2bbfff JavaNativeFoundation (1) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation >>> 0x11c2c6000 - 0x11c2cbfff com.apple.JavaVM (14.5.0 - 14.5.0) <83C8C2AB-E99D-39FF-80B4-90A7DEB1DAFB> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM >>> 0x11c2d3000 - 0x11c2d8fff JavaLaunching (1) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching >> >> How are you getting this code to load? > > It is a NetBeans 7.2 Swing + JavaFX project that was run from the IDE. > >> Is this a bundled application? > > No. But I haven't looked into the magic that the NB Ant script is doing for Swing + JavaFX it even makes a main class derived from Applet for some reason.. I didn't bother to sanitize it. > >> I would only expect to see this code with Apple's application stub. It could be that JavaVM.framework is pulling it in -- JavaNativeFoundation and JavaRuntimeSupport rely on it. >> >> Just curious?. > > Now you've got me curious too. This is normal. The AWT and Aqua LaF in Java 7 links against JavaNativeFoundation and JavaRuntimeSupport to do it's business. Regards, Mike Swingler Apple Inc. From swpalmer at gmail.com Tue Oct 23 12:20:37 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 23 Oct 2012 15:20:37 -0400 Subject: Native crash on OS X while trying to reproduce memory leak. In-Reply-To: <21826FC9-8B09-4D4E-8E2E-87DEC8DCB243@apple.com> References: <0957BDEF-41F7-48C2-AFAD-9E5AD9F7C225@oracle.com> <93360AB7-26AB-4792-924D-4BBB1F579592@gmail.com> <21826FC9-8B09-4D4E-8E2E-87DEC8DCB243@apple.com> Message-ID: On 2012-10-23, at 3:12 PM, Mike Swingler wrote: > On Oct 23, 2012, at 12:05 PM, Scott Palmer wrote: > >> >> On 2012-10-23, at 1:26 PM, Scott Kovatch wrote: >> >>> >>> On Oct 21, 2012, at 3:49 PM, Scott Palmer wrote: >>> >>> The crashed thread: >>> >>>> Thread 28 Crashed:: CVDisplayLink >>>> 0 libsystem_kernel.dylib 0x00007fff8f68a212 __pthread_kill + 10 >>>> >>> >>> All of that, except for the signal handling code, is Apple code. It's probably going to be hard to know if we fed it garbage or a bug in the GL driver. >> >> What I expected. Perhaps the crash report will eventually trickle down to somebody at Apple that can do something more. > > Not if the JVM is catching it. HotSpot should actually not catch crashes that are on threads that are not attached to the JVM. The standard OS X crash reporter window opened and I submitted the report. Doesn't that mean that it will get in the queue to be reviewed by Apple? (Perhaps after a few duplicate stack traces or something?) Scott P. From swingler at apple.com Tue Oct 23 12:27:08 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 23 Oct 2012 12:27:08 -0700 Subject: Native crash on OS X while trying to reproduce memory leak. In-Reply-To: References: <0957BDEF-41F7-48C2-AFAD-9E5AD9F7C225@oracle.com> <93360AB7-26AB-4792-924D-4BBB1F579592@gmail.com> <21826FC9-8B09-4D4E-8E2E-87DEC8DCB243@apple.com> Message-ID: <4E6C9F61-5CBD-4621-A163-453233E92DEC@apple.com> On Oct 23, 2012, at 12:20 PM, Scott Palmer wrote: > On 2012-10-23, at 3:12 PM, Mike Swingler wrote: > >> On Oct 23, 2012, at 12:05 PM, Scott Palmer wrote: >> >>> >>> On 2012-10-23, at 1:26 PM, Scott Kovatch wrote: >>> >>>> >>>> On Oct 21, 2012, at 3:49 PM, Scott Palmer wrote: >>>> >>>> The crashed thread: >>>> >>>>> Thread 28 Crashed:: CVDisplayLink >>>>> 0 libsystem_kernel.dylib 0x00007fff8f68a212 __pthread_kill + 10 >>>>> >>>> >>>> All of that, except for the signal handling code, is Apple code. It's probably going to be hard to know if we fed it garbage or a bug in the GL driver. >>> >>> What I expected. Perhaps the crash report will eventually trickle down to somebody at Apple that can do something more. >> >> Not if the JVM is catching it. HotSpot should actually not catch crashes that are on threads that are not attached to the JVM. > > The standard OS X crash reporter window opened and I submitted the report. Doesn't that mean that it will get in the queue to be reviewed by Apple? (Perhaps after a few duplicate stack traces or something?) It will be transmitted to Apple, however it will simply be glommed together with all of the other "crashes in 3rd party Java" if Java 7's HotSpot is busy handling the crash. Regards, Mike Swingler Apple Inc. From phidias51 at gmail.com Tue Oct 23 12:37:02 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 23 Oct 2012 12:37:02 -0700 Subject: Service & Data Binding In JavaFX and SceneBuilder Message-ID: After using SceneBuilder through the latter half of my project, I've become convinced that it is THE way to build JavaFX GUIs. However, the one thing that I'm missing is the kind of drag and drop binding of data sources to widgets that you could do in Project Rave. I was wondering if this was in the works? Specifically, I'd like to be able to register a data source and simply bind it to widget. In my case, most of the existing services are RESTful services that return JSON objects, and it would greatly speed things up, if I could simply point a combobox to a RESTful service responsible for populating the combobox, and then bind the combobox's change listener, to save the user's selection by invoking another RESTful service. Ideally, you would be able to use different types of service protocols. For example, you might have a combination of RESTful services, XML-HTTP, or bytestream-based services. Cheers, Mark From steve.x.northover at oracle.com Tue Oct 23 13:30:57 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 23 Oct 2012 16:30:57 -0400 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: References: Message-ID: <5086FE81.8000601@oracle.com> Hi all, I have been looking into Node Orientation which is an API that controls the directionality of a Node. This is different from BIDI or the BIDI algorithm which governs the direction of text. Node orientation concerns the flow of visual data which is either left-to-right or right-to-left. The best example is a tree control. In tree control that is oriented right-to-left, the expansion arrows point to the right and the branches of the tree expand from the right to the left. https://wikis.oracle.com/display/OpenJDK/Node+Orientation+in+JavaFX Steve From pedro.duquevieira at gmail.com Tue Oct 23 17:03:46 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 24 Oct 2012 01:03:46 +0100 Subject: Fwd: TableView - listening to events on table headers In-Reply-To: References: Message-ID: Somehow my email below didn't get any response so I'm sending it again.. ---------- Forwarded message ---------- From: Pedro Duque Vieira Date: Tue, Oct 23, 2012 at 12:42 AM Subject: TableView - listening to events on table headers To: OpenJFX Mailing List Hi, In my app I have to listen to mouse events on table headers, I've tried to come up with a good solution to this but haven't found any. Posting in the JavaFX OTN forums also did not bring any better solution. As it is the only solution I see is replacing the headers via setGraphic method of TableColumn and attaching listeners to what I pass in to the setGraphic, even though I will end up replacing the TableColumn header with the same type of node as was previously present, so I end up calling setGraphic only for the sake of being able to attach listeners. This looks ugly. Is there any better solution for this? My use case is: 1- user mouse clicks the a table header to select a column 2- column gets selected. 3- Selected column is visually highlighted. Thanks, -- Pedro Duque Vieira -- Pedro Duque Vieira From dmdeklerk at gmail.com Tue Oct 23 17:10:52 2012 From: dmdeklerk at gmail.com (DM Klerk) Date: Wed, 24 Oct 2012 02:10:52 +0200 Subject: Bug RT-24142 crashes the VM when you touch a JSObject Message-ID: Recently I filed bug http://javafx-jira.kenai.com/browse/RT-24142, at first I couldn't pinpoint the reason but after I've created a test case the Oracle devs picked it up and soon set the bug to critical, now luckily the bug is set to resolved for Lombard. The bug causes the VM to crash every minute or so when working with DOM objects/JS objects that come from a WebEngine/WebView. It turned out there was a problem with the new webkit garbage collector which caused javafx code to try and reuse cached javascript objects that where GC'd. Since my application is constantly working with DOM objects (WebView was the reason to choose javafx) having it crash every minute is very frustrating. Can anyone tell me where or when i can get a jdk with the fix for bug http://javafx-jira.kenai.com/browse/RT-24142? Does anyone know of a workaround how you can still get a DOM Node from WebEngine and hold on to it for longer than a minute or so? Right now when I do a ((JSObject)node).call("getBoundingClientRect") (or any JSObject.call/JSObject,toString) it randomly crashes after I've performed a certain amount of work. I dont seem to understand why this is happening, will it help if i keep strong references to every JSObject/Node i ever touch, just looking for a way i can continue (while waiting for the next jdk) without constantly loosing unsaved work... Am I asking this question in the right place? Dennis From randahl at rockit.dk Tue Oct 23 18:37:25 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 24 Oct 2012 03:37:25 +0200 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? Message-ID: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? Thanks Randahl From swpalmer at gmail.com Tue Oct 23 19:00:07 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 23 Oct 2012 22:00:07 -0400 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> Message-ID: <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> JavaFX has been bundled since 7u7 anyway? but it is not on the classpath by default. Presumably someone was scared of breaking stuff. The JavaFX app packager does some magic to get it on the classpath for runtime. For Maven there are a couple of options. One is to use the dreaded "system" scope: javafx jfxrt system ${java.home}/lib/jfxrt.jar 2.2.4 Use the "enforcer" plugin to require at lest 7u7. org.apache.maven.plugins maven-enforcer-plugin enforce-java enforce 1.7.0-7 (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html) And then do the same sort of classpath hackery that the app packager stubs do for runtime. Or just use -Xbootclasspath/a: Scott On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: > I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. > > However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. > > Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? > > Thanks > > Randahl From kevin.rushforth at oracle.com Tue Oct 23 19:13:28 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Oct 2012 19:13:28 -0700 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> Message-ID: <50874EC8.1060501@oracle.com> Right. The work needed to put FX onto the classpath by default isn't done yet. It is targeted for JDK 8, with the possibility of back-porting it to JDK 7u12 / FX 2.2.6. -- Kevin Scott Palmer wrote: > JavaFX has been bundled since 7u7 anyway? but it is not on the classpath by default. Presumably someone was scared of breaking stuff. The JavaFX app packager does some magic to get it on the classpath for runtime. > > For Maven there are a couple of options. One is to use the dreaded "system" scope: > > > javafx > jfxrt > system > ${java.home}/lib/jfxrt.jar > 2.2.4 > > > Use the "enforcer" plugin to require at lest 7u7. > > > > > org.apache.maven.plugins > maven-enforcer-plugin > > > enforce-java > > enforce > > > > > 1.7.0-7 > > > > > > > > > > (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html) > > And then do the same sort of classpath hackery that the app packager stubs do for runtime. Or just use -Xbootclasspath/a: > > Scott > > On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: > > >> I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. >> >> However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. >> >> Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? >> >> Thanks >> >> Randahl >> > > From kevin.rushforth at oracle.com Tue Oct 23 19:38:38 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Oct 2012 19:38:38 -0700 Subject: Bug RT-24142 crashes the VM when you touch a JSObject In-Reply-To: References: Message-ID: <508754AE.8030901@oracle.com> > Can anyone tell me where or when i can get a jdk with the fix for bug > http://javafx-jira.kenai.com/browse/RT-24142? http://jdk8.java.net/download.html -- Kevin DM Klerk wrote: > Recently I filed bug http://javafx-jira.kenai.com/browse/RT-24142, at first > I couldn't pinpoint the reason but after I've created a test case the > Oracle devs picked it up and soon set the bug to critical, now luckily the > bug is set to resolved for Lombard. The bug causes the VM to crash every > minute or so when working with DOM objects/JS objects that come from a > WebEngine/WebView. It turned out there was a problem with the new webkit > garbage collector which caused javafx code to try and reuse cached > javascript objects that where GC'd. > > Since my application is constantly working with DOM objects (WebView was > the reason to choose javafx) having it crash every minute is very > frustrating. > > Can anyone tell me where or when i can get a jdk with the fix for bug > http://javafx-jira.kenai.com/browse/RT-24142? > > Does anyone know of a workaround how you can still get a DOM Node from > WebEngine and hold on to it for longer than a minute or so? Right now when > I do a ((JSObject)node).call("getBoundingClientRect") (or any > JSObject.call/JSObject,toString) it randomly crashes after I've performed > a certain amount of work. > I dont seem to understand why this is happening, will it help if i keep > strong references to every JSObject/Node i ever touch, just looking for a > way i can continue (while waiting for the next jdk) without constantly > loosing unsaved work... > > Am I asking this question in the right place? > > Dennis > From zonski at gmail.com Tue Oct 23 19:55:44 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 24 Oct 2012 13:55:44 +1100 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> Message-ID: Given that the bootclasspath issue will (one day) be fixed so that JFX is actually co-bundled, I'd personally just go with manually 'fixing' your installed JDK by moving JFX inside the JDK extension package after the install: http://www.zenjava.com/firstcontact/architecture/setup/install-javafx/ Then when the classpath issue finally gets resolved, no changes will be needed to your Maven POM etc. If you use the assembly tools (or https://github.com/zonski/javafx-maven-plugin) then JFX gets bundled into the disputables so no need to do any hackery on that side of things (i.e. you only have to do the above cludge on your own dev machine where you do your compiling/building). On Wed, Oct 24, 2012 at 1:00 PM, Scott Palmer wrote: > JavaFX has been bundled since 7u7 anyway? but it is not on the classpath > by default. Presumably someone was scared of breaking stuff. The JavaFX > app packager does some magic to get it on the classpath for runtime. > > For Maven there are a couple of options. One is to use the dreaded > "system" scope: > > > javafx > jfxrt > system > ${java.home}/lib/jfxrt.jar > 2.2.4 > > > Use the "enforcer" plugin to require at lest 7u7. > > > > > org.apache.maven.plugins > maven-enforcer-plugin > > > enforce-java > > enforce > > > > > > > 1.7.0-7 > > > > > > > > > > > (see > http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html > ) > > And then do the same sort of classpath hackery that the app packager stubs > do for runtime. Or just use -Xbootclasspath/a: > > Scott > > On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: > > > I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX > 2.2.4 inside it. So I thought I would go ahead and remove my maven > dependency on the trusty old JavaFX 2.2.0-b19. > > > > However when I try to build my application with NetBeans it does not > find the JavaFX classes. If I open the Java platform manager in NetBeans it > also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) > platform. > > > > Am I supposed to still extract the jfxrt.jar and the dylibs and manually > create a maven dependency, or have I overlooked something here? > > > > Thanks > > > > Randahl > > From swpalmer at gmail.com Tue Oct 23 20:04:54 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 23 Oct 2012 23:04:54 -0400 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> Message-ID: <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today) but what I suggested would continue to work without modifications after the proper co-bundling would it not? The issue with including jfxrt.jar yourself is the fragile nature of the native code loading. You must ensure the native libraries are at exactly the right relative path to jfxrt.jar. If they aren't you might accidentally pick up the native libraries in the JRE folder and be fooled into thinking things are working. Then when the JRE is updated the native libraries don't match your bundled jfxrt.jar and it breaks. It happened to me :-) If you are't going to require 7u7 or later, it is probably best to use the javafxpackager tools somehow. Scott On 2012-10-23, at 10:55 PM, Daniel Zwolenski wrote: > Given that the bootclasspath issue will (one day) be fixed so that JFX is actually co-bundled, I'd personally just go with manually 'fixing' your installed JDK by moving JFX inside the JDK extension package after the install: > http://www.zenjava.com/firstcontact/architecture/setup/install-javafx/ > > Then when the classpath issue finally gets resolved, no changes will be needed to your Maven POM etc. > > If you use the assembly tools (or https://github.com/zonski/javafx-maven-plugin) then JFX gets bundled into the disputables so no need to do any hackery on that side of things (i.e. you only have to do the above cludge on your own dev machine where you do your compiling/building). > > > > > On Wed, Oct 24, 2012 at 1:00 PM, Scott Palmer wrote: > JavaFX has been bundled since 7u7 anyway? but it is not on the classpath by default. Presumably someone was scared of breaking stuff. The JavaFX app packager does some magic to get it on the classpath for runtime. > > For Maven there are a couple of options. One is to use the dreaded "system" scope: > > > javafx > jfxrt > system > ${java.home}/lib/jfxrt.jar > 2.2.4 > > > Use the "enforcer" plugin to require at lest 7u7. > > > > > org.apache.maven.plugins > maven-enforcer-plugin > > > enforce-java > > enforce > > > > > 1.7.0-7 > > > > > > > > > > (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html) > > And then do the same sort of classpath hackery that the app packager stubs do for runtime. Or just use -Xbootclasspath/a: > > Scott > > On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: > > > I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. > > > > However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. > > > > Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? > > > > Thanks > > > > Randahl > > From zonski at gmail.com Wed Oct 24 00:33:02 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 24 Oct 2012 18:33:02 +1100 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> Message-ID: <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> The problem with any discussion on this is there is no good answer. JavaFX has five ways of deploying (regular jar, executable jar, applet, jnlp, native installer) all of them broken or as good as (whether you use Maven, Ant or anything). The way I proposed is definitely not perfect but moves some pain from one spot to the next. Choose your fetish. > I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today) I'd hazard a guess you're trying to do something non-standard with it? Generally if you follow Maven's conventions it all just works. If you don't follow them it will slap you round every which way. If you can't follow the conventions (why not?) then I'd suggest Gradle or if you really have to then Ant + Ivy. JavaFX goes out of its way to make you break Maven conventions so generally you will suffer here - there have been a hundred emails on how JavaFX could easily play nice with Maven so I won't bother repeating them here. > but what I suggested would continue to work without modifications after the proper co-bundling would it not? You have introduced extra and unusual config to your POM. After co-bundling it should all be unnecessary and should be removed. In the alternative approach, the Pom is the same before and after. Choose your poison. > The issue with including jfxrt.jar yourself is the fragile nature of the native code loading. You must ensure the native libraries are at exactly the right relative path to jfxrt.jar. > If they aren't you might accidentally pick up the native libraries in the JRE folder and be fooled into thinking things are working. Then when the JRE is updated the native libraries don't match your bundled jfxrt.jar and it breaks. It happened to me :-) Yes. But this is a problem in every single scenario, maven or otherwise. You can either use the jre bundled fx or bundle your own in your distro. Both options are fraught with problems. This is all a flaw in the current half-hearted co-bundling. Jfx is tied to a jre version, is deployed within a jre install, but isn't available meaning you have to do something awful to make it work at all. Can't understand the logic behind this partial cobundle - better not to have done it at all until it could be done properly. But again that's been raised many times before. > If you are't going to require 7u7 or later, it is probably best to use the javafxpackager tools somehow. I'd suggest (having been burnt by this heavily and continually for the last 12 months) that you ONLY use the jfx packaging tools and ONLY use the native installer approach. Everything else is guaranteed to kick you in the face and laugh at your futile attempts to do something as simple as build and deploy. Native installers are pretty terrible to work with in their current form though (huge downloads, complicated setup of build, no auto updating) but in terms of things that will come back to kick you in the nuts in 3 months time this is the only one that might not. > > Scott > > On 2012-10-23, at 10:55 PM, Daniel Zwolenski wrote: > >> Given that the bootclasspath issue will (one day) be fixed so that JFX is actually co-bundled, I'd personally just go with manually 'fixing' your installed JDK by moving JFX inside the JDK extension package after the install: >> http://www.zenjava.com/firstcontact/architecture/setup/install-javafx/ >> >> Then when the classpath issue finally gets resolved, no changes will be needed to your Maven POM etc. >> >> If you use the assembly tools (or https://github.com/zonski/javafx-maven-plugin) then JFX gets bundled into the disputables so no need to do any hackery on that side of things (i.e. you only have to do the above cludge on your own dev machine where you do your compiling/building). >> >> >> >> >> On Wed, Oct 24, 2012 at 1:00 PM, Scott Palmer wrote: >> JavaFX has been bundled since 7u7 anyway? but it is not on the classpath by default. Presumably someone was scared of breaking stuff. The JavaFX app packager does some magic to get it on the classpath for runtime. >> >> For Maven there are a couple of options. One is to use the dreaded "system" scope: >> >> >> javafx >> jfxrt >> system >> ${java.home}/lib/jfxrt.jar >> 2.2.4 >> >> >> Use the "enforcer" plugin to require at lest 7u7. >> >> >> >> >> org.apache.maven.plugins >> maven-enforcer-plugin >> >> >> enforce-java >> >> enforce >> >> >> >> >> 1.7.0-7 >> >> >> >> >> >> >> >> >> >> (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html) >> >> And then do the same sort of classpath hackery that the app packager stubs do for runtime. Or just use -Xbootclasspath/a: >> >> Scott >> >> On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: >> >> > I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. >> > >> > However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. >> > >> > Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? >> > >> > Thanks >> > >> > Randahl >> >> > From neugens.limasoftware at gmail.com Wed Oct 24 00:59:12 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 24 Oct 2012 09:59:12 +0200 Subject: Ensemble in Mac App Store In-Reply-To: <5086C731.7090006@oracle.com> References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <5086C731.7090006@oracle.com> Message-ID: 2012/10/23 Phil Race : > If you are comfortable with the GPL then you can create your own build from > openjdk sources ... > But I thought GPL wasn't allowed in the App Store? Am I wrong, do they fix this? Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From lehmann at media-interactive.de Wed Oct 24 03:55:58 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 24 Oct 2012 12:55:58 +0200 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: <5086C202.5020304@media-interactive.de> References: <5086C202.5020304@media-interactive.de> Message-ID: <5087C93E.6070708@media-interactive.de> I can answer this part now: put an invalidation listener on the scene property of the node used for CustomMenuItem. Once that node gets a scene, it can be used to add a stylesheet. Not really straightforward though. I'd still prefer if the context menu could just use the stylesheet of its MenuButton. Werner On 23.10.2012 18:12, Werner Lehmann wrote: > This works ok but styling is difficult - how can I style the > menuitem/contextmenu used by the MenuButton skin? Apparently I cannot > access it from the MenuButton control. From dmdeklerk at gmail.com Wed Oct 24 04:01:48 2012 From: dmdeklerk at gmail.com (DM Klerk) Date: Wed, 24 Oct 2012 13:01:48 +0200 Subject: Bug RT-24142 crashes the VM when you touch a JSObject In-Reply-To: <508754AE.8030901@oracle.com> References: <508754AE.8030901@oracle.com> Message-ID: My application is an eclipse RCP app (swt, jface, jdt, jsdt and more), which uses Tom's efxclipse for osgi integration. According to eclipse's bug tracker jdk8 is not fully supported yet. Is it at this time even possible to use jdk8 for this or must i wait for either: a. eclipse supporting jdk8 or b. oracle releasing a jdk7 update with my bug fixed? And if b is the case, does anyone know when to expect such a release? Dennis 2012/10/24 Kevin Rushforth > Can anyone tell me where or when i can get a jdk with the fix for bug >> http://javafx-jira.kenai.com/**browse/RT-24142 >> ? >> > > > http://jdk8.java.net/download.**html > > -- Kevin > > > > > DM Klerk wrote: > >> Recently I filed bug http://javafx-jira.kenai.com/**browse/RT-24142, >> at first >> I couldn't pinpoint the reason but after I've created a test case the >> Oracle devs picked it up and soon set the bug to critical, now luckily the >> bug is set to resolved for Lombard. The bug causes the VM to crash every >> minute or so when working with DOM objects/JS objects that come from a >> WebEngine/WebView. It turned out there was a problem with the new webkit >> garbage collector which caused javafx code to try and reuse cached >> javascript objects that where GC'd. >> >> Since my application is constantly working with DOM objects (WebView was >> the reason to choose javafx) having it crash every minute is very >> frustrating. >> >> Can anyone tell me where or when i can get a jdk with the fix for bug >> http://javafx-jira.kenai.com/**browse/RT-24142 >> ? >> >> Does anyone know of a workaround how you can still get a DOM Node from >> WebEngine and hold on to it for longer than a minute or so? Right now when >> I do a ((JSObject)node).call("**getBoundingClientRect") (or any >> JSObject.call/JSObject,**toString) it randomly crashes after I've >> performed >> a certain amount of work. >> I dont seem to understand why this is happening, will it help if i keep >> strong references to every JSObject/Node i ever touch, just looking for a >> way i can continue (while waiting for the next jdk) without constantly >> loosing unsaved work... >> >> Am I asking this question in the right place? >> >> Dennis >> >> > From randahl at rockit.dk Wed Oct 24 04:07:56 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 24 Oct 2012 13:07:56 +0200 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: <5087C93E.6070708@media-interactive.de> References: <5086C202.5020304@media-interactive.de> <5087C93E.6070708@media-interactive.de> Message-ID: Have you looked at caspian.css? I would imagine there was a solution in there. R. On Oct 24, 2012, at 12:55 , Werner Lehmann wrote: > I can answer this part now: put an invalidation listener on the scene property of the node used for CustomMenuItem. Once that node gets a scene, it can be used to add a stylesheet. Not really straightforward though. I'd still prefer if the context menu could just use the stylesheet of its MenuButton. > > Werner > > On 23.10.2012 18:12, Werner Lehmann wrote: >> This works ok but styling is difficult - how can I style the >> menuitem/contextmenu used by the MenuButton skin? Apparently I cannot >> access it from the MenuButton control. From lehmann at media-interactive.de Wed Oct 24 04:23:05 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 24 Oct 2012 13:23:05 +0200 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: References: <5086C202.5020304@media-interactive.de> <5087C93E.6070708@media-interactive.de> Message-ID: <5087CF99.5080200@media-interactive.de> I looked at it a while ago - but what are you suggesting? How would this help with styling a menubutton contextmenu (for a particular usecase), or even with a general style for all application contextmenus? Werner On 24.10.2012 13:07, Randahl Fink Isaksen wrote: > Have you looked at caspian.css? I would imagine there was a solution in there. From tbee at tbee.org Wed Oct 24 04:37:20 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 24 Oct 2012 13:37:20 +0200 Subject: IllegalStateException on an observable list In-Reply-To: <5084574B.6000108@tbee.org> References: <50844EEF.3070708@tbee.org> <5084574B.6000108@tbee.org> Message-ID: <5087D2F0.50801@tbee.org> This indeed was the problem. Point is; I simply used code completion on the Change class, found the getRemoved method, and used that. I figure this will be happening to a lot of people. Maybe it is user friendly to provide a small hint in the IllegalStateException's text, something like "Have you maybe forgotten to iterate over the change sets?". On 2012-10-21 22:12, Tom Eugelink wrote: > How blond can one be, overlooked that. Thanks. > > Tom > > > On 2012-10-21 22:07, Martin Kl?hn wrote: >> Hi, >> >> it seems you've missed to iterate through the collected changes in that Change. if you wrap your for-loop in while(c.next()) it'll work. you can then optionally check if the change was caused by appointments being removed from the list or by something else. See http://docs.oracle.com/javafx/2/api/javafx/collections/ListChangeListener.Change.html for reference. >> >> Martin From swpalmer at gmail.com Wed Oct 24 04:42:17 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 24 Oct 2012 07:42:17 -0400 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> Message-ID: <1C1E83E3-807D-46F1-9E20-9B4DB8BF4BDE@gmail.com> On 2012-10-24, at 3:33 AM, Daniel Zwolenski wrote: > The problem with any discussion on this is there is no good answer. JavaFX has five ways of deploying (regular jar, executable jar, applet, jnlp, native installer) all of them broken or as good as (whether you use Maven, Ant or anything). > > The way I proposed is definitely not perfect but moves some pain from one spot to the next. Choose your fetish. > >> I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today) > > I'd hazard a guess you're trying to do something non-standard with it? Nearly everything is non-standard from Maven's point of view. (E.g. anything with JNI.) But this last fail was because I had a filename that contained an apostrophe and the maven assembly plugin built an invalid command line for the shell. Worked on Windows, failed on Linux, despite the filename being legal on both platforms. >> but what I suggested would continue to work without modifications after the proper co-bundling would it not? > > You have introduced extra and unusual config to your POM. Everything is unusual from Maven's point of view :-). The mythical "standard" that Maven requires I've only encountered in contrived demos and example code. Not real-world applications of any significant size and complexity. (And yes we are using Gradle to fill in the gaps. But IDE support isn't at a comparable level for Gradle yet.) > After co-bundling it should all be unnecessary and should be removed. In the alternative approach, the Pom is the same before and after. Choose your poison. But that's what I'm saying. If you don't change the POM it continues to work after cobundling. The POM is the same before and after. While it could be cleaned up be removing the "unusual" stuff that isn't a requirement to get it to build. Anyway .. This Maven stuff is getting off-topic. > This is all a flaw in the current half-hearted co-bundling. Jfx is tied to a jre version, is deployed within a jre install, but isn't available meaning you have to do something awful to make it work at all. Can't understand the logic behind this partial cobundle - better not to have done it at all until it could be done properly. But again that's been raised many times before. This is what scares me about what is taking so long to simply put a single jar file on the classpath. I fear Oracle is going to do something "fancy" and it is going to be another pain in the butt. I'm hoping it is just a matter of "we aren't allowed to do that without bumping the major version number". But even so a new VM option -XX+UseJavaFX would work. Scott From martin.sladecek at oracle.com Wed Oct 24 04:53:08 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Wed, 24 Oct 2012 13:53:08 +0200 Subject: IllegalStateException on an observable list In-Reply-To: <5087D2F0.50801@tbee.org> References: <50844EEF.3070708@tbee.org> <5084574B.6000108@tbee.org> <5087D2F0.50801@tbee.org> Message-ID: <5087D6A4.4080304@oracle.com> Hi Tom, I already filed a JIRA issue for this. Thanks, -Martin On 10/24/2012 01:37 PM, Tom Eugelink wrote: > This indeed was the problem. Point is; I simply used code completion > on the Change class, found the getRemoved method, and used that. I > figure this will be happening to a lot of people. Maybe it is user > friendly to provide a small hint in the IllegalStateException's text, > something like "Have you maybe forgotten to iterate over the change > sets?". > > > On 2012-10-21 22:12, Tom Eugelink wrote: >> How blond can one be, overlooked that. Thanks. >> >> Tom >> >> >> On 2012-10-21 22:07, Martin Kl?hn wrote: >>> Hi, >>> >>> it seems you've missed to iterate through the collected changes in >>> that Change. if you wrap your for-loop in while(c.next()) it'll >>> work. you can then optionally check if the change was caused by >>> appointments being removed from the list or by something else. See >>> http://docs.oracle.com/javafx/2/api/javafx/collections/ListChangeListener.Change.html >>> for reference. >>> >>> Martin > From martin.sladecek at oracle.com Wed Oct 24 04:53:13 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Wed, 24 Oct 2012 13:53:13 +0200 Subject: IllegalStateException on an observable list In-Reply-To: <5087D2F0.50801@tbee.org> References: <50844EEF.3070708@tbee.org> <5084574B.6000108@tbee.org> <5087D2F0.50801@tbee.org> Message-ID: <5087D6A9.8050002@oracle.com> Hi Tom, I already filed a JIRA issue for this. http://javafx-jira.kenai.com/browse/RT-25748 Thanks, -Martin On 10/24/2012 01:37 PM, Tom Eugelink wrote: > This indeed was the problem. Point is; I simply used code completion > on the Change class, found the getRemoved method, and used that. I > figure this will be happening to a lot of people. Maybe it is user > friendly to provide a small hint in the IllegalStateException's text, > something like "Have you maybe forgotten to iterate over the change > sets?". > > > On 2012-10-21 22:12, Tom Eugelink wrote: >> How blond can one be, overlooked that. Thanks. >> >> Tom >> >> >> On 2012-10-21 22:07, Martin Kl?hn wrote: >>> Hi, >>> >>> it seems you've missed to iterate through the collected changes in >>> that Change. if you wrap your for-loop in while(c.next()) it'll >>> work. you can then optionally check if the change was caused by >>> appointments being removed from the list or by something else. See >>> http://docs.oracle.com/javafx/2/api/javafx/collections/ListChangeListener.Change.html >>> for reference. >>> >>> Martin > From tom.schindl at bestsolution.at Wed Oct 24 05:03:26 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 24 Oct 2012 14:03:26 +0200 Subject: Bug RT-24142 crashes the VM when you touch a JSObject In-Reply-To: References: <508754AE.8030901@oracle.com> Message-ID: <5087D90E.3070509@bestsolution.at> There should not be a problem to use JDK8 with Eclipse (and e(fx)clipse) just change your JDK inside eclipse. What is not supported by Eclipse JDT is using Java8 syntax features like lambdas but if you stay with Java7 features in your code you should be able to launch applications ontop of JDK8. Tom Am 24.10.12 13:01, schrieb DM Klerk: > My application is an eclipse RCP app (swt, jface, jdt, jsdt and more), > which uses Tom's efxclipse for osgi integration. > According to eclipse's bug tracker jdk8 is not fully supported yet. > Is it at this time even possible to use jdk8 for this or must i wait for > either: a. eclipse supporting jdk8 or b. oracle releasing a jdk7 update > with my bug fixed? And if b is the case, does anyone know when to expect > such a release? > > Dennis > > > > 2012/10/24 Kevin Rushforth > >> Can anyone tell me where or when i can get a jdk with the fix for bug >>> http://javafx-jira.kenai.com/**browse/RT-24142 >>> ? >>> >> >> >> http://jdk8.java.net/download.**html >> >> -- Kevin >> >> >> >> >> DM Klerk wrote: >> >>> Recently I filed bug http://javafx-jira.kenai.com/**browse/RT-24142, >>> at first >>> I couldn't pinpoint the reason but after I've created a test case the >>> Oracle devs picked it up and soon set the bug to critical, now luckily the >>> bug is set to resolved for Lombard. The bug causes the VM to crash every >>> minute or so when working with DOM objects/JS objects that come from a >>> WebEngine/WebView. It turned out there was a problem with the new webkit >>> garbage collector which caused javafx code to try and reuse cached >>> javascript objects that where GC'd. >>> >>> Since my application is constantly working with DOM objects (WebView was >>> the reason to choose javafx) having it crash every minute is very >>> frustrating. >>> >>> Can anyone tell me where or when i can get a jdk with the fix for bug >>> http://javafx-jira.kenai.com/**browse/RT-24142 >>> ? >>> >>> Does anyone know of a workaround how you can still get a DOM Node from >>> WebEngine and hold on to it for longer than a minute or so? Right now when >>> I do a ((JSObject)node).call("**getBoundingClientRect") (or any >>> JSObject.call/JSObject,**toString) it randomly crashes after I've >>> performed >>> a certain amount of work. >>> I dont seem to understand why this is happening, will it help if i keep >>> strong references to every JSObject/Node i ever touch, just looking for a >>> way i can continue (while waiting for the next jdk) without constantly >>> loosing unsaved work... >>> >>> Am I asking this question in the right place? >>> >>> Dennis >>> >>> >> -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Wed Oct 24 05:13:33 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 24 Oct 2012 14:13:33 +0200 Subject: IllegalStateException on an observable list In-Reply-To: <5087D6A9.8050002@oracle.com> References: <50844EEF.3070708@tbee.org> <5084574B.6000108@tbee.org> <5087D2F0.50801@tbee.org> <5087D6A9.8050002@oracle.com> Message-ID: <5087DB6D.7020409@tbee.org> Voted On 2012-10-24 13:53, Martin Sladecek wrote: > Hi Tom, > I already filed a JIRA issue for this. http://javafx-jira.kenai.com/browse/RT-25748 > > Thanks, > -Martin > > On 10/24/2012 01:37 PM, Tom Eugelink wrote: >> This indeed was the problem. Point is; I simply used code completion on the Change class, found the getRemoved method, and used that. I figure this will be happening to a lot of people. Maybe it is user friendly to provide a small hint in the IllegalStateException's text, something like "Have you maybe forgotten to iterate over the change sets?". >> >> >> On 2012-10-21 22:12, Tom Eugelink wrote: >>> How blond can one be, overlooked that. Thanks. >>> >>> Tom >>> >>> >>> On 2012-10-21 22:07, Martin Kl?hn wrote: >>>> Hi, >>>> >>>> it seems you've missed to iterate through the collected changes in that Change. if you wrap your for-loop in while(c.next()) it'll work. you can then optionally check if the change was caused by appointments being removed from the list or by something else. See http://docs.oracle.com/javafx/2/api/javafx/collections/ListChangeListener.Change.html for reference. >>>> >>>> Martin >> > From randahl at rockit.dk Wed Oct 24 05:13:55 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 24 Oct 2012 14:13:55 +0200 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: <5087CF99.5080200@media-interactive.de> References: <5086C202.5020304@media-interactive.de> <5087C93E.6070708@media-interactive.de> <5087CF99.5080200@media-interactive.de> Message-ID: I have had success with using nested selectors such as .myusecase .button {} where .myusecase is a style class added to a parent component by my app and .button is the style class that Button adds itself. This affects only buttons in that particular use-case. Couldn't you do something similar, of course with whatever style class the popup has? R. On Oct 24, 2012, at 13:23 , Werner Lehmann wrote: > I looked at it a while ago - but what are you suggesting? How would this help with styling a menubutton contextmenu (for a particular usecase), or even with a general style for all application contextmenus? > > Werner > > On 24.10.2012 13:07, Randahl Fink Isaksen wrote: >> Have you looked at caspian.css? I would imagine there was a solution in there. > From zonski at gmail.com Wed Oct 24 05:17:02 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 24 Oct 2012 23:17:02 +1100 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <1C1E83E3-807D-46F1-9E20-9B4DB8BF4BDE@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> <1C1E83E3-807D-46F1-9E20-9B4DB8BF4BDE@gmail.com> Message-ID: <33A78FD7-54B4-4A13-A5AE-EE1F66E5B6FF@gmail.com> Maven is biased to enterprise/JEE/webapps. Client side java has not been overly mainstream for a good while so mainstream tools are not geared for it. So yes, "nearly everything is non-standard" IF you are building a Java client app, and yes I feel (and share) your pain. Building a fully blown 'standard' webapp however works like a charm with minimal config and makes ANT look like a 'make' script. That same ease could be extended to client side builds though and the previous (recurring) conversations on this thread have been about tweaking jfx to make life easier in this space. Unfortunately it's not been a space the jfx team have seen as important. > This is what scares me about what is taking so long to simply put a single jar file on the classpath. I fear Oracle is going to do something "fancy" and it is going to be another pain in the butt. I'm hoping it is just a matter of "we aren't allowed to do that without bumping the major version number". But even so a new VM option -XX+UseJavaFX would work. I believe this is semi outside the jfx team's control. It needed official jre approval, hence the delay. I don't think anything "fancy" is planned. Once the red tape is cuti t'll just one day be on the jre path, much like swing or java.util. Personally I can accept a delay as necessary, but the decision to "half" include it in the jre was a very poor one in my opinion. Better to hold off completely and instead provide better ways to include it in our app bundles (eg make the DLL loading less fragile - 10 lines of code change could make a whole lot of pain go away). The half co-bundle just added to the pain. Java 8 promises to reduce some of this pain but project jigsaw already got canned so there's no solid pledge on what will actually be delivered. I personally believe native installers are the only potentially usable deployment option at the moment but they need a heck of a lot of improvement and there doesn't seem to be any noticeable activity in this area. The deployment team looks to be focused on security fixes (which funnily enough probably wouldn't be such a problem if applet and jnlp were ditched). From dmdeklerk at gmail.com Wed Oct 24 05:33:05 2012 From: dmdeklerk at gmail.com (DM Klerk) Date: Wed, 24 Oct 2012 14:33:05 +0200 Subject: Bug RT-24142 crashes the VM when you touch a JSObject In-Reply-To: References: <508754AE.8030901@oracle.com> Message-ID: Dont you wish everything in life could be that simple! The crashes I described earlier disappeared when I moved from jdk7 to jdk8, as Tom says all you need to do is point eclipse to use jre8 as runtime for your application and everything works like a charm, thank you Kevin and Jonh for your swift replies. Dennis 2012/10/24 DM Klerk > My application is an eclipse RCP app (swt, jface, jdt, jsdt and more), > which uses Tom's efxclipse for osgi integration. > According to eclipse's bug tracker jdk8 is not fully supported yet. > Is it at this time even possible to use jdk8 for this or must i wait for > either: a. eclipse supporting jdk8 or b. oracle releasing a jdk7 update > with my bug fixed? And if b is the case, does anyone know when to expect > such a release? > > Dennis > > > > 2012/10/24 Kevin Rushforth > >> Can anyone tell me where or when i can get a jdk with the fix for bug >>> http://javafx-jira.kenai.com/**browse/RT-24142 >>> ? >>> >> >> >> http://jdk8.java.net/download.**html >> >> -- Kevin >> >> >> >> >> DM Klerk wrote: >> >>> Recently I filed bug http://javafx-jira.kenai.com/**browse/RT-24142, >>> at first >>> I couldn't pinpoint the reason but after I've created a test case the >>> Oracle devs picked it up and soon set the bug to critical, now luckily >>> the >>> bug is set to resolved for Lombard. The bug causes the VM to crash every >>> minute or so when working with DOM objects/JS objects that come from a >>> WebEngine/WebView. It turned out there was a problem with the new webkit >>> garbage collector which caused javafx code to try and reuse cached >>> javascript objects that where GC'd. >>> >>> Since my application is constantly working with DOM objects (WebView was >>> the reason to choose javafx) having it crash every minute is very >>> frustrating. >>> >>> Can anyone tell me where or when i can get a jdk with the fix for bug >>> http://javafx-jira.kenai.com/**browse/RT-24142 >>> ? >>> >>> Does anyone know of a workaround how you can still get a DOM Node from >>> WebEngine and hold on to it for longer than a minute or so? Right now >>> when >>> I do a ((JSObject)node).call("**getBoundingClientRect") (or any >>> JSObject.call/JSObject,**toString) it randomly crashes after I've >>> performed >>> a certain amount of work. >>> I dont seem to understand why this is happening, will it help if i keep >>> strong references to every JSObject/Node i ever touch, just looking for a >>> way i can continue (while waiting for the next jdk) without constantly >>> loosing unsaved work... >>> >>> Am I asking this question in the right place? >>> >>> Dennis >>> >>> >> > From lehmann at media-interactive.de Wed Oct 24 05:58:28 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 24 Oct 2012 14:58:28 +0200 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: References: <5086C202.5020304@media-interactive.de> <5087C93E.6070708@media-interactive.de> <5087CF99.5080200@media-interactive.de> Message-ID: <5087E5F4.3050705@media-interactive.de> Randahl, the problem is not about using selectors (this works) - it is about ContextMenu being a PopupControl having a separate scene having a different stylesheet. If you want to style a ContextMenu you have to add your stylesheet to ContextMenu.scene.root.styleSheets. This is difficult if the particular instance of a context menu is a private field of a MenuButton skin. Currently I get around this just by using a CustomMenuItem which uses a provided node which in turn has an invalidation listener on the scene property. Not pretty... ;-) And this won't work for MenuButton if the menu has no custom items. Which is still an open problem... Werner On 24.10.2012 14:13, Randahl Fink Isaksen wrote: > I have had success with using nested selectors such as > > .myusecase .button {} > > where .myusecase is a style class added to a parent component by my > app and .button is the style class that Button adds itself. This > affects only buttons in that particular use-case. Couldn't you do > something similar, of course with whatever style class the popup > has? > > R. From tbee at tbee.org Wed Oct 24 06:07:36 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 24 Oct 2012 15:07:36 +0200 Subject: javafx 8 Message-ID: <5087E818.8020804@tbee.org> Stephen asked me to take a peek at a demo app for JFall next week. It seems from the compilation errors that it requires JavaFX 8. Is there a early access binary release is JFX8 available anywhere? Because since JFX is not fully open sourced, I do not think I'll be able to compile it myself. Or am I? Tom From knut.arne.vedaa at broadpark.no Wed Oct 24 06:19:35 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Wed, 24 Oct 2012 15:19:35 +0200 Subject: javafx 8 In-Reply-To: <5087E818.8020804@tbee.org> References: <5087E818.8020804@tbee.org> Message-ID: <5087EAE7.4000304@broadpark.no> Haven't tried it myself, but it seems to be available from here, as part of JDK8: http://jdk8.java.net/download.html Knut Arne Vedaa On 24.10.2012 15:07, Tom Eugelink wrote: > Stephen asked me to take a peek at a demo app for JFall next week. It > seems from the compilation errors that it requires JavaFX 8. Is there a > early access binary release is JFX8 available anywhere? Because since > JFX is not fully open sourced, I do not think I'll be able to compile it > myself. Or am I? > > Tom > > From joe.mcglynn at oracle.com Wed Oct 24 06:34:22 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Wed, 24 Oct 2012 06:34:22 -0700 Subject: javafx 8 In-Reply-To: <5087EAE7.4000304@broadpark.no> References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> Message-ID: <0E9FFE31-1AFA-460F-9C6D-D9B36CBA520A@oracle.com> That's correct, the latest build of JDK 8 will have the latest FX 8. They are not separable. Joe -- On Oct 24, 2012, at 6:19 AM, Knut Arne Vedaa wrote: > Haven't tried it myself, but it seems to be available from here, as part of JDK8: > > http://jdk8.java.net/download.html > > > Knut Arne Vedaa > > On 24.10.2012 15:07, Tom Eugelink wrote: >> Stephen asked me to take a peek at a demo app for JFall next week. It >> seems from the compilation errors that it requires JavaFX 8. Is there a >> early access binary release is JFX8 available anywhere? Because since >> JFX is not fully open sourced, I do not think I'll be able to compile it >> myself. Or am I? >> >> Tom >> >> > From tbee at tbee.org Wed Oct 24 06:40:52 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 24 Oct 2012 15:40:52 +0200 Subject: javafx 8 In-Reply-To: <5087EAE7.4000304@broadpark.no> References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> Message-ID: <5087EFE4.5060101@tbee.org> The JavaFX link only contains demo's. But the JDK8 EA indeed contains a JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version that the demo app is compiled against (a method is missing). But down to one error. Thanks! On 2012-10-24 15:19, Knut Arne Vedaa wrote: > Haven't tried it myself, but it seems to be available from here, as part of JDK8: > > http://jdk8.java.net/download.html > > > Knut Arne Vedaa > > On 24.10.2012 15:07, Tom Eugelink wrote: >> Stephen asked me to take a peek at a demo app for JFall next week. It >> seems from the compilation errors that it requires JavaFX 8. Is there a >> early access binary release is JFX8 available anywhere? Because since >> JFX is not fully open sourced, I do not think I'll be able to compile it >> myself. Or am I? >> >> Tom >> >> > From joe.mcglynn at oracle.com Wed Oct 24 06:44:20 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Wed, 24 Oct 2012 06:44:20 -0700 Subject: javafx 8 In-Reply-To: <5087EFE4.5060101@tbee.org> References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> <5087EFE4.5060101@tbee.org> Message-ID: Indeed, the latest EA release is at least a week behind internal development work. So that is entirely possible. -- On Oct 24, 2012, at 6:40 AM, Tom Eugelink wrote: > The JavaFX link only contains demo's. But the JDK8 EA indeed contains a JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version that the demo app is compiled against (a method is missing). But down to one error. > > Thanks! > > > > > On 2012-10-24 15:19, Knut Arne Vedaa wrote: >> Haven't tried it myself, but it seems to be available from here, as part of JDK8: >> >> http://jdk8.java.net/download.html >> >> >> Knut Arne Vedaa >> >> On 24.10.2012 15:07, Tom Eugelink wrote: >>> Stephen asked me to take a peek at a demo app for JFall next week. It >>> seems from the compilation errors that it requires JavaFX 8. Is there a >>> early access binary release is JFX8 available anywhere? Because since >>> JFX is not fully open sourced, I do not think I'll be able to compile it >>> myself. Or am I? >>> >>> Tom >>> >>> >> > From randahl at rockit.dk Wed Oct 24 06:44:24 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 24 Oct 2012 15:44:24 +0200 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> Message-ID: <22118C95-B840-4F35-BBE0-776254CFC3B5@rockit.dk> I can confirm that simply dragging jfxrt.jar to the ext package works like a charm. I am fully aware that this would not be sufficient for a production release distributed to end users, but since we are not about to release this seems to be the fastest way forward. Sure hope there is a focus on fixing this ? for newcomers, I would want JavaFX to be plug and play, and currently it does not seem to be. Randahl On Oct 24, 2012, at 9:33 , Daniel Zwolenski wrote: > The problem with any discussion on this is there is no good answer. JavaFX has five ways of deploying (regular jar, executable jar, applet, jnlp, native installer) all of them broken or as good as (whether you use Maven, Ant or anything). > > The way I proposed is definitely not perfect but moves some pain from one spot to the next. Choose your fetish. > >> I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today) > > I'd hazard a guess you're trying to do something non-standard with it? > > Generally if you follow Maven's conventions it all just works. If you don't follow them it will slap you round every which way. If you can't follow the conventions (why not?) then I'd suggest Gradle or if you really have to then Ant + Ivy. > > JavaFX goes out of its way to make you break Maven conventions so generally you will suffer here - there have been a hundred emails on how JavaFX could easily play nice with Maven so I won't bother repeating them here. > >> but what I suggested would continue to work without modifications after the proper co-bundling would it not? > > You have introduced extra and unusual config to your POM. After co-bundling it should all be unnecessary and should be removed. In the alternative approach, the Pom is the same before and after. Choose your poison. > >> The issue with including jfxrt.jar yourself is the fragile nature of the native code loading. You must ensure the native libraries are at exactly the right relative path to jfxrt.jar. >> If they aren't you might accidentally pick up the native libraries in the JRE folder and be fooled into thinking things are working. Then when the JRE is updated the native libraries don't match your bundled jfxrt.jar and it breaks. It happened to me :-) > > Yes. But this is a problem in every single scenario, maven or otherwise. You can either use the jre bundled fx or bundle your own in your distro. Both options are fraught with problems. > > This is all a flaw in the current half-hearted co-bundling. Jfx is tied to a jre version, is deployed within a jre install, but isn't available meaning you have to do something awful to make it work at all. Can't understand the logic behind this partial cobundle - better not to have done it at all until it could be done properly. But again that's been raised many times before. > >> If you are't going to require 7u7 or later, it is probably best to use the javafxpackager tools somehow. > > I'd suggest (having been burnt by this heavily and continually for the last 12 months) that you ONLY use the jfx packaging tools and ONLY use the native installer approach. Everything else is guaranteed to kick you in the face and laugh at your futile attempts to do something as simple as build and deploy. > > Native installers are pretty terrible to work with in their current form though (huge downloads, complicated setup of build, no auto updating) but in terms of things that will come back to kick you in the nuts in 3 months time this is the only one that might not. > > >> >> Scott >> >> On 2012-10-23, at 10:55 PM, Daniel Zwolenski wrote: >> >>> Given that the bootclasspath issue will (one day) be fixed so that JFX is actually co-bundled, I'd personally just go with manually 'fixing' your installed JDK by moving JFX inside the JDK extension package after the install: >>> http://www.zenjava.com/firstcontact/architecture/setup/install-javafx/ >>> >>> Then when the classpath issue finally gets resolved, no changes will be needed to your Maven POM etc. >>> >>> If you use the assembly tools (or https://github.com/zonski/javafx-maven-plugin) then JFX gets bundled into the disputables so no need to do any hackery on that side of things (i.e. you only have to do the above cludge on your own dev machine where you do your compiling/building). >>> >>> >>> >>> >>> On Wed, Oct 24, 2012 at 1:00 PM, Scott Palmer wrote: >>> JavaFX has been bundled since 7u7 anyway? but it is not on the classpath by default. Presumably someone was scared of breaking stuff. The JavaFX app packager does some magic to get it on the classpath for runtime. >>> >>> For Maven there are a couple of options. One is to use the dreaded "system" scope: >>> >>> >>> javafx >>> jfxrt >>> system >>> ${java.home}/lib/jfxrt.jar >>> 2.2.4 >>> >>> >>> Use the "enforcer" plugin to require at lest 7u7. >>> >>> >>> >>> >>> org.apache.maven.plugins >>> maven-enforcer-plugin >>> >>> >>> enforce-java >>> >>> enforce >>> >>> >>> >>> >>> 1.7.0-7 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html) >>> >>> And then do the same sort of classpath hackery that the app packager stubs do for runtime. Or just use -Xbootclasspath/a: >>> >>> Scott >>> >>> On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: >>> >>> > I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. >>> > >>> > However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. >>> > >>> > Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? >>> > >>> > Thanks >>> > >>> > Randahl >>> >>> >> From kevin.rushforth at oracle.com Wed Oct 24 06:56:09 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Oct 2012 06:56:09 -0700 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <22118C95-B840-4F35-BBE0-776254CFC3B5@rockit.dk> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> <22118C95-B840-4F35-BBE0-776254CFC3B5@rockit.dk> Message-ID: <5087F379.8090704@oracle.com> > I can confirm that simply dragging jfxrt.jar to the ext package works like a charm. Current thinking is that putting jfxrt.jar in lib/ext is what we will do to include JavaFX on the default classpath in FX 8 (and possibly 7u12 if no issues arise with this transition). -- Kevin Randahl Fink Isaksen wrote: > I can confirm that simply dragging jfxrt.jar to the ext package works like a charm. > I am fully aware that this would not be sufficient for a production release distributed to end users, but since we are not about to release this seems to be the fastest way forward. > > Sure hope there is a focus on fixing this ? for newcomers, I would want JavaFX to be plug and play, and currently it does not seem to be. > > Randahl > > > > On Oct 24, 2012, at 9:33 , Daniel Zwolenski wrote: > > >> The problem with any discussion on this is there is no good answer. JavaFX has five ways of deploying (regular jar, executable jar, applet, jnlp, native installer) all of them broken or as good as (whether you use Maven, Ant or anything). >> >> The way I proposed is definitely not perfect but moves some pain from one spot to the next. Choose your fetish. >> >> >>> I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today) >>> >> I'd hazard a guess you're trying to do something non-standard with it? >> >> Generally if you follow Maven's conventions it all just works. If you don't follow them it will slap you round every which way. If you can't follow the conventions (why not?) then I'd suggest Gradle or if you really have to then Ant + Ivy. >> >> JavaFX goes out of its way to make you break Maven conventions so generally you will suffer here - there have been a hundred emails on how JavaFX could easily play nice with Maven so I won't bother repeating them here. >> >> >>> but what I suggested would continue to work without modifications after the proper co-bundling would it not? >>> >> You have introduced extra and unusual config to your POM. After co-bundling it should all be unnecessary and should be removed. In the alternative approach, the Pom is the same before and after. Choose your poison. >> >> >>> The issue with including jfxrt.jar yourself is the fragile nature of the native code loading. You must ensure the native libraries are at exactly the right relative path to jfxrt.jar. >>> If they aren't you might accidentally pick up the native libraries in the JRE folder and be fooled into thinking things are working. Then when the JRE is updated the native libraries don't match your bundled jfxrt.jar and it breaks. It happened to me :-) >>> >> Yes. But this is a problem in every single scenario, maven or otherwise. You can either use the jre bundled fx or bundle your own in your distro. Both options are fraught with problems. >> >> This is all a flaw in the current half-hearted co-bundling. Jfx is tied to a jre version, is deployed within a jre install, but isn't available meaning you have to do something awful to make it work at all. Can't understand the logic behind this partial cobundle - better not to have done it at all until it could be done properly. But again that's been raised many times before. >> >> >>> If you are't going to require 7u7 or later, it is probably best to use the javafxpackager tools somehow. >>> >> I'd suggest (having been burnt by this heavily and continually for the last 12 months) that you ONLY use the jfx packaging tools and ONLY use the native installer approach. Everything else is guaranteed to kick you in the face and laugh at your futile attempts to do something as simple as build and deploy. >> >> Native installers are pretty terrible to work with in their current form though (huge downloads, complicated setup of build, no auto updating) but in terms of things that will come back to kick you in the nuts in 3 months time this is the only one that might not. >> >> >> >>> Scott >>> >>> On 2012-10-23, at 10:55 PM, Daniel Zwolenski wrote: >>> >>> >>>> Given that the bootclasspath issue will (one day) be fixed so that JFX is actually co-bundled, I'd personally just go with manually 'fixing' your installed JDK by moving JFX inside the JDK extension package after the install: >>>> http://www.zenjava.com/firstcontact/architecture/setup/install-javafx/ >>>> >>>> Then when the classpath issue finally gets resolved, no changes will be needed to your Maven POM etc. >>>> >>>> If you use the assembly tools (or https://github.com/zonski/javafx-maven-plugin) then JFX gets bundled into the disputables so no need to do any hackery on that side of things (i.e. you only have to do the above cludge on your own dev machine where you do your compiling/building). >>>> >>>> >>>> >>>> >>>> On Wed, Oct 24, 2012 at 1:00 PM, Scott Palmer wrote: >>>> JavaFX has been bundled since 7u7 anyway? but it is not on the classpath by default. Presumably someone was scared of breaking stuff. The JavaFX app packager does some magic to get it on the classpath for runtime. >>>> >>>> For Maven there are a couple of options. One is to use the dreaded "system" scope: >>>> >>>> >>>> javafx >>>> jfxrt >>>> system >>>> ${java.home}/lib/jfxrt.jar >>>> 2.2.4 >>>> >>>> >>>> Use the "enforcer" plugin to require at lest 7u7. >>>> >>>> >>>> >>>> >>>> org.apache.maven.plugins >>>> maven-enforcer-plugin >>>> >>>> >>>> enforce-java >>>> >>>> enforce >>>> >>>> >>>> >>>> >>>> 1.7.0-7 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html) >>>> >>>> And then do the same sort of classpath hackery that the app packager stubs do for runtime. Or just use -Xbootclasspath/a: >>>> >>>> Scott >>>> >>>> On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen wrote: >>>> >>>> >>>>> I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19. >>>>> >>>>> However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform. >>>>> >>>>> Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here? >>>>> >>>>> Thanks >>>>> >>>>> Randahl >>>>> >>>> > > From swpalmer at gmail.com Wed Oct 24 07:52:25 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 24 Oct 2012 10:52:25 -0400 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <5087F379.8090704@oracle.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> <22118C95-B840-4F35-BBE0-776254CFC3B5@rockit.dk> <5087F379.8090704@oracle.com> Message-ID: <4E4CDCE2-5EEC-419C-A6E6-B60257FBAE9F@gmail.com> On 2012-10-24, at 9:56 AM, Kevin Rushforth wrote: > > I can confirm that simply dragging jfxrt.jar to the ext package works like a charm. > > Current thinking is that putting jfxrt.jar in lib/ext is what we will do to include JavaFX on the default classpath in FX 8 (and possibly 7u12 if no issues arise with this transition). > > -- Kevin Ah.. then that will break my Maven "hack". Since the path to jfxrt.jar will change and Maven will barf when it can't find the system dependency. I'm glad that I haven't rolled out that hack yet. Scott From steve.x.northover at oracle.com Wed Oct 24 07:56:31 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 24 Oct 2012 10:56:31 -0400 Subject: Fwd: TableView - listening to events on table headers In-Reply-To: References: Message-ID: <5088019F.1080308@oracle.com> Hi Pedro, You can always use a filter to see every click that happens in a control: tableView.addEventFilter(MouseEvent.MOUSE_PRESSED, new EventHandler() { public void handle(Event event) { System.out.println("Press " + event.getSource() + " " + event.getTarget()); } }); However, you then need to determine that the target was a table header node and that seems like reaching into the implementation. I would suggest that you stick with setGraphic() if this is working for you and enter a JIRA feature request for mouse and other event handlers for table column headers. Steve On 23/10/2012 8:03 PM, Pedro Duque Vieira wrote: > Somehow my email below didn't get any response so I'm sending it again.. > ---------- Forwarded message ---------- > From: Pedro Duque Vieira > Date: Tue, Oct 23, 2012 at 12:42 AM > Subject: TableView - listening to events on table headers > To: OpenJFX Mailing List > > > Hi, > > In my app I have to listen to mouse events on table headers, I've tried to > come up with a good solution to this but haven't found any. Posting in the > JavaFX OTN forums also did not bring any better solution. > As it is the only solution I see is replacing the headers via setGraphic > method of TableColumn and attaching listeners to what I pass in to the > setGraphic, even though I will end up replacing the TableColumn header with > the same type of node as was previously present, so I end up calling > setGraphic only for the sake of being able to attach listeners. This looks > ugly. > > Is there any better solution for this? > > My use case is: > 1- user mouse clicks the a table header to select a column > 2- column gets selected. > 3- Selected column is visually highlighted. > > Thanks, > > From pedro.duquevieira at gmail.com Wed Oct 24 08:22:22 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 24 Oct 2012 16:22:22 +0100 Subject: Fwd: TableView - listening to events on table headers In-Reply-To: <5088019F.1080308@oracle.com> References: <5088019F.1080308@oracle.com> Message-ID: Hi Steve, I will enter that Jira issue than... Thanks, best regards, On Wed, Oct 24, 2012 at 3:56 PM, wrote: > Hi Pedro, > > You can always use a filter to see every click that happens in a control: > > tableView.addEventFilter(**MouseEvent.MOUSE_PRESSED, new > EventHandler() { > public void handle(Event event) { > System.out.println("Press " + event.getSource() + " " + > event.getTarget()); > > } > }); > > However, you then need to determine that the target was a table header > node and that seems like reaching into the implementation. I would suggest > that you stick with setGraphic() if this is working for you and enter a > JIRA feature request for mouse and other event handlers for table column > headers. > > Steve > > > On 23/10/2012 8:03 PM, Pedro Duque Vieira wrote: > >> Somehow my email below didn't get any response so I'm sending it again.. >> ---------- Forwarded message ---------- >> From: Pedro Duque Vieira >> > >> Date: Tue, Oct 23, 2012 at 12:42 AM >> Subject: TableView - listening to events on table headers >> To: OpenJFX Mailing List >> > >> >> >> Hi, >> >> In my app I have to listen to mouse events on table headers, I've tried to >> come up with a good solution to this but haven't found any. Posting in the >> JavaFX OTN forums also did not bring any better solution. >> As it is the only solution I see is replacing the headers via setGraphic >> method of TableColumn and attaching listeners to what I pass in to the >> setGraphic, even though I will end up replacing the TableColumn header >> with >> the same type of node as was previously present, so I end up calling >> setGraphic only for the sake of being able to attach listeners. This looks >> ugly. >> >> Is there any better solution for this? >> >> My use case is: >> 1- user mouse clicks the a table header to select a column >> 2- column gets selected. >> 3- Selected column is visually highlighted. >> >> Thanks, >> >> >> -- Pedro Duque Vieira From david.grieve at oracle.com Wed Oct 24 08:23:05 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 24 Oct 2012 11:23:05 -0400 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: <5087C93E.6070708@media-interactive.de> References: <5086C202.5020304@media-interactive.de> <5087C93E.6070708@media-interactive.de> Message-ID: <83D853E0-D450-4D0A-ACE4-5A09FE59387B@oracle.com> Some (possibly) related discussions from OTN: https://forums.oracle.com/forums/thread.jspa?threadID=2451829 https://forums.oracle.com/forums/thread.jspa?threadID=2354253 On Oct 24, 2012, at 6:55 AM, Werner Lehmann wrote: > I can answer this part now: put an invalidation listener on the scene property of the node used for CustomMenuItem. Once that node gets a scene, it can be used to add a stylesheet. Not really straightforward though. I'd still prefer if the context menu could just use the stylesheet of its MenuButton. > > Werner > > On 23.10.2012 18:12, Werner Lehmann wrote: >> This works ok but styling is difficult - how can I style the >> menuitem/contextmenu used by the MenuButton skin? Apparently I cannot >> access it from the MenuButton control. David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From lehmann at media-interactive.de Wed Oct 24 08:59:00 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 24 Oct 2012 17:59:00 +0200 Subject: ContextMenu styling (esp. for MenuButton) In-Reply-To: <83D853E0-D450-4D0A-ACE4-5A09FE59387B@oracle.com> References: <5086C202.5020304@media-interactive.de> <5087C93E.6070708@media-interactive.de> <83D853E0-D450-4D0A-ACE4-5A09FE59387B@oracle.com> Message-ID: <50881044.9010501@media-interactive.de> David, thanks. I have shared the info I have on OTN. Unfortunately, that does not include a good or even complete solution... In the end I am afraid there are only two choices: a) MenuButton with unstyled menu b) Button with manually managed ContextMenu. Second choice is not that bad but I liked MenuButton and do not really want to recreate what SplitMenuButton already does for me. Werner On 24.10.2012 17:23, David Grieve wrote: > Some (possibly) related discussions from OTN: > https://forums.oracle.com/forums/thread.jspa?threadID=2451829 > https://forums.oracle.com/forums/thread.jspa?threadID=2354253 From John_Smith at symantec.com Wed Oct 24 10:17:30 2012 From: John_Smith at symantec.com (John Smith) Date: Wed, 24 Oct 2012 10:17:30 -0700 Subject: Ensemble in Mac App Store In-Reply-To: References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160263AA0D@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> If I find some time, maybe I'll buy a Mac and try to build a GPLed demo to be submitted to the App Store. Thanks for the info Scott and Phil. -----Original Message----- From: Scott Kovatch [mailto:scott.kovatch at oracle.com] Sent: Tuesday, October 23, 2012 9:23 AM To: John Smith Cc: Richard Bair; openjfx-dev at openjdk.java.net Mailing Subject: Re: Ensemble in Mac App Store On Oct 22, 2012, at 4:36 PM, John Smith wrote: > Really nice work on packaging Ensemble and placing it in the Mac App Store. > > If one wants to package an application for the Mac App Store, which build must be used? Well, I should come clean here, and admit that it wasn't just a simple matter of downloading a JDK release and packaging everything up. I checked out the source of OpenJDK (jdk7u branch) and built a JDK myself. There were some known issues in the AWT that I patched locally. All of those changes have been checked in, so there should be an upcoming release (probably 7u12) with all of the fixes. I also took what should have been FX 2.2.4 and combined that with the JDK. > So, currently, is it only Oracle which can publish JavaFX applications in the Mac App Store? > And the rest of the world will be able to do the packaging in Spring when JDK 7u12 / FX 2.2.6 is released? The answer to these two questions is yes. Ensemble should be seen right now as proof that 'yes, a JRE and JavaFX can be put into the OS X app store.' We have a chicken-and-egg problem in that we can't stand up and say it can be done unless we do it ourselves first. So, that's what we did. Unfortunately things didn't line up schedule-wise, so the community can't do it yet. We are still on track to have a release that is ready to use by anyone for packaging -- nothing has changed there. You can start with the pre-release of 7u10, which *should* have all of the JDK and JavaFX fixes that would have kept you from submitting to the store, but I'd have to check to see if all of the ones we know about made it. 7u12 will definitely have all of them. -- Scott K. -----Original Message----- From: Phil Race [mailto:philip.race at oracle.com] Sent: Tuesday, October 23, 2012 9:35 AM To: Richard Bair Cc: John Smith; openjfx-dev at openjdk.java.net Mailing Subject: Re: Ensemble in Mac App Store If you are comfortable with the GPL then you can create your own build from openjdk sources ... -phil. From johan at lodgon.com Wed Oct 24 11:33:43 2012 From: johan at lodgon.com (Johan Vos) Date: Wed, 24 Oct 2012 20:33:43 +0200 Subject: javafx 8 In-Reply-To: References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> <5087EFE4.5060101@tbee.org> Message-ID: I have the same issue when working with the source code of JavaFX 8: downloaded an EA bundle of JDK 8, copied the jfxrt.jar to the artifacts directory, and then trying to build open-jfx. There are a number of missing methods or classes in the jfxrt.jar that is bundled with JDK8 EAb61 (e.g. UnmodifiableArrayList which is expected to be in import com.sun.javafx.UnmodifiableArrayList) Is there a way we can get the latest jfxrt.jar in order to build open-jfx? - Johan 2012/10/24 Joe McGlynn > Indeed, the latest EA release is at least a week behind internal > development work. So that is entirely possible. > > -- > On Oct 24, 2012, at 6:40 AM, Tom Eugelink wrote: > > > The JavaFX link only contains demo's. But the JDK8 EA indeed contains a > JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version that > the demo app is compiled against (a method is missing). But down to one > error. > > > > Thanks! > > > > > > > > > > On 2012-10-24 15:19, Knut Arne Vedaa wrote: > >> Haven't tried it myself, but it seems to be available from here, as > part of JDK8: > >> > >> http://jdk8.java.net/download.html > >> > >> > >> Knut Arne Vedaa > >> > >> On 24.10.2012 15:07, Tom Eugelink wrote: > >>> Stephen asked me to take a peek at a demo app for JFall next week. It > >>> seems from the compilation errors that it requires JavaFX 8. Is there a > >>> early access binary release is JFX8 available anywhere? Because since > >>> JFX is not fully open sourced, I do not think I'll be able to compile > it > >>> myself. Or am I? > >>> > >>> Tom > >>> > >>> > >> > > > > From steve.x.northover at oracle.com Wed Oct 24 12:16:32 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 24 Oct 2012 15:16:32 -0400 Subject: javafx 8 In-Reply-To: References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> <5087EFE4.5060101@tbee.org> Message-ID: <50883E90.1050804@oracle.com> Hi Johan, I was able to get OpenJFX to build just now and yesterday (on Windows under Cygwin) when fixing the build instructions for the OpenJFX wiki. I downloaded jdk-8-ea-bin-b61-windows-i586-18_oct_2012.exe and followed the instructions that I created here: https://wikis.oracle.com/display/OpenJDK/Building+OpenJFX to make sure they were right. I realize that the instructions are wrong on OpenJFX and will get to that soon. Thanks, Steve On 24/10/2012 2:33 PM, Johan Vos wrote: > I have the same issue when working with the source code of JavaFX 8: > downloaded an EA bundle of JDK 8, copied the jfxrt.jar to the artifacts > directory, and then trying to build open-jfx. There are a number of missing > methods or classes in the jfxrt.jar that is bundled with JDK8 EAb61 (e.g. > UnmodifiableArrayList which is expected to be in import > com.sun.javafx.UnmodifiableArrayList) > Is there a way we can get the latest jfxrt.jar in order to build open-jfx? > > - Johan > > 2012/10/24 Joe McGlynn > >> Indeed, the latest EA release is at least a week behind internal >> development work. So that is entirely possible. >> >> -- >> On Oct 24, 2012, at 6:40 AM, Tom Eugelink wrote: >> >>> The JavaFX link only contains demo's. But the JDK8 EA indeed contains a >> JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version that >> the demo app is compiled against (a method is missing). But down to one >> error. >>> Thanks! >>> >>> >>> >>> >>> On 2012-10-24 15:19, Knut Arne Vedaa wrote: >>>> Haven't tried it myself, but it seems to be available from here, as >> part of JDK8: >>>> http://jdk8.java.net/download.html >>>> >>>> >>>> Knut Arne Vedaa >>>> >>>> On 24.10.2012 15:07, Tom Eugelink wrote: >>>>> Stephen asked me to take a peek at a demo app for JFall next week. It >>>>> seems from the compilation errors that it requires JavaFX 8. Is there a >>>>> early access binary release is JFX8 available anywhere? Because since >>>>> JFX is not fully open sourced, I do not think I'll be able to compile >> it >>>>> myself. Or am I? >>>>> >>>>> Tom >>>>> >>>>> >> From johan at lodgon.com Wed Oct 24 12:30:57 2012 From: johan at lodgon.com (Johan Vos) Date: Wed, 24 Oct 2012 21:30:57 +0200 Subject: javafx 8 In-Reply-To: <50883E90.1050804@oracle.com> References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> <5087EFE4.5060101@tbee.org> <50883E90.1050804@oracle.com> Message-ID: My mistake, I was using an older build of 8EA than b61. Updated to that one and it's working fine now. com.sun.javafx.UnmodifiableArrayList.class indeed exists in b61. Thanks! - Johan 2012/10/24 > Hi Johan, > > I was able to get OpenJFX to build just now and yesterday (on Windows > under Cygwin) when fixing the build instructions for the OpenJFX wiki. I > downloaded jdk-8-ea-bin-b61-windows-i586-**18_oct_2012.exe and followed > the instructions that I created here: https://wikis.oracle.com/** > display/OpenJDK/Building+**OpenJFXto make sure they were right. > > I realize that the instructions are wrong on OpenJFX and will get to that > soon. > > Thanks, > Steve > > > On 24/10/2012 2:33 PM, Johan Vos wrote: > >> I have the same issue when working with the source code of JavaFX 8: >> downloaded an EA bundle of JDK 8, copied the jfxrt.jar to the artifacts >> directory, and then trying to build open-jfx. There are a number of >> missing >> methods or classes in the jfxrt.jar that is bundled with JDK8 EAb61 (e.g. >> UnmodifiableArrayList which is expected to be in import >> com.sun.javafx.**UnmodifiableArrayList) >> Is there a way we can get the latest jfxrt.jar in order to build open-jfx? >> >> - Johan >> >> 2012/10/24 Joe McGlynn >> >> Indeed, the latest EA release is at least a week behind internal >>> development work. So that is entirely possible. >>> >>> -- >>> On Oct 24, 2012, at 6:40 AM, Tom Eugelink wrote: >>> >>> The JavaFX link only contains demo's. But the JDK8 EA indeed contains a >>>> >>> JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version >>> that >>> the demo app is compiled against (a method is missing). But down to one >>> error. >>> >>>> Thanks! >>>> >>>> >>>> >>>> >>>> On 2012-10-24 15:19, Knut Arne Vedaa wrote: >>>> >>>>> Haven't tried it myself, but it seems to be available from here, as >>>>> >>>> part of JDK8: >>> >>>> http://jdk8.java.net/download.**html >>>>> >>>>> >>>>> Knut Arne Vedaa >>>>> >>>>> On 24.10.2012 15:07, Tom Eugelink wrote: >>>>> >>>>>> Stephen asked me to take a peek at a demo app for JFall next week. It >>>>>> seems from the compilation errors that it requires JavaFX 8. Is there >>>>>> a >>>>>> early access binary release is JFX8 available anywhere? Because since >>>>>> JFX is not fully open sourced, I do not think I'll be able to compile >>>>>> >>>>> it >>> >>>> myself. Or am I? >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>> From jonathan.giles at oracle.com Wed Oct 24 12:44:32 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 25 Oct 2012 08:44:32 +1300 Subject: Announcing the JavaFX UI controls sandbox Message-ID: <50884520.2020607@oracle.com> Hi everyone. This is something I've been waiting a really, really, really long time to announce, but it has finally happened. Today I am so pleased to announce the opening of the JavaFX UI controls sandbox repository on OpenJFX. This repo is a fork of the JavaFX 8.0 controls repo, but will occasionally sync from there to keep it up to date. This repo is intended for OpenJFX developers to put their 'toys' until such time that they get called up to the big leagues for inclusion into OpenJFX itself (although there are no guarantees that this will ever happen). This means that the controls are functional, but most probably not feature complete with a finalised API or any significant documentation. The reason why I've been wanting to open this sandbox up is so that members of the JavaFX community can get super early access to our controls as soon as they reach the most minimal level of maturity, and help guide them along their paths to adulthood. I also wanted to do this as it takes a long time between developing a UI control and having it appear in a JavaFX release. This is something that has frustrated me, and a number of you, to no end. From the get-go there are a few controls in this repo that you may be interested to play with and give us feedback on. They are TreeTableView (although note this is currently undergoing a total rewrite), Dialogs (ala JOptionPane from Swing), TableView cell span support (look at TableView.spanModel for more info), and a RangeSlider control. These controls will develop over time, but of course we're always on the lookout for others who want to improve these controls for us. If you're interested specifically in tending to the new controls in the sandbox, please email me and we can discuss it. For those of you interested in taking a look at the code, you can do a 'hg clone' of the following url: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt. Finally, there are some screenshots of the new controls here: http://fxexperience.com/2012/10/announcing-the-javafx-ui-controls-sandbox/ Thanks, Jonathan From zonski at gmail.com Wed Oct 24 12:51:13 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 25 Oct 2012 06:51:13 +1100 Subject: Ensemble in Mac App Store In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160263AA0D@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <2820926E-9933-46F4-87B3-E579990BD094@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216020CCF39@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <411E73D23DEC4C46BA48F2B6D8BF3D22160263AA0D@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <54D5997E-5434-4F1B-AFAB-0D5B1FCD18E7@gmail.com> According to this (and other articles), GPL is not allowed in the Mac store: http://apple.stackexchange.com/questions/6109/is-it-possible-to-have-gpl-software-in-the-mac-app-store Not sure how Scott got away with it? On 25/10/2012, at 4:17 AM, John Smith wrote: > If I find some time, maybe I'll buy a Mac and try to build a GPLed demo to be submitted to the App Store. > Thanks for the info Scott and Phil. > > -----Original Message----- > From: Scott Kovatch [mailto:scott.kovatch at oracle.com] > Sent: Tuesday, October 23, 2012 9:23 AM > To: John Smith > Cc: Richard Bair; openjfx-dev at openjdk.java.net Mailing > Subject: Re: Ensemble in Mac App Store > > > On Oct 22, 2012, at 4:36 PM, John Smith wrote: > >> Really nice work on packaging Ensemble and placing it in the Mac App Store. >> >> If one wants to package an application for the Mac App Store, which build must be used? > > Well, I should come clean here, and admit that it wasn't just a simple matter of downloading a JDK release and packaging everything up. > > I checked out the source of OpenJDK (jdk7u branch) and built a JDK myself. There were some known issues in the AWT that I patched locally. All of those changes have been checked in, so there should be an upcoming release (probably 7u12) with all of the fixes. > > I also took what should have been FX 2.2.4 and combined that with the JDK. > >> So, currently, is it only Oracle which can publish JavaFX applications in the Mac App Store? >> And the rest of the world will be able to do the packaging in Spring when JDK 7u12 / FX 2.2.6 is released? > > > The answer to these two questions is yes. Ensemble should be seen right now as proof that 'yes, a JRE and JavaFX can be put into the OS X app store.' We have a chicken-and-egg problem in that we can't stand up and say it can be done unless we do it ourselves first. So, that's what we did. Unfortunately things didn't line up schedule-wise, so the community can't do it yet. > > We are still on track to have a release that is ready to use by anyone for packaging -- nothing has changed there. You can start with the pre-release of 7u10, which *should* have all of the JDK and JavaFX fixes that would have kept you from submitting to the store, but I'd have to check to see if all of the ones we know about made it. 7u12 will definitely have all of them. > > -- Scott K. > > > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Tuesday, October 23, 2012 9:35 AM > To: Richard Bair > Cc: John Smith; openjfx-dev at openjdk.java.net Mailing > Subject: Re: Ensemble in Mac App Store > > If you are comfortable with the GPL then you can create your own build from openjdk sources ... > > -phil. From hang.vo at oracle.com Wed Oct 24 13:05:09 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 24 Oct 2012 20:05:09 +0000 Subject: hg: openjfx/sandbox-8/controls/rt: 9 new changesets Message-ID: <20121024200518.8E4FA4750E@hg.openjdk.java.net> Changeset: 0627d31e5f6b Author: jgiles Date: 2012-10-09 10:19 -0700 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/0627d31e5f6b Moving Dialogs to javafx.scene.control and consolidating in the Dialogs class - API is accessible via the Dialogs class. - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogResources.java - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogTemplate.java - javafx-ui-controls/src/com/preview/javafx/scene/control/Dialogs.java - javafx-ui-controls/src/com/preview/javafx/scene/control/ExceptionDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/FXDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/UITextArea.java - javafx-ui-controls/src/com/preview/javafx/scene/control/dialogs.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/Dialogs.java Changeset: 852c2d511e03 Author: jgiles Date: 2012-10-09 10:20 -0700 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/852c2d511e03 Moving VERY early proof of concept TreeTableView into javafx.scene.control package - API will be changing in the coming weeks. - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java + javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java + javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java + javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 08bc96f53b4f Author: jgiles Date: 2012-10-09 10:52 -0700 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/08bc96f53b4f Added very early cell spanning support. Currently this is implemented as a control that extends from TableView (CellSpanTableView), but of course the intention would be to fold this back into TableView when time permits. + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSpanTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/CellSpan.java + javafx-ui-controls/src/javafx/scene/control/CellSpanTableView.java + javafx-ui-controls/src/javafx/scene/control/SpanModel.java Changeset: f78bf1a2be57 Author: jgiles Date: 2012-10-09 11:35 -0700 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/f78bf1a2be57 Disable TreeTableColumn builder generation temporarily. ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: bc4fa93bf0b4 Author: jgiles Date: 2012-10-10 08:23 -0700 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/bc4fa93bf0b4 Adding a proof of concept implementation of a RangeSlider control + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/RangeSliderBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/RangeSliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/RangeSlider.java Changeset: 7eb59377995c Author: jgiles Date: 2012-10-10 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/7eb59377995c Merged cell span support into TableView / TableRowSkin, removing the need for the CellSpanTableView and CellSpanTableRowSkin classes. - javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSpanTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css - javafx-ui-controls/src/javafx/scene/control/CellSpanTableView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: ae2bbf103d6d Author: jgiles Date: 2012-10-23 13:51 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/ae2bbf103d6d Updated SpanModel API to provide the row object and TableColumn as arguments in getCellSpanAt, rather than just the row and column indices (which still remain) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/SpanModel.java Changeset: 585abb1da3d0 Author: jgiles Date: 2012-10-23 15:23 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/585abb1da3d0 Further work on cleaning up the Dialogs code ! javafx-ui-controls/src/javafx/scene/control/Dialogs.java Changeset: 9e5ef340d95f Author: jgiles Date: 2012-10-25 08:37 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/9e5ef340d95f Automated merge with ssh://jfxsrc.us.oracle.com//sandbox/javafx/8.0/controls/jfx/rt - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogResources.java - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogTemplate.java - javafx-ui-controls/src/com/preview/javafx/scene/control/Dialogs.java - javafx-ui-controls/src/com/preview/javafx/scene/control/ExceptionDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/FXDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java - javafx-ui-controls/src/com/preview/javafx/scene/control/UITextArea.java - javafx-ui-controls/src/com/preview/javafx/scene/control/dialogs.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From kevin.rushforth at oracle.com Wed Oct 24 13:18:25 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Oct 2012 13:18:25 -0700 Subject: javafx 8 In-Reply-To: References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> <5087EFE4.5060101@tbee.org> Message-ID: <50884D11.2050902@oracle.com> The source for openjfx/8/master is always kept in sync with the latest weekly build (plus or minus a few hours depending on when the build is uploaded to java.net), so if you take the currently weekly build of jdk8 and build openjfx/8/master against that jfxrt.jar in that build, it should work. I just tried this and had no problems building it. Btw, the specific class you metioned, com.sun.javafx.UnmodifiableArrayList, was added several weeks ago so I suspect that yours is a different problem. Can you double-check that you are actually picking up the jfxrt.jar from jdk8-b61 ? -- Kevin Johan Vos wrote: > I have the same issue when working with the source code of JavaFX 8: > downloaded an EA bundle of JDK 8, copied the jfxrt.jar to the artifacts > directory, and then trying to build open-jfx. There are a number of missing > methods or classes in the jfxrt.jar that is bundled with JDK8 EAb61 (e.g. > UnmodifiableArrayList which is expected to be in import > com.sun.javafx.UnmodifiableArrayList) > Is there a way we can get the latest jfxrt.jar in order to build open-jfx? > > - Johan > > 2012/10/24 Joe McGlynn > > >> Indeed, the latest EA release is at least a week behind internal >> development work. So that is entirely possible. >> >> -- >> On Oct 24, 2012, at 6:40 AM, Tom Eugelink wrote: >> >> >>> The JavaFX link only contains demo's. But the JDK8 EA indeed contains a >>> >> JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version that >> the demo app is compiled against (a method is missing). But down to one >> error. >> >>> Thanks! >>> >>> >>> >>> >>> On 2012-10-24 15:19, Knut Arne Vedaa wrote: >>> >>>> Haven't tried it myself, but it seems to be available from here, as >>>> >> part of JDK8: >> >>>> http://jdk8.java.net/download.html >>>> >>>> >>>> Knut Arne Vedaa >>>> >>>> On 24.10.2012 15:07, Tom Eugelink wrote: >>>> >>>>> Stephen asked me to take a peek at a demo app for JFall next week. It >>>>> seems from the compilation errors that it requires JavaFX 8. Is there a >>>>> early access binary release is JFX8 available anywhere? Because since >>>>> JFX is not fully open sourced, I do not think I'll be able to compile >>>>> >> it >> >>>>> myself. Or am I? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >> From kevin.rushforth at oracle.com Wed Oct 24 13:22:21 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Oct 2012 13:22:21 -0700 Subject: javafx 8 In-Reply-To: References: <5087E818.8020804@tbee.org> <5087EAE7.4000304@broadpark.no> <5087EFE4.5060101@tbee.org> <50883E90.1050804@oracle.com> Message-ID: <50884DFD.9030906@oracle.com> Good to hear. Then you can ignore the e-mail I sent before I saw this. -- Kevin Johan Vos wrote: > My mistake, I was using an older build of 8EA than b61. Updated to that one > and it's working fine now. > com.sun.javafx.UnmodifiableArrayList.class indeed exists in b61. > > Thanks! > > - Johan > > 2012/10/24 > > >> Hi Johan, >> >> I was able to get OpenJFX to build just now and yesterday (on Windows >> under Cygwin) when fixing the build instructions for the OpenJFX wiki. I >> downloaded jdk-8-ea-bin-b61-windows-i586-**18_oct_2012.exe and followed >> the instructions that I created here: https://wikis.oracle.com/** >> display/OpenJDK/Building+**OpenJFXto make sure they were right. >> >> I realize that the instructions are wrong on OpenJFX and will get to that >> soon. >> >> Thanks, >> Steve >> >> >> On 24/10/2012 2:33 PM, Johan Vos wrote: >> >> >>> I have the same issue when working with the source code of JavaFX 8: >>> downloaded an EA bundle of JDK 8, copied the jfxrt.jar to the artifacts >>> directory, and then trying to build open-jfx. There are a number of >>> missing >>> methods or classes in the jfxrt.jar that is bundled with JDK8 EAb61 (e.g. >>> UnmodifiableArrayList which is expected to be in import >>> com.sun.javafx.**UnmodifiableArrayList) >>> Is there a way we can get the latest jfxrt.jar in order to build open-jfx? >>> >>> - Johan >>> >>> 2012/10/24 Joe McGlynn >>> >>> Indeed, the latest EA release is at least a week behind internal >>> >>>> development work. So that is entirely possible. >>>> >>>> -- >>>> On Oct 24, 2012, at 6:40 AM, Tom Eugelink wrote: >>>> >>>> The JavaFX link only contains demo's. But the JDK8 EA indeed contains a >>>> >>>> JavaFX8 jfxrt.jar. Unfortunately that does not seem to be the version >>>> that >>>> the demo app is compiled against (a method is missing). But down to one >>>> error. >>>> >>>> >>>>> Thanks! >>>>> >>>>> >>>>> >>>>> >>>>> On 2012-10-24 15:19, Knut Arne Vedaa wrote: >>>>> >>>>> >>>>>> Haven't tried it myself, but it seems to be available from here, as >>>>>> >>>>>> >>>>> part of JDK8: >>>>> >>>>> http://jdk8.java.net/download.**html >>>>> >>>>>> Knut Arne Vedaa >>>>>> >>>>>> On 24.10.2012 15:07, Tom Eugelink wrote: >>>>>> >>>>>> >>>>>>> Stephen asked me to take a peek at a demo app for JFall next week. It >>>>>>> seems from the compilation errors that it requires JavaFX 8. Is there >>>>>>> a >>>>>>> early access binary release is JFX8 available anywhere? Because since >>>>>>> JFX is not fully open sourced, I do not think I'll be able to compile >>>>>>> >>>>>>> >>>>>> it >>>>>> >>>>> myself. Or am I? >>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> >>>>>>> From hang.vo at oracle.com Wed Oct 24 14:48:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 24 Oct 2012 21:48:06 +0000 Subject: hg: openjfx/8/controls/rt: Merging Accessibility code from sandbox to controls-scrum Message-ID: <20121024214811.9F19E47524@hg.openjdk.java.net> Changeset: 0558587f6f1b Author: psomashe at PSOMASHE-LAP.st-users.us.oracle.com Date: 2012-10-24 22:44 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0558587f6f1b Merging Accessibility code from sandbox to controls-scrum ! javafx-ui-common/build-closed.xml ! javafx-ui-common/nbproject/project.xml ! javafx-ui-common/src/com/sun/javafx/Logging.java + javafx-ui-common/src/com/sun/javafx/accessible/AccessibleNode.java + javafx-ui-common/src/com/sun/javafx/accessible/AccessibleStage.java + javafx-ui-common/src/com/sun/javafx/accessible/AccessibleText.java ! javafx-ui-common/src/com/sun/javafx/stage/StagePeerListener.java ! javafx-ui-common/src/com/sun/javafx/stage/WindowPeerListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStageListener.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-controls/build-closed.xml ! javafx-ui-controls/build-common.xml + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleButton.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleCheckBox.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleControl.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleList.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleListItem.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleRadioButton.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleSlider.java ! javafx-ui-controls/src/javafx/scene/control/Button.java ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/project.properties ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java From zonski at gmail.com Wed Oct 24 15:02:53 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 25 Oct 2012 09:02:53 +1100 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <4E4CDCE2-5EEC-419C-A6E6-B60257FBAE9F@gmail.com> References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> <22118C95-B840-4F35-BBE0-776254CFC3B5@rockit.dk> <5087F379.8090704@oracle.com> <4E4CDCE2-5EEC-419C-A6E6-B60257FBAE9F@gmail.com> Message-ID: In that case, might be worth highlighting that if you are using any of the deployment options that require the JRE to be 'installed' (i.e. *all of them * except native), then the JRE will automatically try to upgrade itself on your users' machines. Meaning that at any given moment your app could just stop working (e.g. due to a change affecting something like your workaround below) without you, the developer, doing anything. I nearly had this happen with a commercial product of mine in a previous JRE release but I noticed it (by pure chance) a couple of days before the JRE release. I did some (unpaid) late nights to make my code work on both versions of the JRE. Now every JRE release there's a chance it could (and probably will) break though, which is one reason, among many, why that client is considering a rewrite to HTML (cross browser compatibility pales in comparison to the sort of risk created by this JRE update). This is one of the main reasons I would recommend the native installers as the only 'safe' option. Since the JRE is bundled into your distro and never actually 'installed', you can guarantee control over it. Everything else, you are at the mercy of the elements. This is just another issue that has been (recurringly) discussed on here but not seen as important. Best to assume you're on your own for this sort of stuff and use extremely defensive strategies in both your code and your deployments. On Thu, Oct 25, 2012 at 1:52 AM, Scott Palmer wrote: > > On 2012-10-24, at 9:56 AM, Kevin Rushforth > wrote: > > > > I can confirm that simply dragging jfxrt.jar to the ext package works > like a charm. > > > > Current thinking is that putting jfxrt.jar in lib/ext is what we will do > to include JavaFX on the default classpath in FX 8 (and possibly 7u12 if no > issues arise with this transition). > > > > -- Kevin > > Ah.. then that will break my Maven "hack". Since the path to jfxrt.jar > will change and Maven will barf when it can't find the system dependency. > I'm glad that I haven't rolled out that hack yet. > > Scott From swpalmer at gmail.com Wed Oct 24 15:46:21 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 24 Oct 2012 18:46:21 -0400 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: References: <541AFC03-1B7E-4BF5-B95A-010D15025C34@rockit.dk> <3DD7AF31-D5F5-4A15-ABB7-0B8C1D853C5A@gmail.com> <67864A2A-B3A4-4F94-B830-D22AD0C17C1E@gmail.com> <3EA26F7F-32CC-42E7-9EBA-47D81C545588@gmail.com> <22118C95-B840-4F35-BBE0-776254CFC3B5@rockit.dk> <5087F379.8090704@oracle.com> <4E4CDCE2-5EEC-419C-A6E6-B60257FBAE9F@gmail.com> Message-ID: <46CD8C3C-9012-4097-AFE6-EF79AE5BDFA6@gmail.com> We always install a private JRE for our apps anyway. It will be shared among apps from our company only. But I meant the update would break my build. Running the app. should still work. I think we test to see if we can load the Node class and if that fails only then attempt to add jfxrt.jar to the classpath by assuming it is beside rt.jar (or whatever jar String.class loads from). Since Node will be on the classpath we will skip trying to hack jfxrt.jar onto the classpath in the first place so it won't matter that it isn't where we expect it. Though I'm generally disappointed that things will change yet again in unexpected ways if jfxrt.jar moves to a new location. Scott On 2012-10-24, at 6:02 PM, Daniel Zwolenski wrote: > In that case, might be worth highlighting that if you are using any of the deployment options that require the JRE to be 'installed' (i.e. all of them except native), then the JRE will automatically try to upgrade itself on your users' machines. Meaning that at any given moment your app could just stop working (e.g. due to a change affecting something like your workaround below) without you, the developer, doing anything. > > I nearly had this happen with a commercial product of mine in a previous JRE release but I noticed it (by pure chance) a couple of days before the JRE release. I did some (unpaid) late nights to make my code work on both versions of the JRE. Now every JRE release there's a chance it could (and probably will) break though, which is one reason, among many, why that client is considering a rewrite to HTML (cross browser compatibility pales in comparison to the sort of risk created by this JRE update). > > This is one of the main reasons I would recommend the native installers as the only 'safe' option. Since the JRE is bundled into your distro and never actually 'installed', you can guarantee control over it. Everything else, you are at the mercy of the elements. > > This is just another issue that has been (recurringly) discussed on here but not seen as important. Best to assume you're on your own for this sort of stuff and use extremely defensive strategies in both your code and your deployments. > > > On Thu, Oct 25, 2012 at 1:52 AM, Scott Palmer wrote: >> >> On 2012-10-24, at 9:56 AM, Kevin Rushforth wrote: >> >> > > I can confirm that simply dragging jfxrt.jar to the ext package works like a charm. >> > >> > Current thinking is that putting jfxrt.jar in lib/ext is what we will do to include JavaFX on the default classpath in FX 8 (and possibly 7u12 if no issues arise with this transition). >> > >> > -- Kevin >> >> Ah.. then that will break my Maven "hack". Since the path to jfxrt.jar will change and Maven will barf when it can't find the system dependency. I'm glad that I haven't rolled out that hack yet. >> >> Scott > From randahl at rockit.dk Wed Oct 24 16:56:53 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 25 Oct 2012 01:56:53 +0200 Subject: Announcing the JavaFX UI controls sandbox In-Reply-To: <50884520.2020607@oracle.com> References: <50884520.2020607@oracle.com> Message-ID: <566376B0-0FF2-4D7D-991C-3F2BCE731B76@rockit.dk> Jonathan, this looks wonderful. I bet a lot of us are already developing a lot of cool controls, and I would love to see more synergy between projects for the benefit of everyone. Would you be interested in evaluating other kinds controls, if a project has made something which is not in the sandbox already? Randahl On Oct 24, 2012, at 21:44 , Jonathan Giles wrote: > Hi everyone. > > This is something I've been waiting a really, really, really long time to announce, but it has finally happened. Today I am so pleased to announce the opening of the JavaFX UI controls sandbox repository on OpenJFX. This repo is a fork of the JavaFX 8.0 controls repo, but will occasionally sync from there to keep it up to date. This repo is intended for OpenJFX developers to put their 'toys' until such time that they get called up to the big leagues for inclusion into OpenJFX itself (although there are no guarantees that this will ever happen). This means that the controls are functional, but most probably not feature complete with a finalised API or any significant documentation. > > The reason why I've been wanting to open this sandbox up is so that members of the JavaFX community can get super early access to our controls as soon as they reach the most minimal level of maturity, and help guide them along their paths to adulthood. I also wanted to do this as it takes a long time between developing a UI control and having it appear in a JavaFX release. This is something that has frustrated me, and a number of you, to no end. > > From the get-go there are a few controls in this repo that you may be interested to play with and give us feedback on. They are TreeTableView (although note this is currently undergoing a total rewrite), Dialogs (ala JOptionPane from Swing), TableView cell span support (look at TableView.spanModel for more info), and a RangeSlider control. These controls will develop over time, but of course we're always on the lookout for others who want to improve these controls for us. If you're interested specifically in tending to the new controls in the sandbox, please email me and we can discuss it. > > For those of you interested in taking a look at the code, you can do a 'hg clone' of the following url: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt. > > Finally, there are some screenshots of the new controls here: http://fxexperience.com/2012/10/announcing-the-javafx-ui-controls-sandbox/ > > Thanks, > Jonathan From jonathan.giles at oracle.com Wed Oct 24 17:04:46 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 25 Oct 2012 13:04:46 +1300 Subject: Announcing the JavaFX UI controls sandbox In-Reply-To: <566376B0-0FF2-4D7D-991C-3F2BCE731B76@rockit.dk> References: <50884520.2020607@oracle.com> <566376B0-0FF2-4D7D-991C-3F2BCE731B76@rockit.dk> Message-ID: <5088821E.3090308@oracle.com> Randahl, Of course I would love to see people contributing to the OpenJFX sandbox. First however developers would have to sign the Oracle Contributor Agreement, and then we can start accepting contributions. After some time of contributions being submitted via Jira I would be very happy to start giving access to developers to directly write to the repo (in other words, we want developers to prove themselves for a short while first). In general I think it is safe to say that we in OpenJFX (aka Oracle employees presently) would love to start seeing contributions from the community. OpenJFX is supposed to make us all one big team, so I can't wait for that to happen. Of course, I do want to be very clear that a viable alternative repo already exists (and the bar for entry is somewhat lower): JFXtras is a growing repository full of JavaFX UI controls and other cool gadgets. I would say that the primary difference between the two repos is what JavaFX version they base themselves on: JFXtras is always based on the latest official release of JavaFX, whereas the sandbox is based on the next release (so in this case, JavaFX 8.0). Of course, I would love to see the controls we put out today in the sandbox 'back-ported' to JFXtras so that they are available to a wider community. -- Jonathan On 25/10/2012 12:56 p.m., Randahl Fink Isaksen wrote: > Jonathan, this looks wonderful. I bet a lot of us are already developing a lot of cool controls, and I would love to see more synergy between projects for the benefit of everyone. > > Would you be interested in evaluating other kinds controls, if a project has made something which is not in the sandbox already? > > Randahl > > > On Oct 24, 2012, at 21:44 , Jonathan Giles wrote: > >> Hi everyone. >> >> This is something I've been waiting a really, really, really long time to announce, but it has finally happened. Today I am so pleased to announce the opening of the JavaFX UI controls sandbox repository on OpenJFX. This repo is a fork of the JavaFX 8.0 controls repo, but will occasionally sync from there to keep it up to date. This repo is intended for OpenJFX developers to put their 'toys' until such time that they get called up to the big leagues for inclusion into OpenJFX itself (although there are no guarantees that this will ever happen). This means that the controls are functional, but most probably not feature complete with a finalised API or any significant documentation. >> >> The reason why I've been wanting to open this sandbox up is so that members of the JavaFX community can get super early access to our controls as soon as they reach the most minimal level of maturity, and help guide them along their paths to adulthood. I also wanted to do this as it takes a long time between developing a UI control and having it appear in a JavaFX release. This is something that has frustrated me, and a number of you, to no end. >> >> From the get-go there are a few controls in this repo that you may be interested to play with and give us feedback on. They are TreeTableView (although note this is currently undergoing a total rewrite), Dialogs (ala JOptionPane from Swing), TableView cell span support (look at TableView.spanModel for more info), and a RangeSlider control. These controls will develop over time, but of course we're always on the lookout for others who want to improve these controls for us. If you're interested specifically in tending to the new controls in the sandbox, please email me and we can discuss it. >> >> For those of you interested in taking a look at the code, you can do a 'hg clone' of the following url: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt. >> >> Finally, there are some screenshots of the new controls here: http://fxexperience.com/2012/10/announcing-the-javafx-ui-controls-sandbox/ >> >> Thanks, >> Jonathan From swpalmer at gmail.com Wed Oct 24 11:59:45 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 24 Oct 2012 14:59:45 -0400 Subject: What to expect from current 8.0 EA builds? Message-ID: What should I expect from JavaFX in the 8-ea-b61 release? I ask because my first test was not promising. There were many rendering glitches on OS X (10.8.2). Good: java version "1.7.0_10-ea" Java(TM) SE Runtime Environment (build 1.7.0_10-ea-b12) Bad: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b61) As you can see? -There was garbage left behind as I dragged my node to position it. -The arrowhead has a glitch. (It is a Region with a SVG path set via the CSS) -The area with the gears isn't rendering the background colour everywhere it is supposed to. -The curve in that same corner is positioned one pixel too low so it creeps into the border area. (The kerning on the text is bad, but it is the same for both) All of that is in a JFXPanel, if it makes a difference. Scott From zonski at gmail.com Wed Oct 24 23:01:28 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 25 Oct 2012 17:01:28 +1100 Subject: JFX on iOS - legal barriers to community doing the work? Message-ID: I think the "official" stance regarding JFX on iOS is that the community will build it once everything is open source? I assume this will mean someone porting "OpenJDK+OpenJFX" to the iOS platform? According to everything I can find on the web, GPL is not legally allowed in the iOS app store because the two licences clash. As I understand it both OpenJDK and OpenJFX are distributed under the GPL licence. Doesn't that mean if the community did this port, no one would be legally allowed to deploy it to the app store anyway? From tbee at tbee.org Wed Oct 24 23:48:36 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 25 Oct 2012 08:48:36 +0200 Subject: Announcing the JavaFX UI controls sandbox In-Reply-To: <5088821E.3090308@oracle.com> References: <50884520.2020607@oracle.com> <566376B0-0FF2-4D7D-991C-3F2BCE731B76@rockit.dk> <5088821E.3090308@oracle.com> Message-ID: <5088E0C4.8020503@tbee.org> To be more precise; JFXtras has a repo for the current JFX release, and a repo for the next JFX release (see https://github.com/JFXtras/jfxtras-labs). So if people want to, they can develop on the latest and greatest JFX version. But Jonathan is right that almost all development is done against the current version. Like JavaFX is syncing its version with the JDK, JFXtras syncs with JavaFX. So currently we're on 2.2-r4 and we will be releasing 8.0-r1 when the time comes. Tom On 2012-10-25 02:04, Jonathan Giles wrote: > Randahl, > > Of course I would love to see people contributing to the OpenJFX sandbox. First however developers would have to sign the Oracle Contributor Agreement, and then we can start accepting contributions. After some time of contributions being submitted via Jira I would be very happy to start giving access to developers to directly write to the repo (in other words, we want developers to prove themselves for a short while first). In general I think it is safe to say that we in OpenJFX (aka Oracle employees presently) would love to start seeing contributions from the community. OpenJFX is supposed to make us all one big team, so I can't wait for that to happen. > > Of course, I do want to be very clear that a viable alternative repo already exists (and the bar for entry is somewhat lower): JFXtras is a growing repository full of JavaFX UI controls and other cool gadgets. I would say that the primary difference between the two repos is what JavaFX version they base themselves on: JFXtras is always based on the latest official release of JavaFX, whereas the sandbox is based on the next release (so in this case, JavaFX 8.0). Of course, I would love to see the controls we put out today in the sandbox 'back-ported' to JFXtras so that they are available to a wider community. > > -- Jonathan > > On 25/10/2012 12:56 p.m., Randahl Fink Isaksen wrote: >> Jonathan, this looks wonderful. I bet a lot of us are already developing a lot of cool controls, and I would love to see more synergy between projects for the benefit of everyone. >> >> Would you be interested in evaluating other kinds controls, if a project has made something which is not in the sandbox already? >> >> Randahl >> >> >> On Oct 24, 2012, at 21:44 , Jonathan Giles wrote: >> >>> Hi everyone. >>> >>> This is something I've been waiting a really, really, really long time to announce, but it has finally happened. Today I am so pleased to announce the opening of the JavaFX UI controls sandbox repository on OpenJFX. This repo is a fork of the JavaFX 8.0 controls repo, but will occasionally sync from there to keep it up to date. This repo is intended for OpenJFX developers to put their 'toys' until such time that they get called up to the big leagues for inclusion into OpenJFX itself (although there are no guarantees that this will ever happen). This means that the controls are functional, but most probably not feature complete with a finalised API or any significant documentation. >>> >>> The reason why I've been wanting to open this sandbox up is so that members of the JavaFX community can get super early access to our controls as soon as they reach the most minimal level of maturity, and help guide them along their paths to adulthood. I also wanted to do this as it takes a long time between developing a UI control and having it appear in a JavaFX release. This is something that has frustrated me, and a number of you, to no end. >>> >>> From the get-go there are a few controls in this repo that you may be interested to play with and give us feedback on. They are TreeTableView (although note this is currently undergoing a total rewrite), Dialogs (ala JOptionPane from Swing), TableView cell span support (look at TableView.spanModel for more info), and a RangeSlider control. These controls will develop over time, but of course we're always on the lookout for others who want to improve these controls for us. If you're interested specifically in tending to the new controls in the sandbox, please email me and we can discuss it. >>> >>> For those of you interested in taking a look at the code, you can do a 'hg clone' of the following url: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt. >>> >>> Finally, there are some screenshots of the new controls here: http://fxexperience.com/2012/10/announcing-the-javafx-ui-controls-sandbox/ >>> >>> Thanks, >>> Jonathan > From neugens.limasoftware at gmail.com Thu Oct 25 01:05:55 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 25 Oct 2012 10:05:55 +0200 Subject: JFX on iOS - legal barriers to community doing the work? In-Reply-To: References: Message-ID: 2012/10/25 Daniel Zwolenski : > I think the "official" stance regarding JFX on iOS is that the community > will build it once everything is open source? > > I assume this will mean someone porting "OpenJDK+OpenJFX" to the iOS > platform? > > According to everything I can find on the web, GPL is not legally allowed > in the iOS app store because the two licences clash. > > As I understand it both OpenJDK and OpenJFX are distributed under the GPL > licence. > > Doesn't that mean if the community did this port, no one would be legally > allowed to deploy it to the app store anyway? IANAL, but as far as I understand, yes, you are right. However, if you contribute back this code Oracle can. Depending on how Oracle want to play steward in this process, once this port is contributed back (remember that you signed the OCA in this case), Oracle could still ship a version of JavaFX/OpenJDK on iOS that is not GPL. This is, of course, less than ideal. This is already the case for every GPL application and library, so I think a better way would be for the companies involved (especially Oracle, which has a good weight), to try to push Apple to change this stupid policy, but this is entirely Apple fault, and the reason why iOS is so crippled. I would also love to hear what Oracle thinks on the matter (since this is likely a stopper for them too). Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From phidias51 at gmail.com Thu Oct 25 11:31:06 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 25 Oct 2012 11:31:06 -0700 Subject: JavaFX Event Bus Recommendations Message-ID: In my current application we're using the standard point2point eventing that comes with JavaFX. To create support for a new type of event we: - Create an EventType class. - Create an Event class - Create an Event Listener interface for it. - Add a mixin that makes it easier to add/remove/notify listeners. Since there are several developers on the list who make heavy use of the Spring framework, I was wondering if anyone had tried using the Spring Eventing framework http://blog.yohanliyanage.com/2012/09/eventing-with-spring-framework/ as more scaleable approach to adding support for new events? Or if there were any other Event Bus frameworks that the community could recommend for use with JavaFX? Also, are there any plans to more directly support an Event Bus in JavaFX? Cheers, Mark From richard.bair at oracle.com Thu Oct 25 11:37:13 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 25 Oct 2012 20:37:13 +0200 Subject: JavaFX Event Bus Recommendations In-Reply-To: References: Message-ID: <2AEE69A8-8D3A-48C1-8DA2-EF7865BB8D13@oracle.com> > Also, are there any plans to more directly support an Event Bus in JavaFX? It has come up a few times, but at the moment we don't have any plans for one. If we were to do one, I think we would need to look at each of the existing FX frameworks and see if there is some common ground that could be factored out and standardized. But at this point I feel it is too early for standardization. Richard From John_Smith at symantec.com Thu Oct 25 12:13:25 2012 From: John_Smith at symantec.com (John Smith) Date: Thu, 25 Oct 2012 12:13:25 -0700 Subject: JavaFX Event Bus Recommendations In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> There are a couple of forum threads on Event Buses you could read to see what other people have done around this: https://forums.oracle.com/forums/thread.jspa?messageID=10548299 https://forums.oracle.com/forums/thread.jspa?messageID=10590312 One of them includes a link to a simple JavaFX implementation which Greg Brown created http://code.google.com/p/sjmb/ (unfortunately the link doesn't work for me as I am not authorized to view it). -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner Sent: Thursday, October 25, 2012 11:31 AM To: openjfx-dev at openjdk.java.net Subject: JavaFX Event Bus Recommendations In my current application we're using the standard point2point eventing that comes with JavaFX. To create support for a new type of event we: - Create an EventType class. - Create an Event class - Create an Event Listener interface for it. - Add a mixin that makes it easier to add/remove/notify listeners. Since there are several developers on the list who make heavy use of the Spring framework, I was wondering if anyone had tried using the Spring Eventing framework http://blog.yohanliyanage.com/2012/09/eventing-with-spring-framework/ as more scaleable approach to adding support for new events? Or if there were any other Event Bus frameworks that the community could recommend for use with JavaFX? Also, are there any plans to more directly support an Event Bus in JavaFX? Cheers, Mark From phidias51 at gmail.com Thu Oct 25 13:00:16 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 25 Oct 2012 13:00:16 -0700 Subject: JavaFX Event Bus Recommendations In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Hi John, I had the same problem trying to connect to Greg's project. I've used the SimpleEventBus (another google code project) before on a Swing project: http://code.google.com/p/simpleeventbus/ but not in JavaFX. Cheers, Mark On Thu, Oct 25, 2012 at 12:13 PM, John Smith wrote: > There are a couple of forum threads on Event Buses you could read to see > what other people have done around this: > https://forums.oracle.com/forums/thread.jspa?messageID=10548299 > https://forums.oracle.com/forums/thread.jspa?messageID=10590312 > > One of them includes a link to a simple JavaFX implementation which Greg > Brown created http://code.google.com/p/sjmb/ (unfortunately the link > doesn't work for me as I am not authorized to view it). > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner > Sent: Thursday, October 25, 2012 11:31 AM > To: openjfx-dev at openjdk.java.net > Subject: JavaFX Event Bus Recommendations > > In my current application we're using the standard point2point eventing > that comes with JavaFX. To create support for a new type of event we: > > - Create an EventType class. > - Create an Event class > - Create an Event Listener interface for it. > - Add a mixin that makes it easier to add/remove/notify listeners. > > > Since there are several developers on the list who make heavy use of the > Spring framework, I was wondering if anyone had tried using the Spring > Eventing framework > http://blog.yohanliyanage.com/2012/09/eventing-with-spring-framework/ as > more scaleable approach to adding support for new events? Or if there > were any other Event Bus frameworks that the community could recommend for > use with JavaFX? > > Also, are there any plans to more directly support an Event Bus in JavaFX? > > > Cheers, > > Mark > From zonski at gmail.com Thu Oct 25 13:56:20 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 26 Oct 2012 07:56:20 +1100 Subject: JavaFX Event Bus Recommendations In-Reply-To: References: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <68A90146-D342-4149-8427-182E3844E984@gmail.com> I'm on the side that says this shouldn't be in JFX and should be done via OSS projects. There are many different flavours and styles to this problem and some fit some apps/domains better than others. eg you could have a shared, app-wide model (or tree of models) backing your views with observable properties that you can listen to. This flavour is a kind of state-full event bus that you can query for current state at any time and works well for full client side apps, like an IDE or 3d model editor. It works less well with a client-server system where your 'model' is effectively on the server. Heaps of other options exist with pros and cons. Which one should jfx choose? Also, in general OSS projects will be able to adapt much faster to changes than jre/jfx, make use of other libraries, and be easier for contributors to get involved with (compare fxextras project to oracle fx). It also reduces jfx bloat (eg smaller downloads, less to port to mobile platforms, etc) and keeps the jfx team free to focus on things that need to be done at the platform level, like high speed graphics, 3d rendering, media, *deployment* and cross-platform ports (like mobile). Everything that can be done outside of jfx should be IMO. I'd vote the same for things like validation frameworks (and charts and FXML but too late on those fronts). Core fx should provide lower level hook-ins (like ways to add Node highlights which can be leveraged for validation frameworks). Java is an operating system, not an application framework. That's been part of its long term success. The app frameworks should be built on top of it (like spring, struts, GAE, etc, etc - none of those are part of the jre thankfully!). On 26/10/2012, at 7:00 AM, Mark Fortner wrote: > Hi John, > I had the same problem trying to connect to Greg's project. I've used the > SimpleEventBus (another google code project) before on a Swing project: > http://code.google.com/p/simpleeventbus/ but not in JavaFX. > > Cheers, > > Mark > > > > > On Thu, Oct 25, 2012 at 12:13 PM, John Smith wrote: > >> There are a couple of forum threads on Event Buses you could read to see >> what other people have done around this: >> https://forums.oracle.com/forums/thread.jspa?messageID=10548299 >> https://forums.oracle.com/forums/thread.jspa?messageID=10590312 >> >> One of them includes a link to a simple JavaFX implementation which Greg >> Brown created http://code.google.com/p/sjmb/ (unfortunately the link >> doesn't work for me as I am not authorized to view it). >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto: >> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner >> Sent: Thursday, October 25, 2012 11:31 AM >> To: openjfx-dev at openjdk.java.net >> Subject: JavaFX Event Bus Recommendations >> >> In my current application we're using the standard point2point eventing >> that comes with JavaFX. To create support for a new type of event we: >> >> - Create an EventType class. >> - Create an Event class >> - Create an Event Listener interface for it. >> - Add a mixin that makes it easier to add/remove/notify listeners. >> >> >> Since there are several developers on the list who make heavy use of the >> Spring framework, I was wondering if anyone had tried using the Spring >> Eventing framework >> http://blog.yohanliyanage.com/2012/09/eventing-with-spring-framework/ as >> more scaleable approach to adding support for new events? Or if there >> were any other Event Bus frameworks that the community could recommend for >> use with JavaFX? >> >> Also, are there any plans to more directly support an Event Bus in JavaFX? >> >> >> Cheers, >> >> Mark >> From phidias51 at gmail.com Thu Oct 25 14:41:09 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 25 Oct 2012 14:41:09 -0700 Subject: JavaFX Event Bus Recommendations In-Reply-To: <68A90146-D342-4149-8427-182E3844E984@gmail.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <68A90146-D342-4149-8427-182E3844E984@gmail.com> Message-ID: Hi Dan, I'm currently looking at Guava's EventBus, and the Spring Eventing framework. Do you know of any frameworks that are well suited to JavaFX? Cheers, Mark On Thu, Oct 25, 2012 at 1:56 PM, Daniel Zwolenski wrote: > I'm on the side that says this shouldn't be in JFX and should be done via > OSS projects. > > There are many different flavours and styles to this problem and some fit > some apps/domains better than others. eg you could have a shared, app-wide > model (or tree of models) backing your views with observable properties > that you can listen to. This flavour is a kind of state-full event bus that > you can query for current state at any time and works well for full client > side apps, like an IDE or 3d model editor. It works less well with a > client-server system where your 'model' is effectively on the server. Heaps > of other options exist with pros and cons. Which one should jfx choose? > > Also, in general OSS projects will be able to adapt much faster to changes > than jre/jfx, make use of other libraries, and be easier for contributors > to get involved with (compare fxextras project to oracle fx). > > It also reduces jfx bloat (eg smaller downloads, less to port to mobile > platforms, etc) and keeps the jfx team free to focus on things that need to > be done at the platform level, like high speed graphics, 3d rendering, > media, *deployment* and cross-platform ports (like mobile). > > Everything that can be done outside of jfx should be IMO. I'd vote the > same for things like validation frameworks (and charts and FXML but too > late on those fronts). Core fx should provide lower level hook-ins (like > ways to add Node highlights which can be leveraged for validation > frameworks). > > Java is an operating system, not an application framework. That's been > part of its long term success. The app frameworks should be built on top of > it (like spring, struts, GAE, etc, etc - none of those are part of the jre > thankfully!). > > > On 26/10/2012, at 7:00 AM, Mark Fortner wrote: > > > Hi John, > > I had the same problem trying to connect to Greg's project. I've used > the > > SimpleEventBus (another google code project) before on a Swing project: > > http://code.google.com/p/simpleeventbus/ but not in JavaFX. > > > > Cheers, > > > > Mark > > > > > > > > > > On Thu, Oct 25, 2012 at 12:13 PM, John Smith >wrote: > > > >> There are a couple of forum threads on Event Buses you could read to see > >> what other people have done around this: > >> https://forums.oracle.com/forums/thread.jspa?messageID=10548299 > >> https://forums.oracle.com/forums/thread.jspa?messageID=10590312 > >> > >> One of them includes a link to a simple JavaFX implementation which Greg > >> Brown created http://code.google.com/p/sjmb/ (unfortunately the link > >> doesn't work for me as I am not authorized to view it). > >> > >> -----Original Message----- > >> From: openjfx-dev-bounces at openjdk.java.net [mailto: > >> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner > >> Sent: Thursday, October 25, 2012 11:31 AM > >> To: openjfx-dev at openjdk.java.net > >> Subject: JavaFX Event Bus Recommendations > >> > >> In my current application we're using the standard point2point eventing > >> that comes with JavaFX. To create support for a new type of event we: > >> > >> - Create an EventType class. > >> - Create an Event class > >> - Create an Event Listener interface for it. > >> - Add a mixin that makes it easier to add/remove/notify listeners. > >> > >> > >> Since there are several developers on the list who make heavy use of the > >> Spring framework, I was wondering if anyone had tried using the Spring > >> Eventing framework > >> http://blog.yohanliyanage.com/2012/09/eventing-with-spring-framework/as > >> more scaleable approach to adding support for new events? Or if there > >> were any other Event Bus frameworks that the community could recommend > for > >> use with JavaFX? > >> > >> Also, are there any plans to more directly support an Event Bus in > JavaFX? > >> > >> > >> Cheers, > >> > >> Mark > >> > From hang.vo at oracle.com Thu Oct 25 15:18:07 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 25 Oct 2012 22:18:07 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-23763 StackedBarChart does not work with autoranging category axis Message-ID: <20121025221812.C7A9C4754B@hg.openjdk.java.net> Changeset: b0f305a2d89e Author: Paru Somashekar Date: 2012-10-25 15:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b0f305a2d89e fix RT-23763 StackedBarChart does not work with autoranging category axis and unit test. ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java From hang.vo at oracle.com Thu Oct 25 15:33:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 25 Oct 2012 22:33:34 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121025223340.288E94754C@hg.openjdk.java.net> Changeset: 1089c39177ad Author: "Jasper Potts" Date: 2012-10-25 15:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1089c39177ad ConferenceScheduleApp: fixed unicode decoding in JSON parser in app. ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java Changeset: 2b0c055d14b8 Author: "Jasper Potts" Date: 2012-10-25 15:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2b0c055d14b8 ConferenceScheduleApp: fixed unicode decoding in JSON parser in app. Better fix :-) ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java From hang.vo at oracle.com Thu Oct 25 17:32:28 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 26 Oct 2012 00:32:28 +0000 Subject: hg: openjfx/8/master/rt: 7 new changesets Message-ID: <20121026003236.328A74755B@hg.openjdk.java.net> Changeset: 609ede4dbba0 Author: Morris Meyer Date: 2012-10-17 16:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/609ede4dbba0 RT-25434 - FindBugs issue ! javafx-ui-common/src/com/sun/javafx/tk/ImageLoader.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageLoader.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageLoaderFactory.java Changeset: 923b26ed6ea4 Author: kcr Date: 2012-10-19 05:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/923b26ed6ea4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 99a390cd0ec5 Author: Pavel Safrata Date: 2012-10-22 15:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/99a390cd0ec5 RT-25753: toString() of gestures reports inertia. ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java Changeset: 732db3a8f698 Author: "Jasper Potts" Date: 2012-10-22 17:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/732db3a8f698 Added com.sun API for listening to cell changes on a VirtualFlow. Also VirtualFlow performance improvements. Both by Richard Bair from JavaOne demo work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 7e671f637e68 Author: "Jasper Potts" Date: 2012-10-22 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7e671f637e68 Fixed com.sun API for listening to cell changes on a VirtualFlow, should have had getters and setters not public field. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 3a9f57c30378 Author: "Jasper Potts" Date: 2012-10-22 18:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3a9f57c30378 Added ConferenceScheduleApp that was demoed at JavaOne 2012 to new apps experiments directory + apps/experiments/ConferenceScheduleApp/build.xml + apps/experiments/ConferenceScheduleApp/manifest.mf + apps/experiments/ConferenceScheduleApp/nbproject/build-impl.xml + apps/experiments/ConferenceScheduleApp/nbproject/configs/Run_as_WebStart.properties + apps/experiments/ConferenceScheduleApp/nbproject/configs/Run_in_Browser.properties + apps/experiments/ConferenceScheduleApp/nbproject/configs/Test_Mode.properties + apps/experiments/ConferenceScheduleApp/nbproject/genfiles.properties + apps/experiments/ConferenceScheduleApp/nbproject/jfx-impl.xml + apps/experiments/ConferenceScheduleApp/nbproject/project.properties + apps/experiments/ConferenceScheduleApp/nbproject/project.xml + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/AutoLogoutLightBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/ConferenceScheduleApp.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/Page.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/PageContainer.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/PlatformIntegration.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet-Desktop.css + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet.css + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/Theme.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/TouchClickedEventAvoider.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/TouchScrollEventSynthesizer.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/AsciiBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/CheckBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/EmailBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/EventPopoverPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/LoginProgressBarSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/NoopScrollBarSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/Popover.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverTreeList.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/ResizableWrappingText.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/ScrollPaneSkin3.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SearchBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SimpleVBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SymbolBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TestPopover.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TestVirtualKeyboard.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TreeBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/VirtualKeyboard.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/VirtualKeyboardSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/DataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/SessionManagement.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/TwitterJson.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/DevoxxDataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/GetConferenceDataTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/LoginTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/TestDataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/UpdateScheduleTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/back-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/backspace-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/blue-linen.jpg + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/cancel.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/cancel at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/capslock-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/done.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/done at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/duke48.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/enter-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-popover.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-popover at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-shadow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-shadow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/ios-list-transparent.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/ios-list-transparent at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-blue-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-blue-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-gray-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-grey-button-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-red-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-red-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-background-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-background.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-strap-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-strap.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-guest-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-guest-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-login-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-login-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-title-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-title.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/need-to-be-logged-in.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/pic-shadow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/pic-shadow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-blue-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-blue-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-light-blue-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-light-blue-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-list-border.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-list-border at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow-empty.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow-empty at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/refresh-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/refresh-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/rough_diagonal.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/rough_diagonal_blue.jpg + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search-clear.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search-clear at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/shift-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/short-key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/short-key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/special-key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/special-key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/star.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tick.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tick at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bottom-fade.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble-tooth.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble-tooth at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-dot.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-dot at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-presentation.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-presentation at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-top-fade.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-dark-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-dark.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-hide.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-light-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-light.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-medium-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-medium.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Availability.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Event.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/FilterType.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Level.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Room.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Session.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/SessionTime.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/SessionType.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Speaker.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Track.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Tweet.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Venue.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/CatalogPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/FilterSessionsByTrackPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/FilterSessionsByTypePage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/LoginScreen.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SearchFilterPopoverPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SessionFilterCriteria.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SessionListPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SocialPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SpeakersPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/TimelinePage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/TracksPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/VenueRoomPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/VenuesPage.java Changeset: f536337e8dc5 Author: hudson Date: 2012-10-25 16:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f536337e8dc5 Added tag 8.0-b62 for changeset 3a9f57c30378 ! .hgtags From zonski at gmail.com Thu Oct 25 18:24:20 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 26 Oct 2012 12:24:20 +1100 Subject: JavaFX Event Bus Recommendations In-Reply-To: References: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <68A90146-D342-4149-8427-182E3844E984@gmail.com> Message-ID: Hi Mark, This is becoming more of a forum question. Briefly: I tend to use a bus very sparingly and reserve it only for notifications about changes in data (ie model object x was added/deleted/updated) to trigger redraws if needed. I don't use it for actions like 'button was clicked' because the bus can be loose around ensuring order of delivery and guaranteeing things were handled, notifying of handler failure, etc. I prefer to hook these actions into controllers via direct callbacks. As such I tend to just roll my own simple event bus as needed. The choice does come down to two things, 1. the type of app you are building and 2. personal preferences on areas such as control vs ease, etc. You look like you are doing some interesting apps so if you want to kick around general architecture ideas that may suit your needs, feel free to email me directly. On 26/10/2012, at 8:41 AM, Mark Fortner wrote: > Hi Dan, > I'm currently looking at Guava's EventBus, and the Spring Eventing framework. Do you know of any frameworks that are well suited to JavaFX? > > Cheers, > > Mark > > > > > On Thu, Oct 25, 2012 at 1:56 PM, Daniel Zwolenski wrote: > I'm on the side that says this shouldn't be in JFX and should be done via OSS projects. > > There are many different flavours and styles to this problem and some fit some apps/domains better than others. eg you could have a shared, app-wide model (or tree of models) backing your views with observable properties that you can listen to. This flavour is a kind of state-full event bus that you can query for current state at any time and works well for full client side apps, like an IDE or 3d model editor. It works less well with a client-server system where your 'model' is effectively on the server. Heaps of other options exist with pros and cons. Which one should jfx choose? > > Also, in general OSS projects will be able to adapt much faster to changes than jre/jfx, make use of other libraries, and be easier for contributors to get involved with (compare fxextras project to oracle fx). > > It also reduces jfx bloat (eg smaller downloads, less to port to mobile platforms, etc) and keeps the jfx team free to focus on things that need to be done at the platform level, like high speed graphics, 3d rendering, media, *deployment* and cross-platform ports (like mobile). > > Everything that can be done outside of jfx should be IMO. I'd vote the same for things like validation frameworks (and charts and FXML but too late on those fronts). Core fx should provide lower level hook-ins (like ways to add Node highlights which can be leveraged for validation frameworks). > > Java is an operating system, not an application framework. That's been part of its long term success. The app frameworks should be built on top of it (like spring, struts, GAE, etc, etc - none of those are part of the jre thankfully!). > > > On 26/10/2012, at 7:00 AM, Mark Fortner wrote: > > > Hi John, > > I had the same problem trying to connect to Greg's project. I've used the > > SimpleEventBus (another google code project) before on a Swing project: > > http://code.google.com/p/simpleeventbus/ but not in JavaFX. > > > > Cheers, > > > > Mark > > > > > > > > > > On Thu, Oct 25, 2012 at 12:13 PM, John Smith wrote: > > > >> There are a couple of forum threads on Event Buses you could read to see > >> what other people have done around this: > >> https://forums.oracle.com/forums/thread.jspa?messageID=10548299 > >> https://forums.oracle.com/forums/thread.jspa?messageID=10590312 > >> > >> One of them includes a link to a simple JavaFX implementation which Greg > >> Brown created http://code.google.com/p/sjmb/ (unfortunately the link > >> doesn't work for me as I am not authorized to view it). > >> > >> -----Original Message----- > >> From: openjfx-dev-bounces at openjdk.java.net [mailto: > >> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner > >> Sent: Thursday, October 25, 2012 11:31 AM > >> To: openjfx-dev at openjdk.java.net > >> Subject: JavaFX Event Bus Recommendations > >> > >> In my current application we're using the standard point2point eventing > >> that comes with JavaFX. To create support for a new type of event we: > >> > >> - Create an EventType class. > >> - Create an Event class > >> - Create an Event Listener interface for it. > >> - Add a mixin that makes it easier to add/remove/notify listeners. > >> > >> > >> Since there are several developers on the list who make heavy use of the > >> Spring framework, I was wondering if anyone had tried using the Spring > >> Eventing framework > >> http://blog.yohanliyanage.com/2012/09/eventing-with-spring-framework/ as > >> more scaleable approach to adding support for new events? Or if there > >> were any other Event Bus frameworks that the community could recommend for > >> use with JavaFX? > >> > >> Also, are there any plans to more directly support an Event Bus in JavaFX? > >> > >> > >> Cheers, > >> > >> Mark > >> > From tobi at ultramixer.com Thu Oct 25 23:22:43 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 26 Oct 2012 08:22:43 +0200 Subject: iOS button images in ConferenceScheduleApp? Message-ID: <44FCA80A-FD7F-4115-B9BD-3CEB651228C7@ultramixer.com> Hi, I found several hints to iOS on the recently open sourced "ConferenceScheduleApp"... - image: ios-list-transparent at 2x.png - names like "2x" for retina displays? - iOS buttons like "done.png" Maybe the plan on JavaOne 2012 was originally to show ConferenceScheduleApp on iPads instead of "Kiosk systems"? Best, Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com From matthieu at brouillard.fr Fri Oct 26 00:13:31 2012 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Fri, 26 Oct 2012 09:13:31 +0200 Subject: JavaFX Event Bus Recommendations In-Reply-To: References: <411E73D23DEC4C46BA48F2B6D8BF3D221602704751@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <68A90146-D342-4149-8427-182E3844E984@gmail.com> Message-ID: Mark, *> Do you know of any frameworks that are well suited to JavaFX?* In our company, we are currently using CDI even on the client side using weld-se implementation. So for us the choice is: use CDI events. Matthieu From tom.schindl at bestsolution.at Fri Oct 26 01:38:48 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 26 Oct 2012 10:38:48 +0200 Subject: RT-24088 (accepting patches from the community) Message-ID: <508A4C18.7090102@bestsolution.at> Hi, I just saw that the above ticket now has no assignee anymore. I'm not sure what this means but I have the feeling that it does not mean something good for my hope to get this API into jfx8. I'm not sure what to do. I filed the bug provided a use case and a patch still it looks like I'm not getting something as essential and trivial in. I'm eager to help fixing problems and makeing the controls API more feature rich so that I can compete with Swing/SWT and get a real replacement but if my contributions with patches are ignored in such a simple use case I won't in invest the time providing patches for more complex things. I know most people here don't like SWT but the API they have in the widgets is what is a common denominator for all operating systems and so JFX-Controls should at least have API that is available from SWT-Widgets. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From jonathan.giles at oracle.com Fri Oct 26 01:52:19 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 26 Oct 2012 21:52:19 +1300 Subject: RT-24088 (accepting patches from the community) In-Reply-To: <508A4C18.7090102@bestsolution.at> References: <508A4C18.7090102@bestsolution.at> Message-ID: <508A4F43.5060609@oracle.com> The tweak was unassigned simply because the team member that previously owned that bug has moved to another team and no longer owns the TabPane control. This will definitely have an impact on our ability to handle bugs and tweaks, but I do appreciate having these cases where patches have been provided brought to my attention. If you want I will happily work with you to review this patch and consider integrating it, but first there is a need to sign an OCA before it is possible for us to accept a patch into OpenJFX. You can find more out about that here: http://openjdk.java.net/contribute/ Thanks, -- Jonathan On 26/10/2012 9:38 p.m., Tom Schindl wrote: > Hi, > > I just saw that the above ticket now has no assignee anymore. I'm not > sure what this means but I have the feeling that it does not mean > something good for my hope to get this API into jfx8. > > I'm not sure what to do. I filed the bug provided a use case and a patch > still it looks like I'm not getting something as essential and trivial in. > > I'm eager to help fixing problems and makeing the controls API more > feature rich so that I can compete with Swing/SWT and get a real > replacement but if my contributions with patches are ignored in such a > simple use case I won't in invest the time providing patches for more > complex things. > > I know most people here don't like SWT but the API they have in the > widgets is what is a common denominator for all operating systems and so > JFX-Controls should at least have API that is available from SWT-Widgets. > > Tom > From hang.vo at oracle.com Fri Oct 26 04:18:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 26 Oct 2012 11:18:32 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121026111837.29EFF47587@hg.openjdk.java.net> Changeset: 15023603f35c Author: Martin Sladecek Date: 2012-10-26 11:58 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/15023603f35c - Node.scene not lazy - impl_computeGeomBounds used only on some transformations ! javafx-ui-common/src/javafx/scene/Node.java Changeset: a3f860f81cf8 Author: Martin Sladecek Date: 2012-10-26 13:10 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a3f860f81cf8 RT-25496 Optimize ImageView bounds ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageViewTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageView.java From peter.pilgrim at gmail.com Fri Oct 26 05:07:43 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Fri, 26 Oct 2012 13:07:43 +0100 Subject: Black Background behind MediaView Replicating 3D Movie Cube Message-ID: Hi This is nothing to do with OpenJFX codebase or anything else I was working on ScalaFX just now. Writing a port of the CubeSystem Graphic 3D with MediaView instead of Rectangles. I am using my own downloaded movie trailers e.g. The Hobbit, Prometheus, Looper, Flight etc I want to give the MediaView a black background for the videos, keep the aspect ratio, and effectively give each cube a backing rectangle, so I naively did MediaViewCubeFace(val size: Double) extends Group { val backRect: Rectangle { fill = Color.Black } val mediaView: MediaView { fitWidth = size; fitHeight = size } Group { children = Seq( backRect, mediaView) } /* ... */ } None of the above compiles, does not matter. What I found was on MacOS 10.8 Retine Display Java FX 7 update 9 there is a lot of flickering? "So I think I must be doing this wrong?" The media view rendered with the rectangle in front and sometimes behind. DepthTest is switched on. I tried setting a backRect.translateZ = -0.05 and that makes the problem worse. So there something I don't understand about 3D, can't put my finger on it. What did the JavaFX SDK team do to in the JavaOne (2011) demo? Did you put the MediaView inside a Pane or something else? -- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for financial services, London, UK JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim :: :: Skype Call peter_pilgrim :: :: http://java-champions.java.net/ :: From pavel.safrata at oracle.com Fri Oct 26 06:16:03 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Fri, 26 Oct 2012 15:16:03 +0200 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <5086FE81.8000601@oracle.com> References: <5086FE81.8000601@oracle.com> Message-ID: <508A8D13.6030808@oracle.com> Hi Steve, I have a few comments/questions. I'm not sure about the inheritance ignoring reparenting. I think that if an application will use orientation extensively it will reach a hard-to-trace "mess state" where most of the nodes "inherit" but they don't actually have the parent's value. Also it means that peforming "orientate parent" - "insert it into scene" will result in a different behavior than "insert" first and then "orientate", which seems confusing. What if I create a new node and insert it into scene, will it inherit form its new parent? In summary, I find this behavior hard to track and I think that when the value is Inherit it should always match the parent's orientation. How will mirroring cooperate with transformations? For instance user can obtain local-to-scene transformation and if the mirrorring is not contained there, the computations with the transform (such as transforming points) will be wrong. Maybe we could just introduce a public Mirror (or rather Flip) transformation and use it publicly for the mirrorring? How will it behave in 3D? Mirror nodes along X axis regardless of their z-direction volume? Shouldn't effectiveNodeOrientation be a property? It seems it might make sense to observe the value. Also our naming convention is that you should not use getSomthing unless "something" is a property. The same applies to isAutomaticallyMirrored. This method seems weird anyway. When and how often is it called? Can a node change the value dynamically? If yes, we should have a property, if not, we should make sure it doesn't - let the node call some init method in the constructor or something like that. Could you please elaborate on "the application will need to configure parameters that are appropriate for the effect in both orientations"? How do I drop the shadow to the same direction for all nodes, specifically? Thanks, Pavel On 23.10.2012 22:30, steve.x.northover at oracle.com wrote: > Hi all, > > I have been looking into Node Orientation which is an API that > controls the directionality of a Node. This is different from BIDI or > the BIDI algorithm which governs the direction of text. Node > orientation concerns the flow of visual data which is either > left-to-right or right-to-left. The best example is a tree control. > In tree control that is oriented right-to-left, the expansion arrows > point to the right and the branches of the tree expand from the right > to the left. > > https://wikis.oracle.com/display/OpenJDK/Node+Orientation+in+JavaFX > > Steve From tom.schindl at bestsolution.at Fri Oct 26 07:42:03 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 26 Oct 2012 16:42:03 +0200 Subject: Making JavaFX Development Faster In-Reply-To: <5085811A.4050103@media-interactive.de> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> Message-ID: <508AA13B.6040104@bestsolution.at> Not only the memory argument is import. What if a customer says i have to run on his j9-jvm? I can be wrong but IIRC Michael told me at JavaOne that the properties code is even using internal (sun....) stuff so even simply dropping in the jar to the j9 classpath is doomed to fail. And beside that using FX-Observables and e.g. JPA don't like each other i guess because of all those lazy list stuff, ... . Tom Am 22.10.12 19:23, schrieb Werner Lehmann: > Richard, > > On 22.10.2012 17:38, Richard Bair wrote: >> MyObject obj = new MyObject(); >> obj = BlackMagic.makeObservable(obj); > > I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) > >> However, the javafx beans package and collections and such are part >> of the "base" module -- ie: they could be separated from the rest of >> javafx and safely used on the server side or elsewhere. Why not just >> use properties and such on the server side definition of classes? Or >> are those classes being auto-generated and thus not taking observable >> properties into account? > > Currently I want to avoid requiring customers to install the FX runtime > serverside. That will be a moot point with JRE 7+. Which does not help > the 6.x customers, especially if they are on WebLogic which is usually > tied to a specific major version. > > Another aspect is the footprint regarding memory and bandwidth. > Obviously a StringProperty requires more bytes than a String. This is > not an issue (usually) when I want to display a relatively short list of > beans in the UI. It gets noticeable when the server suddenly needs +X > megabytes, the instantion of objects needs +Y ms (also affects > deserialization), and sending them over the network takes +Z ms... > > Werner -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From steve.x.northover at oracle.com Fri Oct 26 09:41:12 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 26 Oct 2012 12:41:12 -0400 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <508A8D13.6030808@oracle.com> References: <5086FE81.8000601@oracle.com> <508A8D13.6030808@oracle.com> Message-ID: <508ABD28.6080402@oracle.com> Hi Pavel! > the inheritance ignoring reparenting. I don't think this was explained well in the documentation. There should be no difference in visual behavior for the final result with respect to the ordering of "orientate" and "insert" operations. > How will mirroring cooperate with transformations? The mirroring transformation is transparent to the application and is included automatically in local-to-scene (it's a bug if it is not). A public Mirror (or rather Flip) transformation would provide API for this transformation, but I'm not sure why we would need to do this. > How will it behave in 3D? Mirror nodes along X axis regardless of their z-direction volume? I think so. > Shouldn't effectiveNodeOrientation be a property? That's a possibility. It would be a properly that changed when inherited orientation up the ancestor tree changed. Do we have any other properties like this in FX? > The same applies to isAutomaticallyMirrored. This is a mechanism that allows controls to opt out of mirroring. Conceptually, it should be "... set once in the constructor and never changed...". I am not particularly happy with this method. Do you have a better suggestion? > Could you please elaborate on "the application will need to configure parameters that are appropriate for the effect in both orientations"? For example, if you want a light source effect to come from the upper left corner when a control is RTL, you will need to create an effect where the light source comes from the upper right corner so that when the control is mirrored, it will come from the left. Steve On 26/10/2012 9:16 AM, Pavel Safrata wrote: > Hi Steve, > I have a few comments/questions. > > I'm not sure about the inheritance ignoring reparenting. I think that > if an application will use orientation extensively it will reach a > hard-to-trace "mess state" where most of the nodes "inherit" but they > don't actually have the parent's value. Also it means that peforming > "orientate parent" - "insert it into scene" will result in a different > behavior than "insert" first and then "orientate", which seems > confusing. What if I create a new node and insert it into scene, will > it inherit form its new parent? In summary, I find this behavior hard > to track and I think that when the value is Inherit it should always > match the parent's orientation. > > How will mirroring cooperate with transformations? For instance user > can obtain local-to-scene transformation and if the mirrorring is not > contained there, the computations with the transform (such as > transforming points) will be wrong. Maybe we could just introduce a > public Mirror (or rather Flip) transformation and use it publicly for > the mirrorring? > > How will it behave in 3D? Mirror nodes along X axis regardless of > their z-direction volume? > > Shouldn't effectiveNodeOrientation be a property? It seems it might > make sense to observe the value. Also our naming convention is that > you should not use getSomthing unless "something" is a property. > > The same applies to isAutomaticallyMirrored. This method seems weird > anyway. When and how often is it called? Can a node change the value > dynamically? If yes, we should have a property, if not, we should make > sure it doesn't - let the node call some init method in the > constructor or something like that. > > Could you please elaborate on "the application will need to configure > parameters that are appropriate for the effect in both orientations"? > How do I drop the shadow to the same direction for all nodes, > specifically? > > Thanks, > Pavel > > On 23.10.2012 22:30, steve.x.northover at oracle.com wrote: >> Hi all, >> >> I have been looking into Node Orientation which is an API that >> controls the directionality of a Node. This is different from BIDI >> or the BIDI algorithm which governs the direction of text. Node >> orientation concerns the flow of visual data which is either >> left-to-right or right-to-left. The best example is a tree control. >> In tree control that is oriented right-to-left, the expansion arrows >> point to the right and the branches of the tree expand from the right >> to the left. >> >> https://wikis.oracle.com/display/OpenJDK/Node+Orientation+in+JavaFX >> >> Steve > From peter.pilgrim at gmail.com Fri Oct 26 11:25:18 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Fri, 26 Oct 2012 19:25:18 +0100 Subject: Black Background behind MediaView Replicating 3D Movie Cube In-Reply-To: References: Message-ID: I just tried this same example on Windows 7 64 bit. Rendering is a lot better. In conclusion, it is not the JavaFX / ScalaFX user client code, instead there is something not correct with Z buffer ordering, so I will leave it for now .... -Dprism.printStats=true -Dprism.verbose=true WINDOWS 7 64bit ==================== Prism pipeline init order: d3d j2d Using t2k for text rasterization Using dirty region optimizations Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D native library ... succeeded. Direct3D initialization succeeded (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline Maximum supported texture size: 8192 Maximum texture size clamped to 4096 OS Information: Windows 7 build 7601 D3D Driver Information: NVIDIA GeForce GTX 570 \\.\DISPLAY1 Driver nvd3dumx.dll, version 9.18.13.697 Pixel Shader version 3.0 Device : ven_10DE, dev_1086, subsys_570B1ACC RESIZE: 13234877720276 w: 800 h: 600 D3D Statistics per last 1 frame(s) : numTrianglesDrawn=1014, numDrawCalls=507, numBufferLocks=507 numTextureLocks=0, numTextureTransferKBytes=0 numRenderTargetSwitch=2, numSetTexture=1, numSetPixelShader=3 D3D Statistics per last 1 frame(s) : numTrianglesDrawn=720, numDrawCalls=360, numBufferLocks=360 numTextureLocks=18, numTextureTransferKBytes=18225 numRenderTargetSwitch=2, numSetTexture=31, numSetPixelShader=14 D3D Statistics per last 1 frame(s) : numTrianglesDrawn=658, numDrawCalls=329, numBufferLocks=329 numTextureLocks=0, numTextureTransferKBytes=0 numRenderTargetSwitch=2, numSetTexture=31, numSetPixelShader=14 D3D Statistics per last 1 frame(s) : numTrianglesDrawn=654, numDrawCalls=327, numBufferLocks=327 numTextureLocks=3, numTextureTransferKBytes=3037 Mac OS X 10.8 =============== Prism pipeline init order: es2 j2d Using t2k for text rasterization Using dirty region optimizations Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism-es2 succeeded. GLFactory using com.sun.prism.es2.gl.mac.MacGLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline 2012-10-26 19:21:20.816 java[11029:5703] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. Graphics Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce GT 650M OpenGL Engine Version: 2.1 NVIDIA-8.0.61 Maximum supported texture size: 16384 Maximum texture size clamped to 4096 RESIZE: 1351275681714475000 w: 800 h: 600 QuantumRenderer: shutdown # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000001006bf0a9, pid=11029, tid=32783 # # JRE version: 7.0_06-b24 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.2-b09 mixed mode bsd-amd64 compressed oops) # Problematic frame: # AVF info: hasOfflineRenderer, borad-id check : true Process finished with exit code 0 On 26 October 2012 13:07, Peter Pilgrim wrote: > Hi > > This is nothing to do with OpenJFX codebase or anything else > > I was working on ScalaFX just now. Writing a port of the CubeSystem > Graphic 3D with MediaView instead of Rectangles. I am using my own > downloaded movie trailers e.g. The Hobbit, Prometheus, Looper, Flight > etc > > I want to give the MediaView a black background for the videos, keep > the aspect ratio, and effectively give each cube a backing rectangle, > so I naively did > > MediaViewCubeFace(val size: Double) extends Group { > val backRect: Rectangle { fill = Color.Black } > val mediaView: MediaView { fitWidth = size; fitHeight = size } > Group { > children = Seq( backRect, mediaView) > } > > /* ... */ > } > > None of the above compiles, does not matter. What I found was on > MacOS 10.8 Retine Display Java FX 7 update 9 there is a lot of > flickering? > "So I think I must be doing this wrong?" The media view rendered with > the rectangle in front and sometimes behind. DepthTest is switched on. > I tried setting a backRect.translateZ = -0.05 and that makes the > problem worse. So there something I don't understand about 3D, can't > put my finger on it. > > What did the JavaFX SDK team do to in the JavaOne (2011) demo? Did you > put the MediaView inside a Pane or something else? > > -- > Peter Pilgrim, > **Java Champion**, > Java EE Software Development / Design / Architect for financial > services, London, UK > > JavaFX ++ Scala ++ Groovy ++ Android ++ Java > > :: http://www.xenonique.co.uk/blog/ :: > :: http://twitter.com/peter_pilgrim :: > :: http://audio.fm/profile/peter_pilgrim :: > :: Skype Call peter_pilgrim :: > :: http://java-champions.java.net/ :: -- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for financial services, London, UK JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim :: :: Skype Call peter_pilgrim :: :: http://java-champions.java.net/ :: From danno.ferrin at shemnon.com Fri Oct 26 13:58:18 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Fri, 26 Oct 2012 14:58:18 -0600 Subject: iOS button images in ConferenceScheduleApp? In-Reply-To: <44FCA80A-FD7F-4115-B9BD-3CEB651228C7@ultramixer.com> References: <44FCA80A-FD7F-4115-B9BD-3CEB651228C7@ultramixer.com> Message-ID: There are other indicators, check the OpenJFX source for Toolkit.isIOS. The question for me is if we will get the bits behind it when the full stack of OpenJFX hits mercurial. On Fri, Oct 26, 2012 at 12:22 AM, Tobias Bley wrote: > Hi, > > I found several hints to iOS on the recently open sourced > "ConferenceScheduleApp"... > > - image: ios-list-transparent at 2x.png > - names like "2x" for retina displays? > - iOS buttons like "done.png" > > Maybe the plan on JavaOne 2012 was originally to show > ConferenceScheduleApp on iPads instead of "Kiosk systems"? > > Best, > Tobi > > > > -- > Tobias Bley > Chief Executive Officer > > -------------------------------------------------------- > > UltraMixer Digital Audio Solutions > Schillerstra?e 29 > D-01326 Dresden > Germany > > -------------------------------------------------------- > bley at ultramixer.com http://www.ultramixer.com > > > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From hang.vo at oracle.com Fri Oct 26 16:03:29 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 26 Oct 2012 23:03:29 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-24566: Resolve semantics of texture padding. Message-ID: <20121026230333.2B8BD475BF@hg.openjdk.java.net> Changeset: 3626aad4f2a5 Author: flar Date: 2012-10-26 15:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3626aad4f2a5 Fix RT-24566: Resolve semantics of texture padding. ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubFilterable.java From hang.vo at oracle.com Fri Oct 26 16:33:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 26 Oct 2012 23:33:18 +0000 Subject: hg: openjfx/8/controls/rt: fix broken test failure for CategoryAxis. Message-ID: <20121026233323.24F2B475C1@hg.openjdk.java.net> Changeset: 29364c6d7434 Author: Paru Somashekar Date: 2012-10-26 16:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/29364c6d7434 fix broken test failure for CategoryAxis. ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java From richard.bair at oracle.com Fri Oct 26 08:26:08 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 26 Oct 2012 17:26:08 +0200 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> Message-ID: We're going to open source dtjava.js and the packager in a couple days here I hope, but soon I any case. Richard On Oct 22, 2012, at 10:44 PM, Daniel Zwolenski wrote: > Similar issues (give or take) for Maven as Danno has outlined. > > More specifically, I use the classes in: > > com.sun.javafx.tools.packager.* > com.sun.javafx.tools.packager.bundlers.* > > Mostly this code just needs minor tweaks. As Danno said, things like it's not possible to turn off JNLP, and there are some assumptions about directories and the like that would ideally be configurable. > > The (native) Bundler stuff is pretty hard to work with. It's suffering a little from being an after thought I think, so not quite as clean as the rest. It may just be that I'm missing something (working it out through a decompiler is not the best way to understand someone else's code) but I struggled to customise much of the native installer steps. As well as needing changes, ideally someone writing this plugin would have docco on this, and/or be able to shoot Igor questions like "How do I set the vendor for a native installer?" and "How come when I override the app-name it throws this error?", etc. > > The other side of it is that I can't distribute this JAR (i.e. put it in a Maven repo). The old legal problem. As such, I have to use reflection for everything, which is a slow and painful way to code it. > > e.g. > > Object deployParams = newInstance(deployParamsClass); > invoke(deployParams, "setOutdir", outputDir); > invoke(deployParams, "setOutfile", appDistributionName); > invoke(deployParams, "setApplicationClass", mainClass); > > Instead of > > DeployParams params = new DeployParams(); > params.setOutdir(outDir); > params.setOutfile(appDistributionName); > params.setApplicationClass(mainClass); > > See this: https://github.com/zonski/javafx-maven-plugin/blob/master/src/main/java/com/zenjava/javafx/maven/plugin/JfxToolsWrapper.java > > Obviously makes it slower to write and harder and a disincentive to anyone wanting to develop it further. > > Simple solution, you guys put the 'tools' JAR up on a Maven repo (a "Maven Repo" is any public webserver - you do NOT need to install anything or run any processes other than an Apace, just follow a simple directory structure, ridiculously easy, done in 10 minutes). > > Alternatively, you relax the licence on this JAR and say it's ok for us plebs to put it in a Maven repo. > > The reflection works though. > > > > > > > On Tue, Oct 23, 2012 at 5:44 AM, Danno Ferrin wrote: >> Don't mean to threadjack, as I am not sure what Daniel Zwolenski may want, >> but for my Gradle plugin there are some hard coded values that get in the >> way: >> >> * The parts that decide that "package/" is the magic directory to >> look for native support files, so I can just point it at a different >> directory for package >> * The parts that decide which pieces to assemble, so I can turn off JNLP >> generation and just generate .app or .exe >> * The parts that decide the native packages should go into the 'bundles' >> directory, so I can point it somewhere else. >> * The parts that tie the need icon names in the native bundles to the app >> name, so I can always name the files"applicationIcon," "installerIcon", or >> whatever the build configures them to. >> >> I wouldn't be surprised if these were deep in the code subject to audit. >> >> On Mon, Oct 22, 2012 at 9:07 AM, Richard Bair wrote: >> >> > +1 >> > >> > Here's the basic problem I have. The deployment team is neck deep in >> > security audits & security fixes. What parts of the deployment code need to >> > be open sourced in order to make forward progress on this without waiting >> > on the deployment team? Is that a possibility, or are the changes deep in >> > deployment code? >> > >> > Thanks >> > Richard >> > >> > On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote: >> > >> > > Thanks for sharing Daniel! >> > > >> > > >> > > On 2012-10-21 06:30, Daniel Zwolenski wrote: >> > >> I have tidied up, and open sourced my JavaFX Maven plugin enough that it >> > >> builds executable JARs (equivalent to the fx:jar ant task) and native >> > >> bundles (equivalent to a subset of fx:deploy ant task): >> > >> >> > >> https://github.com/zonski/javafx-maven-plugin >> > >> >> > >> >> > >> I was waiting for the bootclasspath issue to get resolved to fix this up >> > >> properly, but since I'm getting further and further away from JFX I >> > figured >> > >> better to tidy it up and hand it over to the community. >> > >> >> > >> It does work perfectly well enough that you can use it to build real >> > >> distributables of your app via Maven. >> > >> >> > >> However it wraps only the basic JavaFX plugin features (i.e. you can't >> > >> customise many of the settings), does not support Applets (dead anyway) >> > or >> > >> JNLP (I've never had success getting JNLP to actually work with JFX). It >> > >> likely also has some platform specific bugs and problems, since I have >> > >> tested only on Windows and building MSI's. >> > >> >> > >> It would be relatively trivial (but time consuming) to extend it >> > further. >> > >> The code is simple but inelegant. Great improvements could be made if >> > the >> > >> JFX deployment team were to make some minor changes to their packaging >> > API >> > >> to make it easier to integrate with. And massive clean-ups could be >> > made if >> > >> they put their tools JAR in a Maven repo that they maintained. >> > >> >> > >> I don't have any intention to develop this further or maintain it. It >> > is a >> > >> good base but it would be up to someone from the community to do this if >> > >> they want it to do anything more than it does. >> > >> >> > >> Note this plugin is to address the packaging/assembly issue. It does NOT >> > >> solve the getting-jfx-on-the-classpath-issue. You still need to do >> > whatever >> > >> workaround you're doing now on that front. >> > > >> > >> > >> >> >> -- >> There is nothing that will hold me back. I know who I am.... >> I remember wher I came from, and I feel stronger for knowing. >> Zane, Ninja of Ice. Ninjago S01E07 > From richard.bair at oracle.com Fri Oct 26 08:18:55 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 26 Oct 2012 17:18:55 +0200 Subject: Font Metrics (was TextField Document model) In-Reply-To: <936EB4EA-9324-4408-9F93-FB6361CF9676@gmail.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <7D3F7E98-7133-45CE-BEAD-0E7E47A777AF@oracle.com> <936EB4EA-9324-4408-9F93-FB6361CF9676@gmail.com> Message-ID: I think these are two distinct issues -- font metrics and locating glyph bounds within a string of text. FontMetrics I think is fairly straightforward -- Felipe what do you think? For the other use case, actually knowing the glyph bounds is not enough (probably). The problem is, suppose that text you were looking for wrapped from one line to the next (letter wrapping instead of word wrapping, or maybe you were searching for a phrase rather than just a word). In this case you need to know the shape that would encompassing text from both lines (think: blue selection box). Even more challenging is BIDI and ligatures -- what if the text you searched for was only using part of a glyph due to ligatures? Or you have disjoint shape due to BIDI (selection is a good example of this again). Now, internally we use an impl on Text to get the shape based on a range of indexes into the Text, and this shape is then used to draw selection. In our quest to get rid of impl methods, I have wanted to see this get proper API treatment. Maybe we would have a TextMeasurement class, and Text node (and TextFlow) would return an instance of it and we could have a method on it that vends a shape. Once you have a shape you can set the fill, stroke, etc as you like. Richard On Oct 22, 2012, at 8:21 PM, Scott Palmer wrote: > While we are talking about the text controls. I would like to request access to either the FontMetrics or a way to accurately position things based on a position in the text without having to implement a Skin. E.g. an auto-complete popup, or something like what OS X does when you look up a definition of a word. > > Like this: > > (heck, even it got it off by a pixel vertically) > > Or perhaps the may to do this is covered in the goal to make Skins a bit more "public". I think I read that was a goal somewhere. > > I recently implemented something like an auto-complete popup and to do it well I needed to set the skin on the TextField to my own subclass of TextFieldSkin just to expose the fontMetrics. It worked out, but I felt dirty doing it :-) and I didn't properly account for various insets etc. > > I'm guessing that a Time/Date field and others would benefit from popups like a calendar, etc. Maybe this is off-topic and it really should be done by implementing a custom Skin? > > > Regards, > > Scott > > > > > On 2012-10-22, at 11:47 AM, Richard Bair wrote: > >>> Would you consider having a setContent(TextFieldDocument doc) method in >>> TextField? The length() method and the get(int, int) method could be >>> final, making it necessary to call super.insert() or super.delete() to get >>> anything done. This would provide the flexibility (likely all the >>> flexibility) and yet would prevent a developer from making a fairly large >>> set of mistakes. >> >> That is a very interesting proposal as well. >> >> Why don't we list the types of text input control scenario's we're interested in (the force all caps case is one I wouldn't have thought of, I'm sure you've seen tons of others in your time developing apps). Once we've got something of a comprehensive list, I think a clear solution that weighs the pros / cons will become more obvious to us. >> >> Richard > From richard.bair at oracle.com Fri Oct 26 08:10:52 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 26 Oct 2012 17:10:52 +0200 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> Message-ID: <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> > Suggestion 2: (possibility) > public interface ContentFilter > public void onDelete(Content content, TextInputControl control, int > start, int end, boolean notifyListeners) { > .... > } > public void onInsert(Content content, TextInputControl control, int > index, String s, boolean notifyListeners) { > .... > } > } > > I added the TextInputControl to the list of parameters so that cursor > manipulation could be done. The above specification would also require the > user to call content.delete() and content.insert() for anything to be > changed. I thought about using boolean return values to signify whether or > not the input was already handled or not, but that would just force a user > to know how to used the booleans. This seemed nicer to me. > > This would allow I lot of power. > * It has the safety of calling the insert and delete models on the rigorous > implementation of Content > * Allows the content to be replaced (if appropriate) at each event. > * Allows for the Content variable to be final This is starting to feel right to me. However, instead of using a 2-method interface (or abstract class), if we break it into two interfaces, then it becomes lambda friendly. Although there is a distinct disadvantage to breaking it up. Having the two methods together means you could have a library of pre built filters, for handling a range of things. And interface or abstract class? Typically we always reach for an abstract class in cases like this because we can extend the class in the future. Now that Java 8 is introducing default methods, we do have another way to extend the API in the future. I am reluctant to rely on it yet though because it is an unproven tool for API design (ie: I don't know the gotchas yet). So suppose we make this thing an abstract class with two methods (for now?) for handling both the delete & add cases. I would modify the implementation though, so that the add case returns the string to insert at the given location (null meaning to reject), and delete returning true / false? By default. The onInsert would return the input string, and onDelete would return true (so you could implement only one of the methods of you wanted to). My reasoning for this is that it makes the implementation and semantics simple. Any time the implementation would mutate the content it first checks the filter and then either stops modification or continues (in the case of insert, with the new string). I need to look at the implementation, but I think the places where we modify the text (and would insert checks to the filter) are also the places we move the caret / selection, so they could take into account the filtered text. What is the purpose of "notifyListeners"? Richard From richard.bair at oracle.com Fri Oct 26 06:46:59 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 26 Oct 2012 15:46:59 +0200 Subject: Making JavaFX Development Faster In-Reply-To: <5085811A.4050103@media-interactive.de> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> Message-ID: <4D4A47AF-5BDF-4632-8B64-88D96C4EFC4F@oracle.com> > On 22.10.2012 17:38, Richard Bair wrote: >> MyObject obj = new MyObject(); >> obj = BlackMagic.makeObservable(obj); > > I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) I'm thinking basic byte code rewriting. I can't remember the name of the project off the top of my head, but I think it is an apache project. Somebody help me out :-) >> However, the javafx beans package and collections and such are part >> of the "base" module -- ie: they could be separated from the rest of >> javafx and safely used on the server side or elsewhere. Why not just >> use properties and such on the server side definition of classes? Or >> are those classes being auto-generated and thus not taking observable >> properties into account? > > Currently I want to avoid requiring customers to install the FX runtime serverside. That will be a moot point with JRE 7+. Which does not help the 6.x customers, especially if they are on WebLogic which is usually tied to a specific major version. > > Another aspect is the footprint regarding memory and bandwidth. Obviously a StringProperty requires more bytes than a String. This is not an issue (usually) when I want to display a relatively short list of beans in the UI. It gets noticeable when the server suddenly needs +X megabytes, the instantion of objects needs +Y ms (also affects deserialization), and sending them over the network takes +Z ms... If only we had properties in the language!! Goetz, I'm looking at you :-) There are some other options in how you define your properties though. For example, the property object can be created lazily, such that on the server side you don't ever instantiate it. Having properties in the language makes it so that it can do this sort of optimization for free, whereas you'd have to write the boilerplate (or use black magic). Richard From richard.bair at oracle.com Fri Oct 26 08:22:24 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 26 Oct 2012 17:22:24 +0200 Subject: MenuButton arrow position In-Reply-To: <50867918.5060403@media-interactive.de> References: <50867918.5060403@media-interactive.de> Message-ID: It sounds very much like a bug to me :-(. Would you mi no filing the issue? Paru, do you recall seeing this issue? On Oct 23, 2012, at 1:01 PM, Werner Lehmann wrote: > Hi, > > MenuButton does not play nice if the graphic is displayed TOP or BOTTOM: http://www.imagebam.com/image/8c4a8b216588054 > > Usually the arrow button is located to the right of the button text. Instead it is on the far right side, with too much gap in between. Should this be treated as a bug, or is this on purpose? Also, is there a workaround to move the arrow to the "right" position? Thanks. > > Werner From richard.bair at oracle.com Fri Oct 26 06:39:38 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 26 Oct 2012 15:39:38 +0200 Subject: Making JavaFX Development Faster In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> Message-ID: <0FCDEA84-6061-4E3F-8845-57D3F190805F@oracle.com> Milan, Can you take a look at the patch? Greg has recently left (although I'm hoping he is still on the forums / mailing list!), and Milan is taking over responsibility for FXML. He'll probably need a bit to get up to speed. But do bug him to look at the issue again :-) Richard On Oct 22, 2012, at 5:08 PM, Danno Ferrin wrote: > The controller doesn't map too well. We would need to write something > custom to stand up the MVC Group in context of a FXML and inject into the > FXML the controller, which is not always were the listeners live. My > perspective is that the controller in FXML is more of a ViewModel from the > MVVM pattern than a logic controller, which is what Griffon leans it's > Controllers towards. It's not hard and fast, you can make either do the > other approach, but structurally it biases the code in that direction. > > That being said, I do have a bug sitting in limbo ( > http://javafx-jira.kenai.com/browse/RT-25559 - with a patch!) that would > allow for easier integration of FXML into typical Griffon MV Groups. > > On Sun, Oct 21, 2012 at 11:16 AM, Mark Fortner wrote: > >> The article that Will pointed out was interesting. However, the developer >> would still end up having to write code to make their POJOs or POJO >> collections observable. It would be nice if there was a "dynamic proxy" >> that automagically made any class you sent it observable. Not sure how >> doable that is -- just thinking off the top of my head. >> >> The one thing that you would need to avoid is making your POJO have any >> JavaFX dependencies. >> >> On the issue of RAD tooling, it sounds like the Griffon team is making some >> progress with respect to making JavaFX easier. I'm not sure how well >> Griffon's Service and Controller interfaces map to JavaFX's Controller. >> >> Cheers, >> >> Mark >> >> >> >> >> On Thu, Oct 18, 2012 at 11:21 AM, Richard Bair >> wrote: >> >>> Another option I would guess is to not use observable objects at all, but >>> you can still use binding (the property adapters should work with that). >>> Even with a list view, which has an ObservableList, you can add items >> form >>> a normal list and vice versa. >>> >>> On Oct 18, 2012, at 10:39 AM, Mark Fortner wrote: >>> >>>> One of the big timewasters when it comes to JavaFX projects taking your >>>> server-side POJOs, creating Observable versions of them, and creating >>>> forms, and controllers for them. If you've been doing JEE development >> in >>>> the past 5 years then you're probably already using Spring ROO, Grails, >>> or >>>> some other RAD tooling that makes this type of work trivial in the web >>>> world. All of these artifacts are usually generated directly from the >>>> POJOs. >>>> >>>> So I'm curious if anyone knows of any tools that make that process >> easier >>>> and faster? >>>> >>>> >>>> Cheers, >>>> >>>> Mark >>> >>> >> > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 From swpalmer at gmail.com Fri Oct 26 20:18:26 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 26 Oct 2012 23:18:26 -0400 Subject: TextField Document model In-Reply-To: <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> Message-ID: <527B2117-D44E-4770-99BF-332CDF8E07C1@gmail.com> On 2012-10-26, at 11:10 AM, Richard Bair wrote: > >> Suggestion 2: (possibility) >> public interface ContentFilter >> public void onDelete(Content content, TextInputControl control, int >> start, int end, boolean notifyListeners) { >> .... >> } >> public void onInsert(Content content, TextInputControl control, int >> index, String s, boolean notifyListeners) { >> .... >> } >> } >> >> I added the TextInputControl to the list of parameters so that cursor >> manipulation could be done. The above specification would also require the >> user to call content.delete() and content.insert() for anything to be >> changed. I thought about using boolean return values to signify whether or >> not the input was already handled or not, but that would just force a user >> to know how to used the booleans. This seemed nicer to me. >> >> This would allow I lot of power. >> * It has the safety of calling the insert and delete models on the rigorous >> implementation of Content >> * Allows the content to be replaced (if appropriate) at each event. >> * Allows for the Content variable to be final > > This is starting to feel right to me. However, instead of using a 2-method interface (or abstract class), if we break it into two interfaces, then it becomes lambda friendly. Although there is a distinct disadvantage to breaking it up. Having the two methods together means you could have a library of pre built filters, for handling a range of things. You could make an interface that implements both of the single method interfaces. I'm not sure if that helps any as it might not work well for the lambda stuff. > And interface or abstract class? Typically we always reach for an abstract class in cases like this because we can extend the class in the future. Now that Java 8 is introducing default methods, we do have another way to extend the API in the future. I am reluctant to rely on it yet though because it is an unproven tool for API design (ie: I don't know the gotchas yet). > > So suppose we make this thing an abstract class with two methods (for now?) for handling both the delete & add cases. I would modify the implementation though, so that the add case returns the string to insert at the given location (null meaning to reject), and delete returning true / false? By default. The onInsert would return the input string, and onDelete would return true (so you could implement only one of the methods of you wanted to). > > My reasoning for this is that it makes the implementation and semantics simple. Any time the implementation would mutate the content it first checks the filter and then either stops modification or continues (in the case of insert, with the new string). I think in the case of Delete it is important to allow for modification of what us to be deleted. What if the selected range contains a part that is not allowed to be deleted in your customized control? Imagine a field for a (North American) phone number that you wanted to always show as (###) ###-####. When selecting parts and hitting delete you don't want the delimiters to be deleted, just the digits. It may not be the best example, but allowing the range to be modified or even split into multiple ranges would be far more powerful. Just return an empty set of ranges and nothing gets deleted... It is more similar to how you propose the Insert filter to work... Actually it brings up the same issue for insert. If I paste a few characters I may actually want to force an overwrite of some of the text that is already there. Such that if I paste 1234567890 into my phone number example the field ends up with (123) 456-7890. Just having Index and String parameters is not enough if we want some of the current text to be replaced. Accounting for caret position and skipping fixed characters in the text can already be done fairly easily with what we have, so I'm not worried about that. I want to keep it simple, without making certain things impossible. Scott From markclaassenx at gmail.com Fri Oct 26 22:28:54 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Sat, 27 Oct 2012 01:28:54 -0400 Subject: TextField Document model In-Reply-To: <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> Message-ID: Thanks. I plan to work on it this weekend. We will see what happens! On Oct 26, 2012 10:51 PM, "Richard Bair" wrote: > > > Suggestion 2: (possibility) > > public interface ContentFilter > > public void onDelete(Content content, TextInputControl control, int > > start, int end, boolean notifyListeners) { > > .... > > } > > public void onInsert(Content content, TextInputControl control, int > > index, String s, boolean notifyListeners) { > > .... > > } > > } > > > > I added the TextInputControl to the list of parameters so that cursor > > manipulation could be done. The above specification would also require > the > > user to call content.delete() and content.insert() for anything to be > > changed. I thought about using boolean return values to signify whether > or > > not the input was already handled or not, but that would just force a > user > > to know how to used the booleans. This seemed nicer to me. > > > > This would allow I lot of power. > > * It has the safety of calling the insert and delete models on the > rigorous > > implementation of Content > > * Allows the content to be replaced (if appropriate) at each event. > > * Allows for the Content variable to be final > > This is starting to feel right to me. However, instead of using a 2-method > interface (or abstract class), if we break it into two interfaces, then it > becomes lambda friendly. Although there is a distinct disadvantage to > breaking it up. Having the two methods together means you could have a > library of pre built filters, for handling a range of things. > > And interface or abstract class? Typically we always reach for an abstract > class in cases like this because we can extend the class in the future. Now > that Java 8 is introducing default methods, we do have another way to > extend the API in the future. I am reluctant to rely on it yet though > because it is an unproven tool for API design (ie: I don't know the gotchas > yet). > > So suppose we make this thing an abstract class with two methods (for > now?) for handling both the delete & add cases. I would modify the > implementation though, so that the add case returns the string to insert at > the given location (null meaning to reject), and delete returning true / > false? By default. The onInsert would return the input string, and onDelete > would return true (so you could implement only one of the methods of you > wanted to). > > My reasoning for this is that it makes the implementation and semantics > simple. Any time the implementation would mutate the content it first > checks the filter and then either stops modification or continues (in the > case of insert, with the new string). > > I need to look at the implementation, but I think the places where we > modify the text (and would insert checks to the filter) are also the places > we move the caret / selection, so they could take into account the filtered > text. > > What is the purpose of "notifyListeners"? > > Richard From richard.bair at oracle.com Sat Oct 27 06:24:59 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 27 Oct 2012 06:24:59 -0700 Subject: Making JavaFX Development Faster In-Reply-To: <508AA13B.6040104@bestsolution.at> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> Message-ID: <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> I cannot imagine what internal stuff Michael could be using or when that was added. On Oct 26, 2012, at 7:42 AM, Tom Schindl wrote: > Not only the memory argument is import. > > What if a customer says i have to run on his j9-jvm? > > I can be wrong but IIRC Michael told me at JavaOne that the properties > code is even using internal (sun....) stuff so even simply dropping in > the jar to the j9 classpath is doomed to fail. > > And beside that using FX-Observables and e.g. JPA don't like each other > i guess because of all those lazy list stuff, ... . > > Tom > > Am 22.10.12 19:23, schrieb Werner Lehmann: >> Richard, >> >> On 22.10.2012 17:38, Richard Bair wrote: >>> MyObject obj = new MyObject(); >>> obj = BlackMagic.makeObservable(obj); >> >> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >> >>> However, the javafx beans package and collections and such are part >>> of the "base" module -- ie: they could be separated from the rest of >>> javafx and safely used on the server side or elsewhere. Why not just >>> use properties and such on the server side definition of classes? Or >>> are those classes being auto-generated and thus not taking observable >>> properties into account? >> >> Currently I want to avoid requiring customers to install the FX runtime >> serverside. That will be a moot point with JRE 7+. Which does not help >> the 6.x customers, especially if they are on WebLogic which is usually >> tied to a specific major version. >> >> Another aspect is the footprint regarding memory and bandwidth. >> Obviously a StringProperty requires more bytes than a String. This is >> not an issue (usually) when I want to display a relatively short list of >> beans in the UI. It gets noticeable when the server suddenly needs +X >> megabytes, the instantion of objects needs +Y ms (also affects >> deserialization), and sending them over the network takes +Z ms... >> >> Werner > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Sat Oct 27 06:55:18 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 27 Oct 2012 15:55:18 +0200 Subject: Making JavaFX Development Faster In-Reply-To: <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> Message-ID: <508BE7C6.3010103@bestsolution.at> If I remember correctly it had to do with listeners and how to manage that they are not leaked but I could be wrong. Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, am I right? I generally think using JavaFX-Beans on the server side is a bad idea. Tom Am 27.10.12 15:24, schrieb Richard Bair: > I cannot imagine what internal stuff Michael could be using or when that was added. > > On Oct 26, 2012, at 7:42 AM, Tom Schindl wrote: > >> Not only the memory argument is import. >> >> What if a customer says i have to run on his j9-jvm? >> >> I can be wrong but IIRC Michael told me at JavaOne that the properties >> code is even using internal (sun....) stuff so even simply dropping in >> the jar to the j9 classpath is doomed to fail. >> >> And beside that using FX-Observables and e.g. JPA don't like each other >> i guess because of all those lazy list stuff, ... . >> >> Tom >> >> Am 22.10.12 19:23, schrieb Werner Lehmann: >>> Richard, >>> >>> On 22.10.2012 17:38, Richard Bair wrote: >>>> MyObject obj = new MyObject(); >>>> obj = BlackMagic.makeObservable(obj); >>> >>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>> >>>> However, the javafx beans package and collections and such are part >>>> of the "base" module -- ie: they could be separated from the rest of >>>> javafx and safely used on the server side or elsewhere. Why not just >>>> use properties and such on the server side definition of classes? Or >>>> are those classes being auto-generated and thus not taking observable >>>> properties into account? >>> >>> Currently I want to avoid requiring customers to install the FX runtime >>> serverside. That will be a moot point with JRE 7+. Which does not help >>> the 6.x customers, especially if they are on WebLogic which is usually >>> tied to a specific major version. >>> >>> Another aspect is the footprint regarding memory and bandwidth. >>> Obviously a StringProperty requires more bytes than a String. This is >>> not an issue (usually) when I want to display a relatively short list of >>> beans in the UI. It gets noticeable when the server suddenly needs +X >>> megabytes, the instantion of objects needs +Y ms (also affects >>> deserialization), and sending them over the network takes +Z ms... >>> >>> Werner >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Sat Oct 27 07:01:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 27 Oct 2012 07:01:15 -0700 Subject: Making JavaFX Development Faster In-Reply-To: <508BE7C6.3010103@bestsolution.at> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> Message-ID: <2CA5CD7F-45A8-4F16-8BFE-064379CBB747@oracle.com> It is true we've done no testing on other VM's so there cannot be a guarantee in that regard. On Oct 27, 2012, at 6:55 AM, Tom Schindl wrote: > If I remember correctly it had to do with listeners and how to manage > that they are not leaked but I could be wrong. > > Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, > am I right? I generally think using JavaFX-Beans on the server side is a > bad idea. > > Tom > > Am 27.10.12 15:24, schrieb Richard Bair: >> I cannot imagine what internal stuff Michael could be using or when that was added. >> >> On Oct 26, 2012, at 7:42 AM, Tom Schindl wrote: >> >>> Not only the memory argument is import. >>> >>> What if a customer says i have to run on his j9-jvm? >>> >>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>> code is even using internal (sun....) stuff so even simply dropping in >>> the jar to the j9 classpath is doomed to fail. >>> >>> And beside that using FX-Observables and e.g. JPA don't like each other >>> i guess because of all those lazy list stuff, ... . >>> >>> Tom >>> >>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>> Richard, >>>> >>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>> MyObject obj = new MyObject(); >>>>> obj = BlackMagic.makeObservable(obj); >>>> >>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>> >>>>> However, the javafx beans package and collections and such are part >>>>> of the "base" module -- ie: they could be separated from the rest of >>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>> use properties and such on the server side definition of classes? Or >>>>> are those classes being auto-generated and thus not taking observable >>>>> properties into account? >>>> >>>> Currently I want to avoid requiring customers to install the FX runtime >>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>> the 6.x customers, especially if they are on WebLogic which is usually >>>> tied to a specific major version. >>>> >>>> Another aspect is the footprint regarding memory and bandwidth. >>>> Obviously a StringProperty requires more bytes than a String. This is >>>> not an issue (usually) when I want to display a relatively short list of >>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>> megabytes, the instantion of objects needs +Y ms (also affects >>>> deserialization), and sending them over the network takes +Z ms... >>>> >>>> Werner >>> >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Sat Oct 27 07:29:50 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 27 Oct 2012 16:29:50 +0200 Subject: Making JavaFX Development Faster In-Reply-To: <508BE7C6.3010103@bestsolution.at> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> Message-ID: <508BEFDE.6090602@tbee.org> About using JavaFX beans server side; can you explain why that would be a bad idea beside the fact that there isn't any support in frames like JDBC? There has been a big demand from the community for real properties in Java. Now JavaFX has become part of the standard JDK, I expect people to start using these properties in other area's as well. The binding concept is rather powerful and once the concept sinks in... This then would have consequences; some bindings no longer can be lazy, we need bean level listeners, etc. But this can all be added quite easily. Then JDBC and JPA need to be enhanced to support them and we're pretty much done. Tom On 2012-10-27 15:55, Tom Schindl wrote: > If I remember correctly it had to do with listeners and how to manage > that they are not leaked but I could be wrong. > > Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, > am I right? I generally think using JavaFX-Beans on the server side is a > bad idea. > > Tom > > Am 27.10.12 15:24, schrieb Richard Bair: >> I cannot imagine what internal stuff Michael could be using or when that was added. >> >> On Oct 26, 2012, at 7:42 AM, Tom Schindl wrote: >> >>> Not only the memory argument is import. >>> >>> What if a customer says i have to run on his j9-jvm? >>> >>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>> code is even using internal (sun....) stuff so even simply dropping in >>> the jar to the j9 classpath is doomed to fail. >>> >>> And beside that using FX-Observables and e.g. JPA don't like each other >>> i guess because of all those lazy list stuff, ... . >>> >>> Tom >>> >>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>> Richard, >>>> >>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>> MyObject obj = new MyObject(); >>>>> obj = BlackMagic.makeObservable(obj); >>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>> >>>>> However, the javafx beans package and collections and such are part >>>>> of the "base" module -- ie: they could be separated from the rest of >>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>> use properties and such on the server side definition of classes? Or >>>>> are those classes being auto-generated and thus not taking observable >>>>> properties into account? >>>> Currently I want to avoid requiring customers to install the FX runtime >>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>> the 6.x customers, especially if they are on WebLogic which is usually >>>> tied to a specific major version. >>>> >>>> Another aspect is the footprint regarding memory and bandwidth. >>>> Obviously a StringProperty requires more bytes than a String. This is >>>> not an issue (usually) when I want to display a relatively short list of >>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>> megabytes, the instantion of objects needs +Y ms (also affects >>>> deserialization), and sending them over the network takes +Z ms... >>>> >>>> Werner >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 > From tbee at tbee.org Sat Oct 27 07:57:05 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 27 Oct 2012 16:57:05 +0200 Subject: bound SVG Message-ID: <508BF641.2040408@tbee.org> I'm trying to modify the JavaFX conference demo application in order to demonstrate CSS styling on Wednesday's JFall. I find that a lot of the stuff is hardcoded and not easily skinnable, so I'm trying to make some pinpoint changes in order to improve this. Since my attempt is to make it more "metro" (simple straight colored rectangles is about all that my design skills can handle) I'm trying to move some of the drawing instructions out into CSS using SVG. However, some of the nodes have dynamic dimensions (width or height), and I would like to have my SVG instructions scale with that. So instead of: M0,0 L10,0 L10,10 L0,10 L0,0 Z I would like to use something like: M0,0 L{width},0 L{width},10 L0,10 L0,0 Z Is this possible? Or only by using some kind of template engine and reloading the CSS? Tom From swpalmer at gmail.com Sat Oct 27 09:07:56 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 27 Oct 2012 12:07:56 -0400 Subject: bound SVG In-Reply-To: <508BF641.2040408@tbee.org> References: <508BF641.2040408@tbee.org> Message-ID: -fx-scale-shape Scott On 2012-10-27, at 10:57 AM, Tom Eugelink wrote: > I'm trying to modify the JavaFX conference demo application in order to demonstrate CSS styling on Wednesday's JFall. I find that a lot of the stuff is hardcoded and not easily skinnable, so I'm trying to make some pinpoint changes in order to improve this. > > Since my attempt is to make it more "metro" (simple straight colored rectangles is about all that my design skills can handle) I'm trying to move some of the drawing instructions out into CSS using SVG. However, some of the nodes have dynamic dimensions (width or height), and I would like to have my SVG instructions scale with that. > > So instead of: M0,0 L10,0 L10,10 L0,10 L0,0 Z > > I would like to use something like: M0,0 L{width},0 L{width},10 L0,10 L0,0 Z > > Is this possible? Or only by using some kind of template engine and reloading the CSS? > > Tom > From tom.schindl at bestsolution.at Sat Oct 27 09:28:40 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 27 Oct 2012 18:28:40 +0200 Subject: Making JavaFX Development Faster In-Reply-To: <508BEFDE.6090602@tbee.org> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> Message-ID: <508C0BB8.2000204@bestsolution.at> Hi, I really like JavaFX properties but their concept really only makes sense on the client. Main points: * They waste memory * are not supported on all JVM (people tend to forget that javafx is not JSRed and only part of openjdk/oracle jdk). On memory: ---------- We can talk about laziness as much as we want but when reading a bean from the database 95% of the fields are none null, hence lazy creation is a nightmare. In my opinion VM properties are very different to what we have in JavaFX. On standard: ------------ As outlined and confirmed by Richard, Oracle does not guarantee that things work on all JVMs (e.g. j9) it might or might not work and can be broken any time. JavaFX will be JSRed by Java9 not sure if vendors are forced to implement the started. When you state other JSRed technologies should adapt to the JavaFX bean standard the they can before Java9. General statement: ------------------ I'm not even sure why people have such a big problem with using a different object on the server (Plain POJO) and Java(FX)-Bean on the client, writing POJOs by hand is a boring and senseless task using some meta format or tool and generate the POJOs and JavaFX-Beans out of that is not rocket sience. Tom Am 27.10.12 16:29, schrieb Tom Eugelink: > About using JavaFX beans server side; can you explain why that would be > a bad idea beside the fact that there isn't any support in frames like > JDBC? > > There has been a big demand from the community for real properties in > Java. Now JavaFX has become part of the standard JDK, I expect people to > start using these properties in other area's as well. The binding > concept is rather powerful and once the concept sinks in... This then > would have consequences; some bindings no longer can be lazy, we need > bean level listeners, etc. But this can all be added quite easily. Then > JDBC and JPA need to be enhanced to support them and we're pretty much > done. > > Tom > > > On 2012-10-27 15:55, Tom Schindl wrote: >> If I remember correctly it had to do with listeners and how to manage >> that they are not leaked but I could be wrong. >> >> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, >> am I right? I generally think using JavaFX-Beans on the server side is a >> bad idea. >> >> Tom >> >> Am 27.10.12 15:24, schrieb Richard Bair: >>> I cannot imagine what internal stuff Michael could be using or when >>> that was added. >>> >>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>> wrote: >>> >>>> Not only the memory argument is import. >>>> >>>> What if a customer says i have to run on his j9-jvm? >>>> >>>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>>> code is even using internal (sun....) stuff so even simply dropping in >>>> the jar to the j9 classpath is doomed to fail. >>>> >>>> And beside that using FX-Observables and e.g. JPA don't like each other >>>> i guess because of all those lazy list stuff, ... . >>>> >>>> Tom >>>> >>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>> Richard, >>>>> >>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>> MyObject obj = new MyObject(); >>>>>> obj = BlackMagic.makeObservable(obj); >>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>>> >>>>>> However, the javafx beans package and collections and such are part >>>>>> of the "base" module -- ie: they could be separated from the rest of >>>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>>> use properties and such on the server side definition of classes? Or >>>>>> are those classes being auto-generated and thus not taking observable >>>>>> properties into account? >>>>> Currently I want to avoid requiring customers to install the FX >>>>> runtime >>>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>>> the 6.x customers, especially if they are on WebLogic which is usually >>>>> tied to a specific major version. >>>>> >>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>> Obviously a StringProperty requires more bytes than a String. This is >>>>> not an issue (usually) when I want to display a relatively short >>>>> list of >>>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>>> megabytes, the instantion of objects needs +Y ms (also affects >>>>> deserialization), and sending them over the network takes +Z ms... >>>>> >>>>> Werner >>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>> GmbH >>>> ------------------------------------------------------------------------ >>>> >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>> 935833 >>>> http://www.BestSolution.at phone ++43 512 >>>> 935834 >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Sat Oct 27 10:17:03 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 27 Oct 2012 19:17:03 +0200 Subject: bound SVG In-Reply-To: References: <508BF641.2040408@tbee.org> Message-ID: <508C170F.5020808@tbee.org> Hm. Yes. But that is not what I need to get what I want; it would also scale the width proportionally. I think I'm aiming too high; like with HTML you do need some hooks to hang the styling on. Tom On 2012-10-27 18:07, Scott Palmer wrote: > -fx-scale-shape > > Scott > > On 2012-10-27, at 10:57 AM, Tom Eugelink wrote: > >> I'm trying to modify the JavaFX conference demo application in order to demonstrate CSS styling on Wednesday's JFall. I find that a lot of the stuff is hardcoded and not easily skinnable, so I'm trying to make some pinpoint changes in order to improve this. >> >> Since my attempt is to make it more "metro" (simple straight colored rectangles is about all that my design skills can handle) I'm trying to move some of the drawing instructions out into CSS using SVG. However, some of the nodes have dynamic dimensions (width or height), and I would like to have my SVG instructions scale with that. >> >> So instead of: M0,0 L10,0 L10,10 L0,10 L0,0 Z >> >> I would like to use something like: M0,0 L{width},0 L{width},10 L0,10 L0,0 Z >> >> Is this possible? Or only by using some kind of template engine and reloading the CSS? >> >> Tom >> From swpalmer at gmail.com Sat Oct 27 12:30:53 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 27 Oct 2012 15:30:53 -0400 Subject: bound SVG In-Reply-To: <508C170F.5020808@tbee.org> References: <508BF641.2040408@tbee.org> <508C170F.5020808@tbee.org> Message-ID: Ah, I see what you are doing now. But if you really Bly have simple rectangles, why do you need SVG at all? Can't you accomplish what you are after with multiple backgrounds and borders? Scott On 2012-10-27, at 1:17 PM, Tom Eugelink wrote: > Hm. Yes. But that is not what I need to get what I want; it would also scale the width proportionally. I think I'm aiming too high; like with HTML you do need some hooks to hang the styling on. > > Tom > > > > > On 2012-10-27 18:07, Scott Palmer wrote: >> -fx-scale-shape >> >> Scott >> >> On 2012-10-27, at 10:57 AM, Tom Eugelink wrote: >> >>> I'm trying to modify the JavaFX conference demo application in order to demonstrate CSS styling on Wednesday's JFall. I find that a lot of the stuff is hardcoded and not easily skinnable, so I'm trying to make some pinpoint changes in order to improve this. >>> >>> Since my attempt is to make it more "metro" (simple straight colored rectangles is about all that my design skills can handle) I'm trying to move some of the drawing instructions out into CSS using SVG. However, some of the nodes have dynamic dimensions (width or height), and I would like to have my SVG instructions scale with that. >>> >>> So instead of: M0,0 L10,0 L10,10 L0,10 L0,0 Z >>> >>> I would like to use something like: M0,0 L{width},0 L{width},10 L0,10 L0,0 Z >>> >>> Is this possible? Or only by using some kind of template engine and reloading the CSS? >>> >>> Tom >>> > From tbee at tbee.org Sat Oct 27 13:14:00 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 27 Oct 2012 22:14:00 +0200 Subject: bound SVG In-Reply-To: References: <508BF641.2040408@tbee.org> <508C170F.5020808@tbee.org> Message-ID: <508C4088.5020506@tbee.org> I hoped to be able to switch from a bar to a full rectangle by just using CSS, but I can't set the width in CSS. I could use two rectangles, but I'm also blocked on the fact that the color is set explicitly in the code (setFill), with two rectangles I need to set both fills, but I can't make one of then go away in the CSS - unless scary solitions with translate maybe. BTW, in my agenda (where I need to do something similar) I simply assign a style class and let that handle the presentation. Then I could simply have declared either color "transparent". I feel that the conference example is not using JavaFX's features to the max :-) Tom On 2012-10-27 21:30, Scott Palmer wrote: > Ah, I see what you are doing now. But if you really Bly have simple rectangles, why do you need SVG at all? Can't you accomplish what you are after with multiple backgrounds and borders? > > Scott > > On 2012-10-27, at 1:17 PM, Tom Eugelink wrote: > >> Hm. Yes. But that is not what I need to get what I want; it would also scale the width proportionally. I think I'm aiming too high; like with HTML you do need some hooks to hang the styling on. >> >> Tom >> >> >> >> >> On 2012-10-27 18:07, Scott Palmer wrote: >>> -fx-scale-shape >>> >>> Scott >>> >>> On 2012-10-27, at 10:57 AM, Tom Eugelink wrote: >>> >>>> I'm trying to modify the JavaFX conference demo application in order to demonstrate CSS styling on Wednesday's JFall. I find that a lot of the stuff is hardcoded and not easily skinnable, so I'm trying to make some pinpoint changes in order to improve this. >>>> >>>> Since my attempt is to make it more "metro" (simple straight colored rectangles is about all that my design skills can handle) I'm trying to move some of the drawing instructions out into CSS using SVG. However, some of the nodes have dynamic dimensions (width or height), and I would like to have my SVG instructions scale with that. >>>> >>>> So instead of: M0,0 L10,0 L10,10 L0,10 L0,0 Z >>>> >>>> I would like to use something like: M0,0 L{width},0 L{width},10 L0,10 L0,0 Z >>>> >>>> Is this possible? Or only by using some kind of template engine and reloading the CSS? >>>> >>>> Tom >>>> From zonski at gmail.com Sat Oct 27 15:15:26 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 28 Oct 2012 09:15:26 +1100 Subject: Making JavaFX Development Faster In-Reply-To: <508C0BB8.2000204@bestsolution.at> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> Message-ID: <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> I totally agree with Tom Schindl. Jfx properties do not fit in the current JPA model and no one would/should use them there. Properties might be useful on the server side (maybe) but not in your JPA beans. Extending what Tom said, I think it is a huge anti-pattern to share your server side beans on your client anyway. People should have DB-centric JPA beans on the server and Screen-centric beans on the client. Lots of reasons for this. I could go into great detail on this and different patterns. It was to be the next topic for my zenjava blog before I stopped using jfx, and showcasing such patterns was something I suggested the "enterprise jfx focus group" would do but that didn't seem so popular an idea so I'll take the hint and spare the list this. Just to add some more specifics on JPA beans having properties on them, as well as what Tom said, I would add: Caching woes - JPA does lots of magical caching and properties and listeners would massively confuse the cache engine, the GC and the developers if anyone tried to actually use them on the server side. That's before you start looking at transaction boundaries too. Misleading API - JPA beans are conceptually linked to a db table, does adding a listener to a property mean I'll get a callback if someone changes my table data (answer is definitely no on a distributed, sharded setup, but API implies that it could). Collections - observable lists would need to be supported too. JPA does magical things to collections (lazy loading, etc), fx collections don't fit in there. Wrong package - these properties are in jfx packages which implies client ui. Server guys won't want to go near them - psychology of this is often overlooked. Plus when/if jigsaw and modularisation happens, you add potential inter-dependencies that are odd and non-intuitive (eg my shared hosting provider could well say "no jfx on this server jre cause it's ui and we don't want people doing that here"). On 28/10/2012, at 3:28 AM, Tom Schindl wrote: > Hi, > > I really like JavaFX properties but their concept really only makes > sense on the client. > > Main points: > * They waste memory > * are not supported on all JVM (people tend to forget that javafx is > not JSRed and only part of openjdk/oracle jdk). > > > On memory: > ---------- > We can talk about laziness as much as we want but when reading a bean > from the database 95% of the fields are none null, hence lazy creation > is a nightmare. > > In my opinion VM properties are very different to what we have in JavaFX. > > > On standard: > ------------ > As outlined and confirmed by Richard, Oracle does not guarantee that > things work on all JVMs (e.g. j9) it might or might not work and can be > broken any time. > > JavaFX will be JSRed by Java9 not sure if vendors are forced to > implement the started. When you state other JSRed technologies should > adapt to the JavaFX bean standard the they can before Java9. > > > General statement: > ------------------ > I'm not even sure why people have such a big problem with using a > different object on the server (Plain POJO) and Java(FX)-Bean on the > client, writing POJOs by hand is a boring and senseless task using some > meta format or tool and generate the POJOs and JavaFX-Beans out of that > is not rocket sience. > > Tom > > Am 27.10.12 16:29, schrieb Tom Eugelink: >> About using JavaFX beans server side; can you explain why that would be >> a bad idea beside the fact that there isn't any support in frames like >> JDBC? >> >> There has been a big demand from the community for real properties in >> Java. Now JavaFX has become part of the standard JDK, I expect people to >> start using these properties in other area's as well. The binding >> concept is rather powerful and once the concept sinks in... This then >> would have consequences; some bindings no longer can be lazy, we need >> bean level listeners, etc. But this can all be added quite easily. Then >> JDBC and JPA need to be enhanced to support them and we're pretty much >> done. >> >> Tom >> >> >> On 2012-10-27 15:55, Tom Schindl wrote: >>> If I remember correctly it had to do with listeners and how to manage >>> that they are not leaked but I could be wrong. >>> >>> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, >>> am I right? I generally think using JavaFX-Beans on the server side is a >>> bad idea. >>> >>> Tom >>> >>> Am 27.10.12 15:24, schrieb Richard Bair: >>>> I cannot imagine what internal stuff Michael could be using or when >>>> that was added. >>>> >>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>>> wrote: >>>> >>>>> Not only the memory argument is import. >>>>> >>>>> What if a customer says i have to run on his j9-jvm? >>>>> >>>>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>>>> code is even using internal (sun....) stuff so even simply dropping in >>>>> the jar to the j9 classpath is doomed to fail. >>>>> >>>>> And beside that using FX-Observables and e.g. JPA don't like each other >>>>> i guess because of all those lazy list stuff, ... . >>>>> >>>>> Tom >>>>> >>>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>>> Richard, >>>>>> >>>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>>> MyObject obj = new MyObject(); >>>>>>> obj = BlackMagic.makeObservable(obj); >>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>>>> >>>>>>> However, the javafx beans package and collections and such are part >>>>>>> of the "base" module -- ie: they could be separated from the rest of >>>>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>>>> use properties and such on the server side definition of classes? Or >>>>>>> are those classes being auto-generated and thus not taking observable >>>>>>> properties into account? >>>>>> Currently I want to avoid requiring customers to install the FX >>>>>> runtime >>>>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>>>> the 6.x customers, especially if they are on WebLogic which is usually >>>>>> tied to a specific major version. >>>>>> >>>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>>> Obviously a StringProperty requires more bytes than a String. This is >>>>>> not an issue (usually) when I want to display a relatively short >>>>>> list of >>>>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>>>> megabytes, the instantion of objects needs +Y ms (also affects >>>>>> deserialization), and sending them over the network takes +Z ms... >>>>>> >>>>>> Werner >>>>> >>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>> GmbH >>>>> ------------------------------------------------------------------------ >>>>> >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------------------------------------------------ >>>>> >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>> 935833 >>>>> http://www.BestSolution.at phone ++43 512 >>>>> 935834 >>> >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From felipe.heidrich at oracle.com Sat Oct 27 21:25:10 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Sat, 27 Oct 2012 21:25:10 -0700 Subject: Font Metrics (was TextField Document model) In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <7D3F7E98-7133-45CE-BEAD-0E7E47A777AF@oracle.com> <936EB4EA-9324-4408-9F93-FB6361CF9676@gmail.com> Message-ID: <1F3A4B3D-AD43-4440-9381-0C832749EA18@oracle.com> On Oct 26, 2012, at 8:18 AM, Richard Bair wrote: > I think these are two distinct issues -- font metrics and locating glyph bounds within a string of text. FontMetrics I think is fairly straightforward -- Felipe what do you think? > Yes, Here the basics Text text = new Text(); text.setFont(Font.font("Helvetica", 24)); System.out.println("Baseline:" + text.getBaselineOffset()); Bounds bounds = text.getLayoutBounds(); //text origin by default is relative to baseline System.out.println("Ascent " + -bounds.getMinY()); System.out.println("Descent " + bounds.getMaxY());//including leading System.out.println("LineHeight " + bounds.getHeight()); If you dig in the internals a bit you will see a FontLoader class that returns a FontMetrics object for a given Font, it has x-height and other properties in it. Other metrics like average char width I don't think the user can ever get. I think we could provide better API in this area. > For the other use case, actually knowing the glyph bounds is not enough (probably). The problem is, suppose that text you were looking for wrapped from one line to the next (letter wrapping instead of word wrapping, or maybe you were searching for a phrase rather than just a word). In this case you need to know the shape that would encompassing text from both lines (think: blue selection box). Even more challenging is BIDI and ligatures -- what if the text you searched for was only using part of a glyph due to ligatures? Or you have disjoint shape due to BIDI (selection is a good example of this again). > > Now, internally we use an impl on Text to get the shape based on a range of indexes into the Text, and this shape is then used to draw selection. In our quest to get rid of impl methods, I have wanted to see this get proper API treatment. Maybe we would have a TextMeasurement class, and Text node (and TextFlow) would return an instance of it and we could have a method on it that vends a shape. Once you have a shape you can set the fill, stroke, etc as you like. > As Richard said, internally we have all the information, we just need to design a proper API. In the meantime, have you looked at TextFieldSkin caretPosition() and getCharacterBounds(), it is based on Text's private API but it is a bit cleaner and sounds like what you are looking for. Anyhow, TextFieldSkin is not part of the public API so not sure if it is a better approach for you. Felipe From swpalmer at gmail.com Sat Oct 27 22:00:38 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 28 Oct 2012 01:00:38 -0400 Subject: Font Metrics (was TextField Document model) In-Reply-To: <1F3A4B3D-AD43-4440-9381-0C832749EA18@oracle.com> References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <7D3F7E98-7133-45CE-BEAD-0E7E47A777AF@oracle.com> <936EB4EA-9324-4408-9F93-FB6361CF9676@gmail.com> <1F3A4B3D-AD43-4440-9381-0C832749EA18@oracle.com> Message-ID: My only complaint is that I had to subclass the default TextFieldSkin and set the TextField to use my skin just to get at the FontMetrics that were in use on the TextField control. I had no intention of actually implementing a skin or changing the behaviour of the default skin. I just wanted to position a popup where the caret was. So yes FontMetrics has what I need, but it should be more accessible. Scott On 2012-10-28, at 12:25 AM, Felipe Heidrich wrote: > > On Oct 26, 2012, at 8:18 AM, Richard Bair wrote: > >> I think these are two distinct issues -- font metrics and locating glyph bounds within a string of text. FontMetrics I think is fairly straightforward -- Felipe what do you think? >> > > Yes, > Here the basics > Text text = new Text(); > text.setFont(Font.font("Helvetica", 24)); > System.out.println("Baseline:" + text.getBaselineOffset()); > Bounds bounds = text.getLayoutBounds(); > //text origin by default is relative to baseline > System.out.println("Ascent " + -bounds.getMinY()); > System.out.println("Descent " + bounds.getMaxY());//including leading > System.out.println("LineHeight " + bounds.getHeight()); > > If you dig in the internals a bit you will see a FontLoader class that returns a FontMetrics object for a given Font, it has x-height and other properties in it. > Other metrics like average char width I don't think the user can ever get. I think we could provide better API in this area. > > >> For the other use case, actually knowing the glyph bounds is not enough (probably). The problem is, suppose that text you were looking for wrapped from one line to the next (letter wrapping instead of word wrapping, or maybe you were searching for a phrase rather than just a word). In this case you need to know the shape that would encompassing text from both lines (think: blue selection box). Even more challenging is BIDI and ligatures -- what if the text you searched for was only using part of a glyph due to ligatures? Or you have disjoint shape due to BIDI (selection is a good example of this again). >> >> Now, internally we use an impl on Text to get the shape based on a range of indexes into the Text, and this shape is then used to draw selection. In our quest to get rid of impl methods, I have wanted to see this get proper API treatment. Maybe we would have a TextMeasurement class, and Text node (and TextFlow) would return an instance of it and we could have a method on it that vends a shape. Once you have a shape you can set the fill, stroke, etc as you like. >> > > As Richard said, internally we have all the information, we just need to design a proper API. > In the meantime, have you looked at TextFieldSkin caretPosition() and getCharacterBounds(), it is based on Text's private API but it is a bit cleaner and sounds like what you are looking for. Anyhow, TextFieldSkin is not part of the public API so not sure if it is a better approach for you. > > Felipe > From tbee at tbee.org Sun Oct 28 00:29:09 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 28 Oct 2012 08:29:09 +0100 Subject: JPA properties (was: Making JavaFX Development Faster) In-Reply-To: <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> Message-ID: <508CDEC5.7030907@tbee.org> As it happens I'm a long term user of JPA (Eclipselink), so I know a little bit about what happens beneath the surface. JPA postprocesses all the entities classes. During this postprocessing it mainly renames the instance variables and replaces them with placeholders. These placeholders then add a.o. lazy loading (only load the data when the value is accessed) and change monitoring (mark an entity as dirty when the variable is modified). When JFX properties would be used as JPA properties, what would need to happen is that the variable inside the property is postprocessed (assuming FIELD level postprocessing). But we don't want to / can't change a class that's inside the JRE. However, JPA postprocessing adds things that JFX properties actually already do, with their invalidation, etc. You probably could create classes (extending JFX Property) that are drop-in replacements for JFX's and hold all the required JPA logic that normally would be added using postprocessing. This would either remove the need for postprocessing for this part, or make postprocessing very simple. In any case it would still allow the power of JFX binding. I'm using JGoodies binding at the moment, which works flawlessly. Why would JFX listeners be different? In the end the placeholder detect changes to the variables, no matter how these changes came to be. JPA entities are not considered linked to the database table, they're just configured to store and retrieve from tables. That is what JPA's locking mechanism is for. Binding them would create a huge problem implementationwise, performancewise, and code maintainabilitywise. Discussing this would overflow the mailing list. To summarize: change conflicts are handled upon commit. JPA caching does nothing magical; a copy can be in the EM's cache or in the EMF's cache. This only is relevant when loading and persisting, not during usage. Things like equality and hash value are important and properties need to be included when determining those. Observable lists in the end are just lists. So a placeholder is placed in front and loads the actual contents once it is being accessed for the first time. Package names is easy. You could use fronting packages, but jigsaw probably will require the properties to move into a separate package, and get fronts in JFX packages and JPA packages for backwards compatibility / create specialized versions. I'm not seeing bears. Tom On 2012-10-28 00:15, Daniel Zwolenski wrote: > I totally agree with Tom Schindl. Jfx properties do not fit in the current JPA model and no one would/should use them there. Properties might be useful on the server side (maybe) but not in your JPA beans. > > Extending what Tom said, I think it is a huge anti-pattern to share your server side beans on your client anyway. People should have DB-centric JPA beans on the server and Screen-centric beans on the client. Lots of reasons for this. I could go into great detail on this and different patterns. It was to be the next topic for my zenjava blog before I stopped using jfx, and showcasing such patterns was something I suggested the "enterprise jfx focus group" would do but that didn't seem so popular an idea so I'll take the hint and spare the list this. > > Just to add some more specifics on JPA beans having properties on them, as well as what Tom said, I would add: > > Caching woes - JPA does lots of magical caching and properties and listeners would massively confuse the cache engine, the GC and the developers if anyone tried to actually use them on the server side. That's before you start looking at transaction boundaries too. > > Misleading API - JPA beans are conceptually linked to a db table, does adding a listener to a property mean I'll get a callback if someone changes my table data (answer is definitely no on a distributed, sharded setup, but API implies that it could). > > Collections - observable lists would need to be supported too. JPA does magical things to collections (lazy loading, etc), fx collections don't fit in there. > > Wrong package - these properties are in jfx packages which implies client ui. Server guys won't want to go near them - psychology of this is often overlooked. Plus when/if jigsaw and modularisation happens, you add potential inter-dependencies that are odd and non-intuitive (eg my shared hosting provider could well say "no jfx on this server jre cause it's ui and we don't want people doing that here"). > > > > On 28/10/2012, at 3:28 AM, Tom Schindl wrote: > >> Hi, >> >> I really like JavaFX properties but their concept really only makes >> sense on the client. >> >> Main points: >> * They waste memory >> * are not supported on all JVM (people tend to forget that javafx is >> not JSRed and only part of openjdk/oracle jdk). >> >> >> On memory: >> ---------- >> We can talk about laziness as much as we want but when reading a bean >> from the database 95% of the fields are none null, hence lazy creation >> is a nightmare. >> >> In my opinion VM properties are very different to what we have in JavaFX. >> >> >> On standard: >> ------------ >> As outlined and confirmed by Richard, Oracle does not guarantee that >> things work on all JVMs (e.g. j9) it might or might not work and can be >> broken any time. >> >> JavaFX will be JSRed by Java9 not sure if vendors are forced to >> implement the started. When you state other JSRed technologies should >> adapt to the JavaFX bean standard the they can before Java9. >> >> >> General statement: >> ------------------ >> I'm not even sure why people have such a big problem with using a >> different object on the server (Plain POJO) and Java(FX)-Bean on the >> client, writing POJOs by hand is a boring and senseless task using some >> meta format or tool and generate the POJOs and JavaFX-Beans out of that >> is not rocket sience. >> >> Tom >> >> Am 27.10.12 16:29, schrieb Tom Eugelink: >>> About using JavaFX beans server side; can you explain why that would be >>> a bad idea beside the fact that there isn't any support in frames like >>> JDBC? >>> >>> There has been a big demand from the community for real properties in >>> Java. Now JavaFX has become part of the standard JDK, I expect people to >>> start using these properties in other area's as well. The binding >>> concept is rather powerful and once the concept sinks in... This then >>> would have consequences; some bindings no longer can be lazy, we need >>> bean level listeners, etc. But this can all be added quite easily. Then >>> JDBC and JPA need to be enhanced to support them and we're pretty much >>> done. >>> >>> Tom >>> >>> >>> On 2012-10-27 15:55, Tom Schindl wrote: >>>> If I remember correctly it had to do with listeners and how to manage >>>> that they are not leaked but I could be wrong. >>>> >>>> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, >>>> am I right? I generally think using JavaFX-Beans on the server side is a >>>> bad idea. >>>> >>>> Tom >>>> >>>> Am 27.10.12 15:24, schrieb Richard Bair: >>>>> I cannot imagine what internal stuff Michael could be using or when >>>>> that was added. >>>>> >>>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>>>> wrote: >>>>> >>>>>> Not only the memory argument is import. >>>>>> >>>>>> What if a customer says i have to run on his j9-jvm? >>>>>> >>>>>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>>>>> code is even using internal (sun....) stuff so even simply dropping in >>>>>> the jar to the j9 classpath is doomed to fail. >>>>>> >>>>>> And beside that using FX-Observables and e.g. JPA don't like each other >>>>>> i guess because of all those lazy list stuff, ... . >>>>>> >>>>>> Tom >>>>>> >>>>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>>>> Richard, >>>>>>> >>>>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>>>> MyObject obj = new MyObject(); >>>>>>>> obj = BlackMagic.makeObservable(obj); >>>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>>>>> >>>>>>>> However, the javafx beans package and collections and such are part >>>>>>>> of the "base" module -- ie: they could be separated from the rest of >>>>>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>>>>> use properties and such on the server side definition of classes? Or >>>>>>>> are those classes being auto-generated and thus not taking observable >>>>>>>> properties into account? >>>>>>> Currently I want to avoid requiring customers to install the FX >>>>>>> runtime >>>>>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>>>>> the 6.x customers, especially if they are on WebLogic which is usually >>>>>>> tied to a specific major version. >>>>>>> >>>>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>>>> Obviously a StringProperty requires more bytes than a String. This is >>>>>>> not an issue (usually) when I want to display a relatively short >>>>>>> list of >>>>>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>>>>> megabytes, the instantion of objects needs +Y ms (also affects >>>>>>> deserialization), and sending them over the network takes +Z ms... >>>>>>> >>>>>>> Werner >>>>>> -- >>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>> GmbH >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>> 935833 >>>>>> http://www.BestSolution.at phone ++43 512 >>>>>> 935834 >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 From zonski at gmail.com Sun Oct 28 00:42:05 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 28 Oct 2012 18:42:05 +1100 Subject: JPA properties (was: Making JavaFX Development Faster) In-Reply-To: <508CDEC5.7030907@tbee.org> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> <508CDEC5.7030907@tbee.org> Message-ID: <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> I stand by my comments but looks like a case of personal preference. Curious though, what do you use observable properties for on the server? How are you leveraging them for an advantage? On 28/10/2012, at 6:29 PM, Tom Eugelink wrote: > As it happens I'm a long term user of JPA (Eclipselink), so I know a little bit about what happens beneath the surface. > > JPA postprocesses all the entities classes. During this postprocessing it mainly renames the instance variables and replaces them with placeholders. These placeholders then add a.o. lazy loading (only load the data when the value is accessed) and change monitoring (mark an entity as dirty when the variable is modified). > > When JFX properties would be used as JPA properties, what would need to happen is that the variable inside the property is postprocessed (assuming FIELD level postprocessing). But we don't want to / can't change a class that's inside the JRE. However, JPA postprocessing adds things that JFX properties actually already do, with their invalidation, etc. You probably could create classes (extending JFX Property) that are drop-in replacements for JFX's and hold all the required JPA logic that normally would be added using postprocessing. This would either remove the need for postprocessing for this part, or make postprocessing very simple. In any case it would still allow the power of JFX binding. > > I'm using JGoodies binding at the moment, which works flawlessly. Why would JFX listeners be different? In the end the placeholder detect changes to the variables, no matter how these changes came to be. > > JPA entities are not considered linked to the database table, they're just configured to store and retrieve from tables. That is what JPA's locking mechanism is for. Binding them would create a huge problem implementationwise, performancewise, and code maintainabilitywise. Discussing this would overflow the mailing list. To summarize: change conflicts are handled upon commit. > > JPA caching does nothing magical; a copy can be in the EM's cache or in the EMF's cache. This only is relevant when loading and persisting, not during usage. Things like equality and hash value are important and properties need to be included when determining those. > > Observable lists in the end are just lists. So a placeholder is placed in front and loads the actual contents once it is being accessed for the first time. > > Package names is easy. You could use fronting packages, but jigsaw probably will require the properties to move into a separate package, and get fronts in JFX packages and JPA packages for backwards compatibility / create specialized versions. > > I'm not seeing bears. > > Tom > > > > On 2012-10-28 00:15, Daniel Zwolenski wrote: >> I totally agree with Tom Schindl. Jfx properties do not fit in the current JPA model and no one would/should use them there. Properties might be useful on the server side (maybe) but not in your JPA beans. >> >> Extending what Tom said, I think it is a huge anti-pattern to share your server side beans on your client anyway. People should have DB-centric JPA beans on the server and Screen-centric beans on the client. Lots of reasons for this. I could go into great detail on this and different patterns. It was to be the next topic for my zenjava blog before I stopped using jfx, and showcasing such patterns was something I suggested the "enterprise jfx focus group" would do but that didn't seem so popular an idea so I'll take the hint and spare the list this. >> >> Just to add some more specifics on JPA beans having properties on them, as well as what Tom said, I would add: >> >> Caching woes - JPA does lots of magical caching and properties and listeners would massively confuse the cache engine, the GC and the developers if anyone tried to actually use them on the server side. That's before you start looking at transaction boundaries too. >> >> Misleading API - JPA beans are conceptually linked to a db table, does adding a listener to a property mean I'll get a callback if someone changes my table data (answer is definitely no on a distributed, sharded setup, but API implies that it could). >> >> Collections - observable lists would need to be supported too. JPA does magical things to collections (lazy loading, etc), fx collections don't fit in there. >> >> Wrong package - these properties are in jfx packages which implies client ui. Server guys won't want to go near them - psychology of this is often overlooked. Plus when/if jigsaw and modularisation happens, you add potential inter-dependencies that are odd and non-intuitive (eg my shared hosting provider could well say "no jfx on this server jre cause it's ui and we don't want people doing that here"). >> >> >> >> On 28/10/2012, at 3:28 AM, Tom Schindl wrote: >> >>> Hi, >>> >>> I really like JavaFX properties but their concept really only makes >>> sense on the client. >>> >>> Main points: >>> * They waste memory >>> * are not supported on all JVM (people tend to forget that javafx is >>> not JSRed and only part of openjdk/oracle jdk). >>> >>> >>> On memory: >>> ---------- >>> We can talk about laziness as much as we want but when reading a bean >>> from the database 95% of the fields are none null, hence lazy creation >>> is a nightmare. >>> >>> In my opinion VM properties are very different to what we have in JavaFX. >>> >>> >>> On standard: >>> ------------ >>> As outlined and confirmed by Richard, Oracle does not guarantee that >>> things work on all JVMs (e.g. j9) it might or might not work and can be >>> broken any time. >>> >>> JavaFX will be JSRed by Java9 not sure if vendors are forced to >>> implement the started. When you state other JSRed technologies should >>> adapt to the JavaFX bean standard the they can before Java9. >>> >>> >>> General statement: >>> ------------------ >>> I'm not even sure why people have such a big problem with using a >>> different object on the server (Plain POJO) and Java(FX)-Bean on the >>> client, writing POJOs by hand is a boring and senseless task using some >>> meta format or tool and generate the POJOs and JavaFX-Beans out of that >>> is not rocket sience. >>> >>> Tom >>> >>> Am 27.10.12 16:29, schrieb Tom Eugelink: >>>> About using JavaFX beans server side; can you explain why that would be >>>> a bad idea beside the fact that there isn't any support in frames like >>>> JDBC? >>>> >>>> There has been a big demand from the community for real properties in >>>> Java. Now JavaFX has become part of the standard JDK, I expect people to >>>> start using these properties in other area's as well. The binding >>>> concept is rather powerful and once the concept sinks in... This then >>>> would have consequences; some bindings no longer can be lazy, we need >>>> bean level listeners, etc. But this can all be added quite easily. Then >>>> JDBC and JPA need to be enhanced to support them and we're pretty much >>>> done. >>>> >>>> Tom >>>> >>>> >>>> On 2012-10-27 15:55, Tom Schindl wrote: >>>>> If I remember correctly it had to do with listeners and how to manage >>>>> that they are not leaked but I could be wrong. >>>>> >>>>> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, >>>>> am I right? I generally think using JavaFX-Beans on the server side is a >>>>> bad idea. >>>>> >>>>> Tom >>>>> >>>>> Am 27.10.12 15:24, schrieb Richard Bair: >>>>>> I cannot imagine what internal stuff Michael could be using or when >>>>>> that was added. >>>>>> >>>>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>>>>> wrote: >>>>>> >>>>>>> Not only the memory argument is import. >>>>>>> >>>>>>> What if a customer says i have to run on his j9-jvm? >>>>>>> >>>>>>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>>>>>> code is even using internal (sun....) stuff so even simply dropping in >>>>>>> the jar to the j9 classpath is doomed to fail. >>>>>>> >>>>>>> And beside that using FX-Observables and e.g. JPA don't like each other >>>>>>> i guess because of all those lazy list stuff, ... . >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>>>>> Richard, >>>>>>>> >>>>>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>>>>> MyObject obj = new MyObject(); >>>>>>>>> obj = BlackMagic.makeObservable(obj); >>>>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>>>>>> >>>>>>>>> However, the javafx beans package and collections and such are part >>>>>>>>> of the "base" module -- ie: they could be separated from the rest of >>>>>>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>>>>>> use properties and such on the server side definition of classes? Or >>>>>>>>> are those classes being auto-generated and thus not taking observable >>>>>>>>> properties into account? >>>>>>>> Currently I want to avoid requiring customers to install the FX >>>>>>>> runtime >>>>>>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>>>>>> the 6.x customers, especially if they are on WebLogic which is usually >>>>>>>> tied to a specific major version. >>>>>>>> >>>>>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>>>>> Obviously a StringProperty requires more bytes than a String. This is >>>>>>>> not an issue (usually) when I want to display a relatively short >>>>>>>> list of >>>>>>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>>>>>> megabytes, the instantion of objects needs +Y ms (also affects >>>>>>>> deserialization), and sending them over the network takes +Z ms... >>>>>>>> >>>>>>>> Werner >>>>>>> -- >>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>>> GmbH >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>>> 935833 >>>>>>> http://www.BestSolution.at phone ++43 512 >>>>>>> 935834 >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 > From tbee at tbee.org Sun Oct 28 01:54:05 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 28 Oct 2012 09:54:05 +0100 Subject: JPA properties In-Reply-To: <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> <508CDEC5.7030907@tbee.org> <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> Message-ID: <508CF2AD.40809@tbee.org> Ah. JPA not necessarily is used server only. The whole EJB setup is very suited for webapps, but may not be the best setup for desktop apps. The EJBs have some drawbacks (insert lenghty discussion here), so I opted to create a business model that is distributed as a standalone postprocessed jar. It is used in a Swing app, JSF2 webapp, several batch processes for a.o. EDIFACT, email, etc. Each with their own entity manager approach. And in case of a Swing (JavaFX) app observable lists can be very handy. Tom On 2012-10-28 08:42, Daniel Zwolenski wrote: > I stand by my comments but looks like a case of personal preference. > > Curious though, what do you use observable properties for on the server? How are you leveraging them for an advantage? > > > > On 28/10/2012, at 6:29 PM, Tom Eugelink wrote: > >> As it happens I'm a long term user of JPA (Eclipselink), so I know a little bit about what happens beneath the surface. >> >> JPA postprocesses all the entities classes. During this postprocessing it mainly renames the instance variables and replaces them with placeholders. These placeholders then add a.o. lazy loading (only load the data when the value is accessed) and change monitoring (mark an entity as dirty when the variable is modified). >> >> When JFX properties would be used as JPA properties, what would need to happen is that the variable inside the property is postprocessed (assuming FIELD level postprocessing). But we don't want to / can't change a class that's inside the JRE. However, JPA postprocessing adds things that JFX properties actually already do, with their invalidation, etc. You probably could create classes (extending JFX Property) that are drop-in replacements for JFX's and hold all the required JPA logic that normally would be added using postprocessing. This would either remove the need for postprocessing for this part, or make postprocessing very simple. In any case it would still allow the power of JFX binding. >> >> I'm using JGoodies binding at the moment, which works flawlessly. Why would JFX listeners be different? In the end the placeholder detect changes to the variables, no matter how these changes came to be. >> >> JPA entities are not considered linked to the database table, they're just configured to store and retrieve from tables. That is what JPA's locking mechanism is for. Binding them would create a huge problem implementationwise, performancewise, and code maintainabilitywise. Discussing this would overflow the mailing list. To summarize: change conflicts are handled upon commit. >> >> JPA caching does nothing magical; a copy can be in the EM's cache or in the EMF's cache. This only is relevant when loading and persisting, not during usage. Things like equality and hash value are important and properties need to be included when determining those. >> >> Observable lists in the end are just lists. So a placeholder is placed in front and loads the actual contents once it is being accessed for the first time. >> >> Package names is easy. You could use fronting packages, but jigsaw probably will require the properties to move into a separate package, and get fronts in JFX packages and JPA packages for backwards compatibility / create specialized versions. >> >> I'm not seeing bears. >> >> Tom >> >> >> >> On 2012-10-28 00:15, Daniel Zwolenski wrote: >>> I totally agree with Tom Schindl. Jfx properties do not fit in the current JPA model and no one would/should use them there. Properties might be useful on the server side (maybe) but not in your JPA beans. >>> >>> Extending what Tom said, I think it is a huge anti-pattern to share your server side beans on your client anyway. People should have DB-centric JPA beans on the server and Screen-centric beans on the client. Lots of reasons for this. I could go into great detail on this and different patterns. It was to be the next topic for my zenjava blog before I stopped using jfx, and showcasing such patterns was something I suggested the "enterprise jfx focus group" would do but that didn't seem so popular an idea so I'll take the hint and spare the list this. >>> >>> Just to add some more specifics on JPA beans having properties on them, as well as what Tom said, I would add: >>> >>> Caching woes - JPA does lots of magical caching and properties and listeners would massively confuse the cache engine, the GC and the developers if anyone tried to actually use them on the server side. That's before you start looking at transaction boundaries too. >>> >>> Misleading API - JPA beans are conceptually linked to a db table, does adding a listener to a property mean I'll get a callback if someone changes my table data (answer is definitely no on a distributed, sharded setup, but API implies that it could). >>> >>> Collections - observable lists would need to be supported too. JPA does magical things to collections (lazy loading, etc), fx collections don't fit in there. >>> >>> Wrong package - these properties are in jfx packages which implies client ui. Server guys won't want to go near them - psychology of this is often overlooked. Plus when/if jigsaw and modularisation happens, you add potential inter-dependencies that are odd and non-intuitive (eg my shared hosting provider could well say "no jfx on this server jre cause it's ui and we don't want people doing that here"). >>> >>> >>> >>> On 28/10/2012, at 3:28 AM, Tom Schindl wrote: >>> >>>> Hi, >>>> >>>> I really like JavaFX properties but their concept really only makes >>>> sense on the client. >>>> >>>> Main points: >>>> * They waste memory >>>> * are not supported on all JVM (people tend to forget that javafx is >>>> not JSRed and only part of openjdk/oracle jdk). >>>> >>>> >>>> On memory: >>>> ---------- >>>> We can talk about laziness as much as we want but when reading a bean >>>> from the database 95% of the fields are none null, hence lazy creation >>>> is a nightmare. >>>> >>>> In my opinion VM properties are very different to what we have in JavaFX. >>>> >>>> >>>> On standard: >>>> ------------ >>>> As outlined and confirmed by Richard, Oracle does not guarantee that >>>> things work on all JVMs (e.g. j9) it might or might not work and can be >>>> broken any time. >>>> >>>> JavaFX will be JSRed by Java9 not sure if vendors are forced to >>>> implement the started. When you state other JSRed technologies should >>>> adapt to the JavaFX bean standard the they can before Java9. >>>> >>>> >>>> General statement: >>>> ------------------ >>>> I'm not even sure why people have such a big problem with using a >>>> different object on the server (Plain POJO) and Java(FX)-Bean on the >>>> client, writing POJOs by hand is a boring and senseless task using some >>>> meta format or tool and generate the POJOs and JavaFX-Beans out of that >>>> is not rocket sience. >>>> >>>> Tom >>>> >>>> Am 27.10.12 16:29, schrieb Tom Eugelink: >>>>> About using JavaFX beans server side; can you explain why that would be >>>>> a bad idea beside the fact that there isn't any support in frames like >>>>> JDBC? >>>>> >>>>> There has been a big demand from the community for real properties in >>>>> Java. Now JavaFX has become part of the standard JDK, I expect people to >>>>> start using these properties in other area's as well. The binding >>>>> concept is rather powerful and once the concept sinks in... This then >>>>> would have consequences; some bindings no longer can be lazy, we need >>>>> bean level listeners, etc. But this can all be added quite easily. Then >>>>> JDBC and JPA need to be enhanced to support them and we're pretty much >>>>> done. >>>>> >>>>> Tom >>>>> >>>>> >>>>> On 2012-10-27 15:55, Tom Schindl wrote: >>>>>> If I remember correctly it had to do with listeners and how to manage >>>>>> that they are not leaked but I could be wrong. >>>>>> >>>>>> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, >>>>>> am I right? I generally think using JavaFX-Beans on the server side is a >>>>>> bad idea. >>>>>> >>>>>> Tom >>>>>> >>>>>> Am 27.10.12 15:24, schrieb Richard Bair: >>>>>>> I cannot imagine what internal stuff Michael could be using or when >>>>>>> that was added. >>>>>>> >>>>>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>>>>>> wrote: >>>>>>> >>>>>>>> Not only the memory argument is import. >>>>>>>> >>>>>>>> What if a customer says i have to run on his j9-jvm? >>>>>>>> >>>>>>>> I can be wrong but IIRC Michael told me at JavaOne that the properties >>>>>>>> code is even using internal (sun....) stuff so even simply dropping in >>>>>>>> the jar to the j9 classpath is doomed to fail. >>>>>>>> >>>>>>>> And beside that using FX-Observables and e.g. JPA don't like each other >>>>>>>> i guess because of all those lazy list stuff, ... . >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>>>>>> Richard, >>>>>>>>> >>>>>>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>>>>>> MyObject obj = new MyObject(); >>>>>>>>>> obj = BlackMagic.makeObservable(obj); >>>>>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>>>>>>>> >>>>>>>>>> However, the javafx beans package and collections and such are part >>>>>>>>>> of the "base" module -- ie: they could be separated from the rest of >>>>>>>>>> javafx and safely used on the server side or elsewhere. Why not just >>>>>>>>>> use properties and such on the server side definition of classes? Or >>>>>>>>>> are those classes being auto-generated and thus not taking observable >>>>>>>>>> properties into account? >>>>>>>>> Currently I want to avoid requiring customers to install the FX >>>>>>>>> runtime >>>>>>>>> serverside. That will be a moot point with JRE 7+. Which does not help >>>>>>>>> the 6.x customers, especially if they are on WebLogic which is usually >>>>>>>>> tied to a specific major version. >>>>>>>>> >>>>>>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>>>>>> Obviously a StringProperty requires more bytes than a String. This is >>>>>>>>> not an issue (usually) when I want to display a relatively short >>>>>>>>> list of >>>>>>>>> beans in the UI. It gets noticeable when the server suddenly needs +X >>>>>>>>> megabytes, the instantion of objects needs +Y ms (also affects >>>>>>>>> deserialization), and sending them over the network takes +Z ms... >>>>>>>>> >>>>>>>>> Werner >>>>>>>> -- >>>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>>>> GmbH >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>>>> 935833 >>>>>>>> http://www.BestSolution.at phone ++43 512 >>>>>>>> 935834 >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>> ------------------------------------------------------------------------ >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>> http://www.BestSolution.at phone ++43 512 935834 From zonski at gmail.com Sun Oct 28 04:23:13 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 28 Oct 2012 22:23:13 +1100 Subject: How does JFX work get prioritised? Message-ID: Is it possible for someone from the Oracle JFX team to outline how features get prioritised for inclusion in a release? I've been frustrated at times with things I think I are important not getting done, and I think a few others have had similar experiences. Obviously all of us think our bug/feature is the most important thing, and not everything can get done and there has to be priorities. I think it would be less frustrating though if we actually knew the process that was used to prioritise issues - who decides, and what metrics are used as input? I noted today for example, that RT-10376, which is simply to allow maximising the stage programmatically, just got bumped so its not part of Java8 and is not part of any foreseeable release. I personally don't care about this feature so much, but it does look like a pretty fundamental, basic thing for a windowing toolkit to have, so highlights the general point: - It was raised as a "critical feature" by Jasper Potts, so it doesn't seem a case of not being recognised as important within Oracle. - It was raised back in 2010 so it doesn't seem a case of it coming in too late and just not making the cut for the release. - Based on comments from Anthony Petrov it seems to be already mostly implemented and just needs to be hooked in, so I'm assuming it's not really a big resourcing issue. - It's got 28 votes from the community, placing it at #8 in the most voted list by my reckoning, so there's no lack of community interest in the issue (3D geometry support has 12 votes for example). >From my vantage point, it's difficult to see why a feature like this wouldn't have been done months ago, let alone be off the road map completely, especially when you consider some of the more obscure features on the roadmap. Confusion over something like this, for me at least, festers into a general distrust in the process, which results in frustration around other issues I do consider important (like build/deployment). Can this confusion be lessened through some better communication? Is it possible to explain how, in this case and in general, you guys prioritise JavaFX work? From zonski at gmail.com Sun Oct 28 04:44:19 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 28 Oct 2012 22:44:19 +1100 Subject: JPA properties In-Reply-To: <508CF2AD.40809@tbee.org> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> <508CDEC5.7030907@tbee.org> <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> <508CF2AD.40809@tbee.org> Message-ID: Fair enough. Calling directly onto a database from the client is probably not an approach I would go for too often or recommend for a lot of use cases, but hey, if it works for you, great. All of my comments were with respect to a standard client-server, 3-tier, JEE architecture (but I don't use EJBs). I personally don't see observable properties being useful or desirable in the server side of this architecture (and would recommend a model for the client tier that is completely decoupled from the data tier, potentially with a DTO pattern at the service tier to transfer data between them). Probably all debating a mute point from JFX's perspective though - JFX properties are what they are and not likely to change. Use them on the server if you want, don't if you don't. On Sun, Oct 28, 2012 at 7:54 PM, Tom Eugelink wrote: > Ah. JPA not necessarily is used server only. The whole EJB setup is very > suited for webapps, but may not be the best setup for desktop apps. The > EJBs have some drawbacks (insert lenghty discussion here), so I opted to > create a business model that is distributed as a standalone postprocessed > jar. It is used in a Swing app, JSF2 webapp, several batch processes for > a.o. EDIFACT, email, etc. Each with their own entity manager approach. > > And in case of a Swing (JavaFX) app observable lists can be very handy. > > Tom > > > > On 2012-10-28 08:42, Daniel Zwolenski wrote: > >> I stand by my comments but looks like a case of personal preference. >> >> Curious though, what do you use observable properties for on the server? >> How are you leveraging them for an advantage? >> >> >> >> On 28/10/2012, at 6:29 PM, Tom Eugelink wrote: >> >> As it happens I'm a long term user of JPA (Eclipselink), so I know a >>> little bit about what happens beneath the surface. >>> >>> JPA postprocesses all the entities classes. During this postprocessing >>> it mainly renames the instance variables and replaces them with >>> placeholders. These placeholders then add a.o. lazy loading (only load the >>> data when the value is accessed) and change monitoring (mark an entity as >>> dirty when the variable is modified). >>> >>> When JFX properties would be used as JPA properties, what would need to >>> happen is that the variable inside the property is postprocessed (assuming >>> FIELD level postprocessing). But we don't want to / can't change a class >>> that's inside the JRE. However, JPA postprocessing adds things that JFX >>> properties actually already do, with their invalidation, etc. You probably >>> could create classes (extending JFX Property) that are drop-in replacements >>> for JFX's and hold all the required JPA logic that normally would be added >>> using postprocessing. This would either remove the need for postprocessing >>> for this part, or make postprocessing very simple. In any case it would >>> still allow the power of JFX binding. >>> >>> I'm using JGoodies binding at the moment, which works flawlessly. Why >>> would JFX listeners be different? In the end the placeholder detect changes >>> to the variables, no matter how these changes came to be. >>> >>> JPA entities are not considered linked to the database table, they're >>> just configured to store and retrieve from tables. That is what JPA's >>> locking mechanism is for. Binding them would create a huge problem >>> implementationwise, performancewise, and code maintainabilitywise. >>> Discussing this would overflow the mailing list. To summarize: change >>> conflicts are handled upon commit. >>> >>> JPA caching does nothing magical; a copy can be in the EM's cache or in >>> the EMF's cache. This only is relevant when loading and persisting, not >>> during usage. Things like equality and hash value are important and >>> properties need to be included when determining those. >>> >>> Observable lists in the end are just lists. So a placeholder is placed >>> in front and loads the actual contents once it is being accessed for the >>> first time. >>> >>> Package names is easy. You could use fronting packages, but jigsaw >>> probably will require the properties to move into a separate package, and >>> get fronts in JFX packages and JPA packages for backwards compatibility / >>> create specialized versions. >>> >>> I'm not seeing bears. >>> >>> Tom >>> >>> >>> >>> On 2012-10-28 00:15, Daniel Zwolenski wrote: >>> >>>> I totally agree with Tom Schindl. Jfx properties do not fit in the >>>> current JPA model and no one would/should use them there. Properties might >>>> be useful on the server side (maybe) but not in your JPA beans. >>>> >>>> Extending what Tom said, I think it is a huge anti-pattern to share >>>> your server side beans on your client anyway. People should have DB-centric >>>> JPA beans on the server and Screen-centric beans on the client. Lots of >>>> reasons for this. I could go into great detail on this and different >>>> patterns. It was to be the next topic for my zenjava blog before I stopped >>>> using jfx, and showcasing such patterns was something I suggested the >>>> "enterprise jfx focus group" would do but that didn't seem so popular an >>>> idea so I'll take the hint and spare the list this. >>>> >>>> Just to add some more specifics on JPA beans having properties on them, >>>> as well as what Tom said, I would add: >>>> >>>> Caching woes - JPA does lots of magical caching and properties and >>>> listeners would massively confuse the cache engine, the GC and the >>>> developers if anyone tried to actually use them on the server side. That's >>>> before you start looking at transaction boundaries too. >>>> >>>> Misleading API - JPA beans are conceptually linked to a db table, does >>>> adding a listener to a property mean I'll get a callback if someone changes >>>> my table data (answer is definitely no on a distributed, sharded setup, but >>>> API implies that it could). >>>> >>>> Collections - observable lists would need to be supported too. JPA does >>>> magical things to collections (lazy loading, etc), fx collections don't fit >>>> in there. >>>> >>>> Wrong package - these properties are in jfx packages which implies >>>> client ui. Server guys won't want to go near them - psychology of this is >>>> often overlooked. Plus when/if jigsaw and modularisation happens, you add >>>> potential inter-dependencies that are odd and non-intuitive (eg my shared >>>> hosting provider could well say "no jfx on this server jre cause it's ui >>>> and we don't want people doing that here"). >>>> >>>> >>>> >>>> On 28/10/2012, at 3:28 AM, Tom Schindl >>>> wrote: >>>> >>>> Hi, >>>>> >>>>> I really like JavaFX properties but their concept really only makes >>>>> sense on the client. >>>>> >>>>> Main points: >>>>> * They waste memory >>>>> * are not supported on all JVM (people tend to forget that javafx is >>>>> not JSRed and only part of openjdk/oracle jdk). >>>>> >>>>> >>>>> On memory: >>>>> ---------- >>>>> We can talk about laziness as much as we want but when reading a bean >>>>> from the database 95% of the fields are none null, hence lazy creation >>>>> is a nightmare. >>>>> >>>>> In my opinion VM properties are very different to what we have in >>>>> JavaFX. >>>>> >>>>> >>>>> On standard: >>>>> ------------ >>>>> As outlined and confirmed by Richard, Oracle does not guarantee that >>>>> things work on all JVMs (e.g. j9) it might or might not work and can be >>>>> broken any time. >>>>> >>>>> JavaFX will be JSRed by Java9 not sure if vendors are forced to >>>>> implement the started. When you state other JSRed technologies should >>>>> adapt to the JavaFX bean standard the they can before Java9. >>>>> >>>>> >>>>> General statement: >>>>> ------------------ >>>>> I'm not even sure why people have such a big problem with using a >>>>> different object on the server (Plain POJO) and Java(FX)-Bean on the >>>>> client, writing POJOs by hand is a boring and senseless task using some >>>>> meta format or tool and generate the POJOs and JavaFX-Beans out of that >>>>> is not rocket sience. >>>>> >>>>> Tom >>>>> >>>>> Am 27.10.12 16:29, schrieb Tom Eugelink: >>>>> >>>>>> About using JavaFX beans server side; can you explain why that would >>>>>> be >>>>>> a bad idea beside the fact that there isn't any support in frames like >>>>>> JDBC? >>>>>> >>>>>> There has been a big demand from the community for real properties in >>>>>> Java. Now JavaFX has become part of the standard JDK, I expect people >>>>>> to >>>>>> start using these properties in other area's as well. The binding >>>>>> concept is rather powerful and once the concept sinks in... This then >>>>>> would have consequences; some bindings no longer can be lazy, we need >>>>>> bean level listeners, etc. But this can all be added quite easily. >>>>>> Then >>>>>> JDBC and JPA need to be enhanced to support them and we're pretty much >>>>>> done. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On 2012-10-27 15:55, Tom Schindl wrote: >>>>>> >>>>>>> If I remember correctly it had to do with listeners and how to manage >>>>>>> that they are not leaked but I could be wrong. >>>>>>> >>>>>>> Anyways nobody guarantees that OpenJFX will run on other vendors >>>>>>> JVMs, >>>>>>> am I right? I generally think using JavaFX-Beans on the server side >>>>>>> is a >>>>>>> bad idea. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> Am 27.10.12 15:24, schrieb Richard Bair: >>>>>>> >>>>>>>> I cannot imagine what internal stuff Michael could be using or when >>>>>>>> that was added. >>>>>>>> >>>>>>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>>>>>>> wrote: >>>>>>>> >>>>>>>> Not only the memory argument is import. >>>>>>>>> >>>>>>>>> What if a customer says i have to run on his j9-jvm? >>>>>>>>> >>>>>>>>> I can be wrong but IIRC Michael told me at JavaOne that the >>>>>>>>> properties >>>>>>>>> code is even using internal (sun....) stuff so even simply >>>>>>>>> dropping in >>>>>>>>> the jar to the j9 classpath is doomed to fail. >>>>>>>>> >>>>>>>>> And beside that using FX-Observables and e.g. JPA don't like each >>>>>>>>> other >>>>>>>>> i guess because of all those lazy list stuff, ... . >>>>>>>>> >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>>>>>> >>>>>>>>>> Richard, >>>>>>>>>> >>>>>>>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>>>>>> >>>>>>>>>>> MyObject obj = new MyObject(); >>>>>>>>>>> obj = BlackMagic.makeObservable(obj)**; >>>>>>>>>>> >>>>>>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib >>>>>>>>>> stuff?) >>>>>>>>>> >>>>>>>>>> However, the javafx beans package and collections and such are >>>>>>>>>>> part >>>>>>>>>>> of the "base" module -- ie: they could be separated from the >>>>>>>>>>> rest of >>>>>>>>>>> javafx and safely used on the server side or elsewhere. Why not >>>>>>>>>>> just >>>>>>>>>>> use properties and such on the server side definition of >>>>>>>>>>> classes? Or >>>>>>>>>>> are those classes being auto-generated and thus not taking >>>>>>>>>>> observable >>>>>>>>>>> properties into account? >>>>>>>>>>> >>>>>>>>>> Currently I want to avoid requiring customers to install the FX >>>>>>>>>> runtime >>>>>>>>>> serverside. That will be a moot point with JRE 7+. Which does not >>>>>>>>>> help >>>>>>>>>> the 6.x customers, especially if they are on WebLogic which is >>>>>>>>>> usually >>>>>>>>>> tied to a specific major version. >>>>>>>>>> >>>>>>>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>>>>>>> Obviously a StringProperty requires more bytes than a String. >>>>>>>>>> This is >>>>>>>>>> not an issue (usually) when I want to display a relatively short >>>>>>>>>> list of >>>>>>>>>> beans in the UI. It gets noticeable when the server suddenly >>>>>>>>>> needs +X >>>>>>>>>> megabytes, the instantion of objects needs +Y ms (also affects >>>>>>>>>> deserialization), and sending them over the network takes +Z ms... >>>>>>>>>> >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>>>>> GmbH >>>>>>>>> ------------------------------**------------------------------** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>>>>> ------------------------------**------------------------------** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>>>>> 935833 >>>>>>>>> http://www.BestSolution.at phone ++43 512 >>>>>>>>> 935834 >>>>>>>>> >>>>>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>> GmbH >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>> 935833 >>>>> http://www.BestSolution.at phone ++43 512 >>>>> 935834 >>>>> >>>> > From scekics at gmail.com Sun Oct 28 06:24:13 2012 From: scekics at gmail.com (Slavko Scekic) Date: Sun, 28 Oct 2012 14:24:13 +0100 Subject: How does JFX work get prioritised? In-Reply-To: References: Message-ID: A good question, Daniel. One that I would like to see answered as well. On Sun, Oct 28, 2012 at 12:23 PM, Daniel Zwolenski wrote: > Is it possible for someone from the Oracle JFX team to outline how features > get prioritised for inclusion in a release? > > I've been frustrated at times with things I think I are important not > getting done, and I think a few others have had similar > experiences. Obviously all of us think our bug/feature is the most > important thing, and not everything can get done and there has to be > priorities. I think it would be less frustrating though if we actually knew > the process that was used to prioritise issues - who decides, and what > metrics are used as input? > > I noted today for example, that > RT-10376, > which is simply to allow maximising the stage programmatically, just got > bumped so its not part of Java8 and is not part of any foreseeable > release. I personally don't care about this feature so much, but it does > look like a pretty fundamental, basic thing for a windowing toolkit to > have, so highlights the general point: > > - It was raised as a "critical feature" by Jasper Potts, so it doesn't > seem a case of not being recognised as important within Oracle. > - It was raised back in 2010 so it doesn't seem a case of it coming in > too late and just not making the cut for the release. > - Based on comments from Anthony Petrov it seems to be already mostly > implemented and just needs to be hooked in, so I'm assuming it's not > really > a big resourcing issue. > - It's got 28 votes from the community, placing it at #8 in the most > voted list by my reckoning, so there's no lack of community interest in > the > issue (3D geometry support has 12 votes for example). > > >From my vantage point, it's difficult to see why a feature like this > wouldn't have been done months ago, let alone be off the road map > completely, especially when you consider some of the more obscure features > on the roadmap. Confusion over something like this, for me at least, > festers into a general distrust in the process, which results in > frustration around other issues I do consider important (like > build/deployment). > > Can this confusion be lessened through some better communication? Is it > possible to explain how, in this case and in general, you guys prioritise > JavaFX work? > From phidias51 at gmail.com Sun Oct 28 09:55:49 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Sun, 28 Oct 2012 09:55:49 -0700 Subject: Making JavaFX Development Faster In-Reply-To: <508C0BB8.2000204@bestsolution.at> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> Message-ID: Getting back to the original topic for a sec, one of the things I've observed with JavaFX is that there are some areas where I think the basic development workflow aren't being helped by JavaFX, and I think these problems are eminently solvable. Here's my workflow (the bits in boldface are the gaps that JavaFX could fill in and make easier): 1. It starts with a spreadsheet. It's the de facto tool that any user uses to collect data (be they scientists or wizards of wall street). They show me the analysis that they want to be able to do with that data. I want to use that spreadsheet as a model for my prototyping work. 2. Create a prototype. I sketch out the result of our conversations, and use SceneBuilder to quickly put together a prototype. At this point I want to be able to *bind the spreadsheet to a tableview, or bind a couple columns to a combobox* so that the users can see real data in the app. Sometimes we get lucky and the data they asking for is already in the database, if that's the case we just need to *bind the widgets to existing RESTful services*. 3. Get approval to create the app. 4. Create POJOs. *Generate forms, controllers, services* (at least for the server side). It would be really helpful to be able to generate JavaFX forms, and controllers as well. At a minimum I need to bind controllers to widgets so that I can populate a comboboxes and charts with values. 5. The remainder of the work revolves around creating and testing the business logic behind the analysis -- the real work that the user's want automated. 6. Deploy the app. This last step is critical to us since it allows the users to give us feedback and do any last minute course correction. It's also the step that threw us for a loop on our last project, since we didn't anticipate that a long-standing technology like webstart would have been broken, and that Oracle would release JREs that continue to be broken. Unlike the native packaging options, webstart means that we don't have to contend with users not updating in a timely manner, nor do we have the manpower to run around to desktops and do the installs ourselves, or use multiple platform specific tools to push apps to the desktop. One thing that I would really like to see fixed, is that when we deploy apps internally, we shouldn't have to jump through all of these hoops to do it. Why do we have sign other people's jars (or even our own jars) for internally deployed apps? There are inherently at least three modes for this kind of deployments (internal, b2c, and b2b). In the latter two cases I would expect to have to sign apps, but not for internal apps. I'm sure there are other workflows, and I'd like to learn more about how other people are doing development. Regards, Mark On Sat, Oct 27, 2012 at 9:28 AM, Tom Schindl wrote: > Hi, > > I really like JavaFX properties but their concept really only makes > sense on the client. > > Main points: > * They waste memory > * are not supported on all JVM (people tend to forget that javafx is > not JSRed and only part of openjdk/oracle jdk). > > > On memory: > ---------- > We can talk about laziness as much as we want but when reading a bean > from the database 95% of the fields are none null, hence lazy creation > is a nightmare. > > In my opinion VM properties are very different to what we have in JavaFX. > > > On standard: > ------------ > As outlined and confirmed by Richard, Oracle does not guarantee that > things work on all JVMs (e.g. j9) it might or might not work and can be > broken any time. > > JavaFX will be JSRed by Java9 not sure if vendors are forced to > implement the started. When you state other JSRed technologies should > adapt to the JavaFX bean standard the they can before Java9. > > > General statement: > ------------------ > I'm not even sure why people have such a big problem with using a > different object on the server (Plain POJO) and Java(FX)-Bean on the > client, writing POJOs by hand is a boring and senseless task using some > meta format or tool and generate the POJOs and JavaFX-Beans out of that > is not rocket sience. > > Tom > > Am 27.10.12 16:29, schrieb Tom Eugelink: > > About using JavaFX beans server side; can you explain why that would be > > a bad idea beside the fact that there isn't any support in frames like > > JDBC? > > > > There has been a big demand from the community for real properties in > > Java. Now JavaFX has become part of the standard JDK, I expect people to > > start using these properties in other area's as well. The binding > > concept is rather powerful and once the concept sinks in... This then > > would have consequences; some bindings no longer can be lazy, we need > > bean level listeners, etc. But this can all be added quite easily. Then > > JDBC and JPA need to be enhanced to support them and we're pretty much > > done. > > > > Tom > > > > > > On 2012-10-27 15:55, Tom Schindl wrote: > >> If I remember correctly it had to do with listeners and how to manage > >> that they are not leaked but I could be wrong. > >> > >> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs, > >> am I right? I generally think using JavaFX-Beans on the server side is a > >> bad idea. > >> > >> Tom > >> > >> Am 27.10.12 15:24, schrieb Richard Bair: > >>> I cannot imagine what internal stuff Michael could be using or when > >>> that was added. > >>> > >>> On Oct 26, 2012, at 7:42 AM, Tom Schindl > >>> wrote: > >>> > >>>> Not only the memory argument is import. > >>>> > >>>> What if a customer says i have to run on his j9-jvm? > >>>> > >>>> I can be wrong but IIRC Michael told me at JavaOne that the properties > >>>> code is even using internal (sun....) stuff so even simply dropping in > >>>> the jar to the j9 classpath is doomed to fail. > >>>> > >>>> And beside that using FX-Observables and e.g. JPA don't like each > other > >>>> i guess because of all those lazy list stuff, ... . > >>>> > >>>> Tom > >>>> > >>>> Am 22.10.12 19:23, schrieb Werner Lehmann: > >>>>> Richard, > >>>>> > >>>>> On 22.10.2012 17:38, Richard Bair wrote: > >>>>>> MyObject obj = new MyObject(); > >>>>>> obj = BlackMagic.makeObservable(obj); > >>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) > >>>>> > >>>>>> However, the javafx beans package and collections and such are part > >>>>>> of the "base" module -- ie: they could be separated from the rest of > >>>>>> javafx and safely used on the server side or elsewhere. Why not just > >>>>>> use properties and such on the server side definition of classes? Or > >>>>>> are those classes being auto-generated and thus not taking > observable > >>>>>> properties into account? > >>>>> Currently I want to avoid requiring customers to install the FX > >>>>> runtime > >>>>> serverside. That will be a moot point with JRE 7+. Which does not > help > >>>>> the 6.x customers, especially if they are on WebLogic which is > usually > >>>>> tied to a specific major version. > >>>>> > >>>>> Another aspect is the footprint regarding memory and bandwidth. > >>>>> Obviously a StringProperty requires more bytes than a String. This is > >>>>> not an issue (usually) when I want to display a relatively short > >>>>> list of > >>>>> beans in the UI. It gets noticeable when the server suddenly needs +X > >>>>> megabytes, the instantion of objects needs +Y ms (also affects > >>>>> deserialization), and sending them over the network takes +Z ms... > >>>>> > >>>>> Werner > >>>> > >>>> -- > >>>> B e s t S o l u t i o n . a t EDV Systemhaus > >>>> GmbH > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> tom schindl gesch?ftsf?hrer/CEO > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 > >>>> 935833 > >>>> http://www.BestSolution.at phone ++43 512 > >>>> 935834 > >> > > > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 > From michael.heinrichs at oracle.com Mon Oct 29 01:30:24 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Mon, 29 Oct 2012 09:30:24 +0100 Subject: No SimpleStringProperty.bind(Property, StringConverter) method In-Reply-To: <50718800.3000607@googlemail.com> References: <50718800.3000607@googlemail.com> Message-ID: <9EF8CFA7-B2B6-418E-92D5-CAF6038DE262@oracle.com> Hi Andy, are you trying to mix regular bindings and bidirectional bindings? This does not work and will cause Exceptions like the one below. I am not sure, what you are trying to achieve. It is unusual to bind the text property of a TextField with a regular binding, because that means the content cannot be modified by the user anymore. Is that what you are trying to do? If you want to bind a StringProperty to an IntegerProperty, there are a number of possibilities how to do that. The IntegerProperty has methods asString() which you can use with or without a formatting String. And then there is Bindings.convert(), Bindings.concat(), and Bindings.format(), each one offers slightly different functionality. Cheers, Michael On 07.10.2012, at 15:47, Andy Till wrote: > Is there a reason why no SimpleStringProperty.bind(Property, StringConverter) exists but SimpleStringProperty.bindBidirectional(Property, StringConverter) does or is this just an omission that I could perhaps request to be implemented? > > I have a SimpleIntegerProperty that is bound to a NumberBinding. A TextField.textProperty is then bound to the SimpleIntegerProperty but it throws the following exception: > > java.lang.RuntimeException: A bound value cannot be set. > at javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:159) > at javafx.beans.property.IntegerProperty.setValue(IntegerProperty.java:80) > at javafx.beans.property.IntegerProperty.setValue(IntegerProperty.java:72) > at com.sun.javafx.binding.BidirectionalBinding$StringConversionBidirectionalBinding.changed(BidirectionalBinding.java:550) > at com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:367) > at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:100) > at javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1034) > at javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1038) > at javafx.scene.control.TextInputControl$TextProperty.invalidate(TextInputControl.java:978) > at javafx.scene.control.TextInputControl$TextProperty.access$200(TextInputControl.java:950) > at javafx.scene.control.TextInputControl$1.invalidated(TextInputControl.java:119) > at com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:155) > at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:100) > at javafx.scene.control.TextField$TextFieldContent.insert(TextField.java:79) > at javafx.scene.control.TextInputControl$TextProperty.doSet(TextInputControl.java:1047) > at javafx.scene.control.TextInputControl$TextProperty.set(TextInputControl.java:973) > at javafx.scene.control.TextInputControl$TextProperty.set(TextInputControl.java:950) > at javafx.beans.property.StringProperty.setValue(StringProperty.java:84) > at javafx.beans.property.StringProperty.setValue(StringProperty.java:76) > at com.sun.javafx.binding.BidirectionalBinding.bind(BidirectionalBinding.java:108) > at javafx.beans.binding.Bindings.bindBidirectional(Bindings.java:655) > at javafx.beans.property.StringProperty.bindBidirectional(StringProperty.java:128) From michael.heinrichs at oracle.com Mon Oct 29 01:58:34 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Mon, 29 Oct 2012 09:58:34 +0100 Subject: Making JavaFX Development Faster In-Reply-To: <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> Message-ID: <82FD4F85-D5E4-4654-BE22-0E67AD0ED5A7@oracle.com> Hi Richard, the Java Bean adapters use Cleaners to unregister themselves from the Java Bean once they are ready to be GCed. If necessary this can easily be rewritten to use finalizers instead. - Michael On 27.10.2012, at 15:24, Richard Bair wrote: > I cannot imagine what internal stuff Michael could be using or when that was added. > > On Oct 26, 2012, at 7:42 AM, Tom Schindl wrote: > >> Not only the memory argument is import. >> >> What if a customer says i have to run on his j9-jvm? >> >> I can be wrong but IIRC Michael told me at JavaOne that the properties >> code is even using internal (sun....) stuff so even simply dropping in >> the jar to the j9 classpath is doomed to fail. >> >> And beside that using FX-Observables and e.g. JPA don't like each other >> i guess because of all those lazy list stuff, ... . >> >> Tom >> >> Am 22.10.12 19:23, schrieb Werner Lehmann: >>> Richard, >>> >>> On 22.10.2012 17:38, Richard Bair wrote: >>>> MyObject obj = new MyObject(); >>>> obj = BlackMagic.makeObservable(obj); >>> >>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?) >>> >>>> However, the javafx beans package and collections and such are part >>>> of the "base" module -- ie: they could be separated from the rest of >>>> javafx and safely used on the server side or elsewhere. Why not just >>>> use properties and such on the server side definition of classes? Or >>>> are those classes being auto-generated and thus not taking observable >>>> properties into account? >>> >>> Currently I want to avoid requiring customers to install the FX runtime >>> serverside. That will be a moot point with JRE 7+. Which does not help >>> the 6.x customers, especially if they are on WebLogic which is usually >>> tied to a specific major version. >>> >>> Another aspect is the footprint regarding memory and bandwidth. >>> Obviously a StringProperty requires more bytes than a String. This is >>> not an issue (usually) when I want to display a relatively short list of >>> beans in the UI. It gets noticeable when the server suddenly needs +X >>> megabytes, the instantion of objects needs +Y ms (also affects >>> deserialization), and sending them over the network takes +Z ms... >>> >>> Werner >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 From pavel.safrata at oracle.com Mon Oct 29 04:49:44 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 29 Oct 2012 12:49:44 +0100 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <508ABD28.6080402@oracle.com> References: <5086FE81.8000601@oracle.com> <508A8D13.6030808@oracle.com> <508ABD28.6080402@oracle.com> Message-ID: <508E6D58.3050301@oracle.com> Hi Steve, On 26.10.2012 18:41, steve.x.northover at oracle.com wrote: > Hi Pavel! > > > the inheritance ignoring reparenting. > > I don't think this was explained well in the documentation. There > should be no difference in visual behavior for the final result with > respect to the ordering of "orientate" and "insert" operations. It seems to be explained well. This is how I understand it, please tell me which of the two statements is incorrect and why: I have a left-to-right parent with an inheriting child. I create new parent, "orientate" it to right-to-left and "insert" it between the original parent and the child. Based on "If an application explicitly sets the root of a hierarchy to left-to-right and then reparents the hierarchy into a parent that is right-to-left, the hierarchy will remain left-to-right" I understand that the child will remain left-to-right. Again, I have a left-to-right parent with an inheriting child. I create a new parent and "insert" it between the original parent and the child. Then I "orientate" it to right-to-left. Based on "Inheritance of node orientation allows application developers to specify the orientation of a root node and have it apply to all children" I understand that the new orientation will be applied to the child, so it will become right-to-left. > > > How will mirroring cooperate with transformations? > > The mirroring transformation is transparent to the application and is > included automatically in local-to-scene (it's a bug if it is not). A > public Mirror (or rather Flip) transformation would provide API for > this transformation, but I'm not sure why we would need to do this. Ah, that sounds quite good. The only thing that slightly bothers me is the state where there are no transformations anywhere and local-to-scene transform still reports it is not an identity transform, which seems confusing. But perhaps I'm too picky. > > > Shouldn't effectiveNodeOrientation be a property? > > That's a possibility. It would be a properly that changed when > inherited orientation up the ancestor tree changed. Do we have any > other properties like this in FX? localToSceneTransform :-) But I admit there is some extra logic needed for such properties that we don't want to add blindly for performance reasons. So it may be better to just rename the getter to simply effectiveNodeOrientation(). > > > The same applies to isAutomaticallyMirrored. > > This is a mechanism that allows controls to opt out of mirroring. > Conceptually, it should be "... set once in the constructor and never > changed...". I am not particularly happy with this method. Do you > have a better suggestion? I've just discussed it locally, there are other options but not particularly nice as well. Guys here also prefer your solution because there is no need to store the value. So I'm withdrawing my objections, however, we believe that the method - needs a better documentation that will state explicitly that it's supposed to return a constant - should be protected (is there any reason for it to be public?) - needs a name that doesn't start with "get" or "is" > > > Could you please elaborate on "the application will need to > configure parameters that are appropriate for the effect in both > orientations"? > > For example, if you want a light source effect to come from the upper > left corner when a control is RTL, you will need to create an effect > where the light source comes from the upper right corner so that when > the control is mirrored, it will come from the left. Hmm, I would prefer to do that automatically, I don't think anybody wants the reversed shadow just because the reading direction is different. But it looks like it would require serious rework of effects which is probably not feasible.. Pavel > > Steve > > On 26/10/2012 9:16 AM, Pavel Safrata wrote: >> Hi Steve, >> I have a few comments/questions. >> >> I'm not sure about the inheritance ignoring reparenting. I think that >> if an application will use orientation extensively it will reach a >> hard-to-trace "mess state" where most of the nodes "inherit" but they >> don't actually have the parent's value. Also it means that peforming >> "orientate parent" - "insert it into scene" will result in a >> different behavior than "insert" first and then "orientate", which >> seems confusing. What if I create a new node and insert it into >> scene, will it inherit form its new parent? In summary, I find this >> behavior hard to track and I think that when the value is Inherit it >> should always match the parent's orientation. >> >> How will mirroring cooperate with transformations? For instance user >> can obtain local-to-scene transformation and if the mirrorring is not >> contained there, the computations with the transform (such as >> transforming points) will be wrong. Maybe we could just introduce a >> public Mirror (or rather Flip) transformation and use it publicly for >> the mirrorring? >> >> How will it behave in 3D? Mirror nodes along X axis regardless of >> their z-direction volume? >> >> Shouldn't effectiveNodeOrientation be a property? It seems it might >> make sense to observe the value. Also our naming convention is that >> you should not use getSomthing unless "something" is a property. >> >> The same applies to isAutomaticallyMirrored. This method seems weird >> anyway. When and how often is it called? Can a node change the value >> dynamically? If yes, we should have a property, if not, we should >> make sure it doesn't - let the node call some init method in the >> constructor or something like that. >> >> Could you please elaborate on "the application will need to configure >> parameters that are appropriate for the effect in both orientations"? >> How do I drop the shadow to the same direction for all nodes, >> specifically? >> >> Thanks, >> Pavel >> >> On 23.10.2012 22:30, steve.x.northover at oracle.com wrote: >>> Hi all, >>> >>> I have been looking into Node Orientation which is an API that >>> controls the directionality of a Node. This is different from BIDI >>> or the BIDI algorithm which governs the direction of text. Node >>> orientation concerns the flow of visual data which is either >>> left-to-right or right-to-left. The best example is a tree >>> control. In tree control that is oriented right-to-left, the >>> expansion arrows point to the right and the branches of the tree >>> expand from the right to the left. >>> >>> https://wikis.oracle.com/display/OpenJDK/Node+Orientation+in+JavaFX >>> >>> Steve >> From lehmann at media-interactive.de Mon Oct 29 05:29:01 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 29 Oct 2012 13:29:01 +0100 Subject: MenuButton arrow position In-Reply-To: References: <50867918.5060403@media-interactive.de> Message-ID: <508E768D.5020601@media-interactive.de> Hi Richard, I filed a bug for this: http://javafx-jira.kenai.com/browse/RT-25879 Probably the arrow is positioned like this because it makes sense for the SplitMenuButton. However, without a "split"... We could work around it with some css. Not pretty but functional for now. By the way, there is some curious difference to the ContextMenu internally used by the MenuButton. In a JFXPanel, a ContextMenu does not autoHide if the users click on some unrelated Swing component. With the MenuButton context menu, autoHide works(*) (see also RT-19953). Any idea why? I am hoping to get this for my own ContextMenu and other popups as well... Werner (*) works to some extent, moving the JFrame from underneath the menu still does not autoHide it but that is less important On 26.10.2012 17:22, Richard Bair wrote: > MenuButton does not play nice if the graphic is displayed TOP or > BOTTOM:http://www.imagebam.com/image/8c4a8b216588054 >> >> Usually the arrow button is located to the right of the button >> text. Instead it is on the far right side, with too much gap in >> between. From steve.x.northover at oracle.com Mon Oct 29 08:17:24 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 29 Oct 2012 11:17:24 -0400 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <508E6D58.3050301@oracle.com> References: <5086FE81.8000601@oracle.com> <508A8D13.6030808@oracle.com> <508ABD28.6080402@oracle.com> <508E6D58.3050301@oracle.com> Message-ID: <508E9E04.10209@oracle.com> On 29/10/2012 7:49 AM, Pavel Safrata wrote: > Hi Steve, > > On 26.10.2012 18:41, steve.x.northover at oracle.com wrote: >> Hi Pavel! >> >> > the inheritance ignoring reparenting. >> >> I don't think this was explained well in the documentation. There >> should be no difference in visual behavior for the final result with >> respect to the ordering of "orientate" and "insert" operations. > > It seems to be explained well. This is how I understand it, please > tell me which of the two statements is incorrect and why: > > I have a left-to-right parent with an inheriting child. I create new > parent, "orientate" it to right-to-left and "insert" it between the > original parent and the child. Based on "If an application explicitly > sets the root of a hierarchy to left-to-right and then reparents the > hierarchy into a parent that is right-to-left, the hierarchy will > remain left-to-right" I understand that the child will remain > left-to-right. > > Again, I have a left-to-right parent with an inheriting child. I > create a new parent and "insert" it between the original parent and > the child. Then I "orientate" it to right-to-left. Based on > "Inheritance of node orientation allows application developers to > specify the orientation of a root node and have it apply to all > children" I understand that the new orientation will be applied to the > child, so it will become right-to-left. > The second statement is true. The behavior can be summarized as: "When not explicitly set, orientation is inherited". I'm not sure about the confusion in the first statement. The sentence is meant to mean that a hierarchy of nodes with an explicitly set root will always have the explicitly set orientation of the root no matter where the root is reparented. Perhaps I should delete the sentence and replace it with something like what I just said. >> >> > How will mirroring cooperate with transformations? >> >> The mirroring transformation is transparent to the application and is >> included automatically in local-to-scene (it's a bug if it is not). >> A public Mirror (or rather Flip) transformation would provide API for >> this transformation, but I'm not sure why we would need to do this. > > Ah, that sounds quite good. The only thing that slightly bothers me is > the state where there are no transformations anywhere and > local-to-scene transform still reports it is not an identity > transform, which seems confusing. But perhaps I'm too picky. > >> >> > Shouldn't effectiveNodeOrientation be a property? >> >> That's a possibility. It would be a properly that changed when >> inherited orientation up the ancestor tree changed. Do we have any >> other properties like this in FX? > > localToSceneTransform :-) But I admit there is some extra logic needed > for such properties that we don't want to add blindly for performance > reasons. So it may be better to just rename the getter to simply > effectiveNodeOrientation(). > It might be that this needs to be a property after all. The issue is that a child may have state that is sets based on effective orientation (say alignment of a text node) and this state needs to be kept up to date with effective orientation. However, providing the method is defined correctly, there is nothing stopping it from becoming a property in future. I understand the performance issue. I will investigate further. >> >> > The same applies to isAutomaticallyMirrored. >> >> This is a mechanism that allows controls to opt out of mirroring. >> Conceptually, it should be "... set once in the constructor and never >> changed...". I am not particularly happy with this method. Do you >> have a better suggestion? > > I've just discussed it locally, there are other options but not > particularly nice as well. Guys here also prefer your solution because > there is no need to store the value. So I'm withdrawing my objections, > however, we believe that the method > - needs a better documentation that will state explicitly that it's > supposed to return a constant > - should be protected (is there any reason for it to be public?) > - needs a name that doesn't start with "get" or "is" I will update the documentation to be better. Can you show me other examples where the "get" and "is" are not used in FX where they might normally be used? I am not a fan of protected. Other than indicating explicitly that subclasses are supposed to override this method, are there any other benefits? > >> >> > Could you please elaborate on "the application will need to >> configure parameters that are appropriate for the effect in both >> orientations"? >> >> For example, if you want a light source effect to come from the upper >> left corner when a control is RTL, you will need to create an effect >> where the light source comes from the upper right corner so that when >> the control is mirrored, it will come from the left. > > Hmm, I would prefer to do that automatically, I don't think anybody > wants the reversed shadow just because the reading direction is > different. But it looks like it would require serious rework of > effects which is probably not feasible.. This issue is this: You can't know what the application wants. In some cases, it is using an effect as part of a control theme and it makes sense for the effect to go from right-to-left when the orientation changes. In other cases, there is directionality involved that should remain constant (like the car example in the documentation). > > Pavel > >> >> Steve >> >> On 26/10/2012 9:16 AM, Pavel Safrata wrote: >>> Hi Steve, >>> I have a few comments/questions. >>> >>> I'm not sure about the inheritance ignoring reparenting. I think >>> that if an application will use orientation extensively it will >>> reach a hard-to-trace "mess state" where most of the nodes "inherit" >>> but they don't actually have the parent's value. Also it means that >>> peforming "orientate parent" - "insert it into scene" will result in >>> a different behavior than "insert" first and then "orientate", which >>> seems confusing. What if I create a new node and insert it into >>> scene, will it inherit form its new parent? In summary, I find this >>> behavior hard to track and I think that when the value is Inherit it >>> should always match the parent's orientation. >>> >>> How will mirroring cooperate with transformations? For instance user >>> can obtain local-to-scene transformation and if the mirrorring is >>> not contained there, the computations with the transform (such as >>> transforming points) will be wrong. Maybe we could just introduce a >>> public Mirror (or rather Flip) transformation and use it publicly >>> for the mirrorring? >>> >>> How will it behave in 3D? Mirror nodes along X axis regardless of >>> their z-direction volume? >>> >>> Shouldn't effectiveNodeOrientation be a property? It seems it might >>> make sense to observe the value. Also our naming convention is that >>> you should not use getSomthing unless "something" is a property. >>> >>> The same applies to isAutomaticallyMirrored. This method seems weird >>> anyway. When and how often is it called? Can a node change the value >>> dynamically? If yes, we should have a property, if not, we should >>> make sure it doesn't - let the node call some init method in the >>> constructor or something like that. >>> >>> Could you please elaborate on "the application will need to >>> configure parameters that are appropriate for the effect in both >>> orientations"? How do I drop the shadow to the same direction for >>> all nodes, specifically? >>> >>> Thanks, >>> Pavel >>> >>> On 23.10.2012 22:30, steve.x.northover at oracle.com wrote: >>>> Hi all, >>>> >>>> I have been looking into Node Orientation which is an API that >>>> controls the directionality of a Node. This is different from BIDI >>>> or the BIDI algorithm which governs the direction of text. Node >>>> orientation concerns the flow of visual data which is either >>>> left-to-right or right-to-left. The best example is a tree >>>> control. In tree control that is oriented right-to-left, the >>>> expansion arrows point to the right and the branches of the tree >>>> expand from the right to the left. >>>> >>>> https://wikis.oracle.com/display/OpenJDK/Node+Orientation+in+JavaFX >>>> >>>> Steve >>> > From hang.vo at oracle.com Mon Oct 29 12:18:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 29 Oct 2012 19:18:27 +0000 Subject: hg: openjfx/8/controls/rt: RT-25181: Virtual Keboard is hiding text input. Added a system property -Dcom.sun.javafx.fxvkContainerType=inScene to place the vk in the app scene instead of in a popup. Supports automatic and manual scrolling. Message-ID: <20121029191832.496FB47652@hg.openjdk.java.net> Changeset: dbd6d178b5dd Author: leifs Date: 2012-10-29 12:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dbd6d178b5dd RT-25181: Virtual Keboard is hiding text input. Added a system property -Dcom.sun.javafx.fxvkContainerType=inScene to place the vk in the app scene instead of in a popup. Supports automatic and manual scrolling. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java From kevin.rushforth at oracle.com Mon Oct 29 14:52:04 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Oct 2012 14:52:04 -0700 Subject: Black Background behind MediaView Replicating 3D Movie Cube In-Reply-To: References: Message-ID: <508EFA84.3000105@oracle.com> The "MediaCube" demo we showed just uses a gradient "fill" on the Scene, but you should be able to achieve the same thing with a Rectangle of your own. You just need to turn off depth test on that rectangle. -- Kevin Peter Pilgrim wrote: > Hi > > This is nothing to do with OpenJFX codebase or anything else > > I was working on ScalaFX just now. Writing a port of the CubeSystem > Graphic 3D with MediaView instead of Rectangles. I am using my own > downloaded movie trailers e.g. The Hobbit, Prometheus, Looper, Flight > etc > > I want to give the MediaView a black background for the videos, keep > the aspect ratio, and effectively give each cube a backing rectangle, > so I naively did > > MediaViewCubeFace(val size: Double) extends Group { > val backRect: Rectangle { fill = Color.Black } > val mediaView: MediaView { fitWidth = size; fitHeight = size } > Group { > children = Seq( backRect, mediaView) > } > > /* ... */ > } > > None of the above compiles, does not matter. What I found was on > MacOS 10.8 Retine Display Java FX 7 update 9 there is a lot of > flickering? > "So I think I must be doing this wrong?" The media view rendered with > the rectangle in front and sometimes behind. DepthTest is switched on. > I tried setting a backRect.translateZ = -0.05 and that makes the > problem worse. So there something I don't understand about 3D, can't > put my finger on it. > > What did the JavaFX SDK team do to in the JavaOne (2011) demo? Did you > put the MediaView inside a Pane or something else? > > From kevin.rushforth at oracle.com Mon Oct 29 17:08:23 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Oct 2012 17:08:23 -0700 Subject: How does JFX work get prioritised? In-Reply-To: References: Message-ID: <508F1A77.3080203@oracle.com> I'll take the heat for this one. I just bulk removed the "Lombard" release for all Feature JIRAs (as opposed to Tweaks) that are not part of the list of accepted features for the release, without too much thought behind it. One reason for doing this is to not leave the false impression that they are being actively worked on, so that people can either set their expectations appropriately or lobby for it being included. Based on your e-mail, the number of votes on this issue, and a couple private e-mails I received, it seems like this is something we should explicitly reconsider. -- Kevin Daniel Zwolenski wrote: > Is it possible for someone from the Oracle JFX team to outline how features > get prioritised for inclusion in a release? > > I've been frustrated at times with things I think I are important not > getting done, and I think a few others have had similar > experiences. Obviously all of us think our bug/feature is the most > important thing, and not everything can get done and there has to be > priorities. I think it would be less frustrating though if we actually knew > the process that was used to prioritise issues - who decides, and what > metrics are used as input? > > I noted today for example, that > RT-10376, > which is simply to allow maximising the stage programmatically, just got > bumped so its not part of Java8 and is not part of any foreseeable > release. I personally don't care about this feature so much, but it does > look like a pretty fundamental, basic thing for a windowing toolkit to > have, so highlights the general point: > > - It was raised as a "critical feature" by Jasper Potts, so it doesn't > seem a case of not being recognised as important within Oracle. > - It was raised back in 2010 so it doesn't seem a case of it coming in > too late and just not making the cut for the release. > - Based on comments from Anthony Petrov it seems to be already mostly > implemented and just needs to be hooked in, so I'm assuming it's not really > a big resourcing issue. > - It's got 28 votes from the community, placing it at #8 in the most > voted list by my reckoning, so there's no lack of community interest in the > issue (3D geometry support has 12 votes for example). > > >From my vantage point, it's difficult to see why a feature like this > wouldn't have been done months ago, let alone be off the road map > completely, especially when you consider some of the more obscure features > on the roadmap. Confusion over something like this, for me at least, > festers into a general distrust in the process, which results in > frustration around other issues I do consider important (like > build/deployment). > > Can this confusion be lessened through some better communication? Is it > possible to explain how, in this case and in general, you guys prioritise > JavaFX work? > From zonski at gmail.com Mon Oct 29 17:38:04 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 30 Oct 2012 11:38:04 +1100 Subject: How does JFX work get prioritised? In-Reply-To: <508F1A77.3080203@oracle.com> References: <508F1A77.3080203@oracle.com> Message-ID: Good to know, but I was just using this issue to frame the question: what's the process you use to determine what's in or out? When you "reconsider" this, who will be doing the reconsidering, and what will be the determining factor of whether it is in or out? e.g. is each developer or sub-team free to pick their priorities or do they come from a marketing team or a high-level management crew? Maybe there's a committee that meets once a week, month, whatever? What input do the decision makers look at when deciding, are they using solid metrics from market research, surveys, community feedback, etc, or is it more of a gut-feel thing? You mention "lobbying". What form of lobbying? What priority do JIRA votes get (traditionally none) vs "private emails", OTN forum posts, or feet stamping and generally being annoying on this mailing list (that hasn't worked for me though ;) ). Does lobbying from certain users (e.g. oracle customers) or types of users (e.g. established corporates vs "I'm a developer") get more weight than others - if so what's the weighting (how many noisy plebs does it take to balance out large corporate)? Any chance we could get some insight on any of that? On Tue, Oct 30, 2012 at 11:08 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I'll take the heat for this one. I just bulk removed the "Lombard" release > for all Feature JIRAs (as opposed to Tweaks) that are not part of the list > of accepted features for the release, without too much thought behind it. > One reason for doing this is to not leave the false impression that they > are being actively worked on, so that people can either set their > expectations appropriately or lobby for it being included. > > Based on your e-mail, the number of votes on this issue, and a couple > private e-mails I received, it seems like this is something we should > explicitly reconsider. > > -- Kevin > > > Daniel Zwolenski wrote: > >> Is it possible for someone from the Oracle JFX team to outline how >> features >> get prioritised for inclusion in a release? >> >> I've been frustrated at times with things I think I are important not >> getting done, and I think a few others have had similar >> experiences. Obviously all of us think our bug/feature is the most >> important thing, and not everything can get done and there has to be >> priorities. I think it would be less frustrating though if we actually >> knew >> the process that was used to prioritise issues - who decides, and what >> metrics are used as input? >> >> I noted today for example, that >> RT-10376 >> >, >> >> which is simply to allow maximising the stage programmatically, just got >> bumped so its not part of Java8 and is not part of any foreseeable >> release. I personally don't care about this feature so much, but it does >> look like a pretty fundamental, basic thing for a windowing toolkit to >> have, so highlights the general point: >> >> - It was raised as a "critical feature" by Jasper Potts, so it doesn't >> >> seem a case of not being recognised as important within Oracle. >> - It was raised back in 2010 so it doesn't seem a case of it coming in >> too late and just not making the cut for the release. >> - Based on comments from Anthony Petrov it seems to be already mostly >> >> implemented and just needs to be hooked in, so I'm assuming it's not >> really >> a big resourcing issue. >> - It's got 28 votes from the community, placing it at #8 in the most >> >> voted list by my reckoning, so there's no lack of community interest >> in the >> issue (3D geometry support has 12 votes for example). >> >> >From my vantage point, it's difficult to see why a feature like this >> wouldn't have been done months ago, let alone be off the road map >> completely, especially when you consider some of the more obscure features >> on the roadmap. Confusion over something like this, for me at least, >> festers into a general distrust in the process, which results in >> frustration around other issues I do consider important (like >> build/deployment). >> >> Can this confusion be lessened through some better communication? Is it >> possible to explain how, in this case and in general, you guys prioritise >> JavaFX work? >> >> > From kevin.rushforth at oracle.com Mon Oct 29 17:41:04 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Oct 2012 17:41:04 -0700 Subject: How does JFX work get prioritised? In-Reply-To: References: <508F1A77.3080203@oracle.com> Message-ID: <508F2220.6080905@oracle.com> Richard Bair should answer the more general question you raised. -- Kevin Daniel Zwolenski wrote: > Good to know, but I was just using this issue to frame the question: > what's the process you use to determine what's in or out? When you > "reconsider" this, who will be doing the reconsidering, and what will > be the determining factor of whether it is in or out? > > e.g. is each developer or sub-team free to pick their priorities or do > they come from a marketing team or a high-level management crew? Maybe > there's a committee that meets once a week, month, whatever? What > input do the decision makers look at when deciding, are they using > solid metrics from market research, surveys, community feedback, etc, > or is it more of a gut-feel thing? > > You mention "lobbying". What form of lobbying? What priority do JIRA > votes get (traditionally none) vs "private emails", OTN forum posts, > or feet stamping and generally being annoying on this mailing list > (that hasn't worked for me though ;) ). Does lobbying from certain > users (e.g. oracle customers) or types of users (e.g. > established corporates vs "I'm a developer") get more weight than > others - if so what's the weighting (how many noisy plebs does it take > to balance out large corporate)? > > Any chance we could get some insight on any of that? > > > > On Tue, Oct 30, 2012 at 11:08 AM, Kevin Rushforth > > wrote: > > I'll take the heat for this one. I just bulk removed the "Lombard" > release for all Feature JIRAs (as opposed to Tweaks) that are not > part of the list of accepted features for the release, without too > much thought behind it. One reason for doing this is to not leave > the false impression that they are being actively worked on, so > that people can either set their expectations appropriately or > lobby for it being included. > > Based on your e-mail, the number of votes on this issue, and a > couple private e-mails I received, it seems like this is something > we should explicitly reconsider. > > -- Kevin > > > Daniel Zwolenski wrote: > > Is it possible for someone from the Oracle JFX team to outline > how features > get prioritised for inclusion in a release? > > I've been frustrated at times with things I think I are > important not > getting done, and I think a few others have had similar > experiences. Obviously all of us think our bug/feature is the most > important thing, and not everything can get done and there has > to be > priorities. I think it would be less frustrating though if we > actually knew > the process that was used to prioritise issues - who decides, > and what > metrics are used as input? > > I noted today for example, that > RT-10376, > > which is simply to allow maximising the stage > programmatically, just got > bumped so its not part of Java8 and is not part of any foreseeable > release. I personally don't care about this feature so much, > but it does > look like a pretty fundamental, basic thing for a windowing > toolkit to > have, so highlights the general point: > > - It was raised as a "critical feature" by Jasper Potts, so > it doesn't > > seem a case of not being recognised as important within Oracle. > - It was raised back in 2010 so it doesn't seem a case of > it coming in > too late and just not making the cut for the release. > - Based on comments from Anthony Petrov it seems to be > already mostly > > implemented and just needs to be hooked in, so I'm assuming > it's not really > a big resourcing issue. > - It's got 28 votes from the community, placing it at #8 in > the most > > voted list by my reckoning, so there's no lack of community > interest in the > issue (3D geometry support has 12 votes for example). > > >From my vantage point, it's difficult to see why a feature > like this > wouldn't have been done months ago, let alone be off the road map > completely, especially when you consider some of the more > obscure features > on the roadmap. Confusion over something like this, for me at > least, > festers into a general distrust in the process, which results in > frustration around other issues I do consider important (like > build/deployment). > > Can this confusion be lessened through some better > communication? Is it > possible to explain how, in this case and in general, you guys > prioritise > JavaFX work? > > > From pavel.safrata at oracle.com Tue Oct 30 03:41:31 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 30 Oct 2012 11:41:31 +0100 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <508E9E04.10209@oracle.com> References: <5086FE81.8000601@oracle.com> <508A8D13.6030808@oracle.com> <508ABD28.6080402@oracle.com> <508E6D58.3050301@oracle.com> <508E9E04.10209@oracle.com> Message-ID: <508FAEDB.90600@oracle.com> Hi Steve, On 29.10.2012 16:17, steve.x.northover at oracle.com wrote: > > > On 29/10/2012 7:49 AM, Pavel Safrata wrote: >> Hi Steve, >> >> On 26.10.2012 18:41, steve.x.northover at oracle.com wrote: >>> Hi Pavel! >>> >>> > the inheritance ignoring reparenting. >>> >>> I don't think this was explained well in the documentation. There >>> should be no difference in visual behavior for the final result with >>> respect to the ordering of "orientate" and "insert" operations. >> >> It seems to be explained well. This is how I understand it, please >> tell me which of the two statements is incorrect and why: >> >> I have a left-to-right parent with an inheriting child. I create new >> parent, "orientate" it to right-to-left and "insert" it between the >> original parent and the child. Based on "If an application explicitly >> sets the root of a hierarchy to left-to-right and then reparents the >> hierarchy into a parent that is right-to-left, the hierarchy will >> remain left-to-right" I understand that the child will remain >> left-to-right. >> >> Again, I have a left-to-right parent with an inheriting child. I >> create a new parent and "insert" it between the original parent and >> the child. Then I "orientate" it to right-to-left. Based on >> "Inheritance of node orientation allows application developers to >> specify the orientation of a root node and have it apply to all >> children" I understand that the new orientation will be applied to >> the child, so it will become right-to-left. >> > > The second statement is true. The behavior can be summarized as: > "When not explicitly set, orientation is inherited". I'm not sure > about the confusion in the first statement. The sentence is meant to > mean that a hierarchy of nodes with an explicitly set root will always > have the explicitly set orientation of the root no matter where the > root is reparented. Perhaps I should delete the sentence and replace > it with something like what I just said. Got it. The confusion is that you mean reparenting the hierarchy including the root, I thought you meant leaving the root on place and reparenting its children to a different root. So I think it is ok (but yes, rewording the sentence may be useful, I'm not the only one to understand it that way). > >>> >>> > How will mirroring cooperate with transformations? >>> >>> The mirroring transformation is transparent to the application and >>> is included automatically in local-to-scene (it's a bug if it is >>> not). A public Mirror (or rather Flip) transformation would provide >>> API for this transformation, but I'm not sure why we would need to >>> do this. >> >> Ah, that sounds quite good. The only thing that slightly bothers me >> is the state where there are no transformations anywhere and >> local-to-scene transform still reports it is not an identity >> transform, which seems confusing. But perhaps I'm too picky. >> >>> >>> > Shouldn't effectiveNodeOrientation be a property? >>> >>> That's a possibility. It would be a properly that changed when >>> inherited orientation up the ancestor tree changed. Do we have any >>> other properties like this in FX? >> >> localToSceneTransform :-) But I admit there is some extra logic >> needed for such properties that we don't want to add blindly for >> performance reasons. So it may be better to just rename the getter to >> simply effectiveNodeOrientation(). >> > > It might be that this needs to be a property after all. The issue is > that a child may have state that is sets based on effective > orientation (say alignment of a text node) and this state needs to be > kept up to date with effective orientation. However, providing the > method is defined correctly, there is nothing stopping it from > becoming a property in future. I understand the performance issue. I > will investigate further. For a property we'd have effectiveNodeOrientationProperty() and getEffectiveNodeOrientation(). For a non-property we'd have something like effectiveNodeOrientation(). So I think we need to decide in the beginning.. > >>> >>> > The same applies to isAutomaticallyMirrored. >>> >>> This is a mechanism that allows controls to opt out of mirroring. >>> Conceptually, it should be "... set once in the constructor and >>> never changed...". I am not particularly happy with this method. Do >>> you have a better suggestion? >> >> I've just discussed it locally, there are other options but not >> particularly nice as well. Guys here also prefer your solution >> because there is no need to store the value. So I'm withdrawing my >> objections, however, we believe that the method >> - needs a better documentation that will state explicitly that it's >> supposed to return a constant >> - should be protected (is there any reason for it to be public?) >> - needs a name that doesn't start with "get" or "is" > > I will update the documentation to be better. Can you show me other > examples where the "get" and "is" are not used in FX where they might > normally be used? For instance Point2D.magnitude() or Transform.determinant(). This is for the compatibility with tools and IDEs that use the naming to determine if it is a property or not. > I am not a fan of protected. Other than indicating explicitly that > subclasses are supposed to override this method, are there any other > benefits? I believe it is a good approach not to publish things that don't need to be public. It is a node implementation thing, it should not confuse users in the list of publicly accessible methods. Other than you not being a fan, are there any concrete reasons for it to be public? (the fan thing doesn't leave much room for discussion) > >> >>> >>> > Could you please elaborate on "the application will need to >>> configure parameters that are appropriate for the effect in both >>> orientations"? >>> >>> For example, if you want a light source effect to come from the >>> upper left corner when a control is RTL, you will need to create an >>> effect where the light source comes from the upper right corner so >>> that when the control is mirrored, it will come from the left. >> >> Hmm, I would prefer to do that automatically, I don't think anybody >> wants the reversed shadow just because the reading direction is >> different. But it looks like it would require serious rework of >> effects which is probably not feasible.. > > This issue is this: You can't know what the application wants. In > some cases, it is using an effect as part of a control theme and it > makes sense for the effect to go from right-to-left when the > orientation changes. In other cases, there is directionality involved > that should remain constant (like the car example in the documentation). I think that effects are quite independent of what the application wants. The reflection always has to reflect the rendered node (having a right-to-left node with left-to-right reflection doesn't make any sense), and I think shadow is always dropped the same way based on the light source, regardless of it being right-to-left text or a car door. But again, I don't see any reasonable way to implement this right now. Pavel > >> >> Pavel >> >>> >>> Steve >>> >>> On 26/10/2012 9:16 AM, Pavel Safrata wrote: >>>> Hi Steve, >>>> I have a few comments/questions. >>>> >>>> I'm not sure about the inheritance ignoring reparenting. I think >>>> that if an application will use orientation extensively it will >>>> reach a hard-to-trace "mess state" where most of the nodes >>>> "inherit" but they don't actually have the parent's value. Also it >>>> means that peforming "orientate parent" - "insert it into scene" >>>> will result in a different behavior than "insert" first and then >>>> "orientate", which seems confusing. What if I create a new node and >>>> insert it into scene, will it inherit form its new parent? In >>>> summary, I find this behavior hard to track and I think that when >>>> the value is Inherit it should always match the parent's orientation. >>>> >>>> How will mirroring cooperate with transformations? For instance >>>> user can obtain local-to-scene transformation and if the mirrorring >>>> is not contained there, the computations with the transform (such >>>> as transforming points) will be wrong. Maybe we could just >>>> introduce a public Mirror (or rather Flip) transformation and use >>>> it publicly for the mirrorring? >>>> >>>> How will it behave in 3D? Mirror nodes along X axis regardless of >>>> their z-direction volume? >>>> >>>> Shouldn't effectiveNodeOrientation be a property? It seems it might >>>> make sense to observe the value. Also our naming convention is that >>>> you should not use getSomthing unless "something" is a property. >>>> >>>> The same applies to isAutomaticallyMirrored. This method seems >>>> weird anyway. When and how often is it called? Can a node change >>>> the value dynamically? If yes, we should have a property, if not, >>>> we should make sure it doesn't - let the node call some init method >>>> in the constructor or something like that. >>>> >>>> Could you please elaborate on "the application will need to >>>> configure parameters that are appropriate for the effect in both >>>> orientations"? How do I drop the shadow to the same direction for >>>> all nodes, specifically? >>>> >>>> Thanks, >>>> Pavel >>>> >>>> On 23.10.2012 22:30, steve.x.northover at oracle.com wrote: >>>>> Hi all, >>>>> >>>>> I have been looking into Node Orientation which is an API that >>>>> controls the directionality of a Node. This is different from >>>>> BIDI or the BIDI algorithm which governs the direction of text. >>>>> Node orientation concerns the flow of visual data which is either >>>>> left-to-right or right-to-left. The best example is a tree >>>>> control. In tree control that is oriented right-to-left, the >>>>> expansion arrows point to the right and the branches of the tree >>>>> expand from the right to the left. >>>>> >>>>> https://wikis.oracle.com/display/OpenJDK/Node+Orientation+in+JavaFX >>>>> >>>>> Steve >>>> >> From java.whoover at gmail.com Tue Oct 30 05:28:21 2012 From: java.whoover at gmail.com (Will Hoover) Date: Tue, 30 Oct 2012 08:28:21 -0400 Subject: JPA properties In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> <508CDEC5.7030907@tbee.org> <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> <508CF2AD.40809@tbee.org> Message-ID: <508fc80c.0da1650a.2e6b.2de6@mx.google.com> I can see both sides of the argument for and against shared use of EMs across tiers. For me, the more fundamental issue is the need for a seamless approach that allows binding across any number of POJOs and their corresponding fields. I view the client as a container and should be treated accordingly. It shouldn't be concerned with "how" we give it data, but rather "what" data we give it. I understand the need for the bean properties in JFX, but I also believe their existence is due to the lack of a formal language-level observer apparatus on POJOs (rather than bytecode mangling or pseudo property classes). -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Sunday, October 28, 2012 7:44 AM To: Tom Eugelink Cc: openjfx-dev at openjdk.java.net Subject: Re: JPA properties Fair enough. Calling directly onto a database from the client is probably not an approach I would go for too often or recommend for a lot of use cases, but hey, if it works for you, great. All of my comments were with respect to a standard client-server, 3-tier, JEE architecture (but I don't use EJBs). I personally don't see observable properties being useful or desirable in the server side of this architecture (and would recommend a model for the client tier that is completely decoupled from the data tier, potentially with a DTO pattern at the service tier to transfer data between them). Probably all debating a mute point from JFX's perspective though - JFX properties are what they are and not likely to change. Use them on the server if you want, don't if you don't. On Sun, Oct 28, 2012 at 7:54 PM, Tom Eugelink wrote: > Ah. JPA not necessarily is used server only. The whole EJB setup is > very suited for webapps, but may not be the best setup for desktop > apps. The EJBs have some drawbacks (insert lenghty discussion here), > so I opted to create a business model that is distributed as a > standalone postprocessed jar. It is used in a Swing app, JSF2 webapp, > several batch processes for a.o. EDIFACT, email, etc. Each with their own entity manager approach. > > And in case of a Swing (JavaFX) app observable lists can be very handy. > > Tom > > > > On 2012-10-28 08:42, Daniel Zwolenski wrote: > >> I stand by my comments but looks like a case of personal preference. >> >> Curious though, what do you use observable properties for on the server? >> How are you leveraging them for an advantage? >> >> >> >> On 28/10/2012, at 6:29 PM, Tom Eugelink wrote: >> >> As it happens I'm a long term user of JPA (Eclipselink), so I know a >>> little bit about what happens beneath the surface. >>> >>> JPA postprocesses all the entities classes. During this >>> postprocessing it mainly renames the instance variables and replaces >>> them with placeholders. These placeholders then add a.o. lazy >>> loading (only load the data when the value is accessed) and change >>> monitoring (mark an entity as dirty when the variable is modified). >>> >>> When JFX properties would be used as JPA properties, what would need >>> to happen is that the variable inside the property is postprocessed >>> (assuming FIELD level postprocessing). But we don't want to / can't >>> change a class that's inside the JRE. However, JPA postprocessing >>> adds things that JFX properties actually already do, with their >>> invalidation, etc. You probably could create classes (extending JFX >>> Property) that are drop-in replacements for JFX's and hold all the >>> required JPA logic that normally would be added using >>> postprocessing. This would either remove the need for postprocessing >>> for this part, or make postprocessing very simple. In any case it would still allow the power of JFX binding. >>> >>> I'm using JGoodies binding at the moment, which works flawlessly. >>> Why would JFX listeners be different? In the end the placeholder >>> detect changes to the variables, no matter how these changes came to be. >>> >>> JPA entities are not considered linked to the database table, >>> they're just configured to store and retrieve from tables. That is >>> what JPA's locking mechanism is for. Binding them would create a >>> huge problem implementationwise, performancewise, and code maintainabilitywise. >>> Discussing this would overflow the mailing list. To summarize: >>> change conflicts are handled upon commit. >>> >>> JPA caching does nothing magical; a copy can be in the EM's cache or >>> in the EMF's cache. This only is relevant when loading and >>> persisting, not during usage. Things like equality and hash value >>> are important and properties need to be included when determining those. >>> >>> Observable lists in the end are just lists. So a placeholder is >>> placed in front and loads the actual contents once it is being >>> accessed for the first time. >>> >>> Package names is easy. You could use fronting packages, but jigsaw >>> probably will require the properties to move into a separate >>> package, and get fronts in JFX packages and JPA packages for >>> backwards compatibility / create specialized versions. >>> >>> I'm not seeing bears. >>> >>> Tom >>> >>> >>> >>> On 2012-10-28 00:15, Daniel Zwolenski wrote: >>> >>>> I totally agree with Tom Schindl. Jfx properties do not fit in the >>>> current JPA model and no one would/should use them there. >>>> Properties might be useful on the server side (maybe) but not in your JPA beans. >>>> >>>> Extending what Tom said, I think it is a huge anti-pattern to share >>>> your server side beans on your client anyway. People should have >>>> DB-centric JPA beans on the server and Screen-centric beans on the >>>> client. Lots of reasons for this. I could go into great detail on >>>> this and different patterns. It was to be the next topic for my >>>> zenjava blog before I stopped using jfx, and showcasing such >>>> patterns was something I suggested the "enterprise jfx focus group" >>>> would do but that didn't seem so popular an idea so I'll take the hint and spare the list this. >>>> >>>> Just to add some more specifics on JPA beans having properties on >>>> them, as well as what Tom said, I would add: >>>> >>>> Caching woes - JPA does lots of magical caching and properties and >>>> listeners would massively confuse the cache engine, the GC and the >>>> developers if anyone tried to actually use them on the server side. >>>> That's before you start looking at transaction boundaries too. >>>> >>>> Misleading API - JPA beans are conceptually linked to a db table, >>>> does adding a listener to a property mean I'll get a callback if >>>> someone changes my table data (answer is definitely no on a >>>> distributed, sharded setup, but API implies that it could). >>>> >>>> Collections - observable lists would need to be supported too. JPA >>>> does magical things to collections (lazy loading, etc), fx >>>> collections don't fit in there. >>>> >>>> Wrong package - these properties are in jfx packages which implies >>>> client ui. Server guys won't want to go near them - psychology of >>>> this is often overlooked. Plus when/if jigsaw and modularisation >>>> happens, you add potential inter-dependencies that are odd and >>>> non-intuitive (eg my shared hosting provider could well say "no jfx >>>> on this server jre cause it's ui and we don't want people doing that here"). >>>> >>>> >>>> >>>> On 28/10/2012, at 3:28 AM, Tom Schindl >>>> >>>> wrote: >>>> >>>> Hi, >>>>> >>>>> I really like JavaFX properties but their concept really only >>>>> makes sense on the client. >>>>> >>>>> Main points: >>>>> * They waste memory >>>>> * are not supported on all JVM (people tend to forget that javafx is >>>>> not JSRed and only part of openjdk/oracle jdk). >>>>> >>>>> >>>>> On memory: >>>>> ---------- >>>>> We can talk about laziness as much as we want but when reading a >>>>> bean from the database 95% of the fields are none null, hence lazy >>>>> creation is a nightmare. >>>>> >>>>> In my opinion VM properties are very different to what we have in >>>>> JavaFX. >>>>> >>>>> >>>>> On standard: >>>>> ------------ >>>>> As outlined and confirmed by Richard, Oracle does not guarantee >>>>> that things work on all JVMs (e.g. j9) it might or might not work >>>>> and can be broken any time. >>>>> >>>>> JavaFX will be JSRed by Java9 not sure if vendors are forced to >>>>> implement the started. When you state other JSRed technologies >>>>> should adapt to the JavaFX bean standard the they can before Java9. >>>>> >>>>> >>>>> General statement: >>>>> ------------------ >>>>> I'm not even sure why people have such a big problem with using a >>>>> different object on the server (Plain POJO) and Java(FX)-Bean on >>>>> the client, writing POJOs by hand is a boring and senseless task >>>>> using some meta format or tool and generate the POJOs and >>>>> JavaFX-Beans out of that is not rocket sience. >>>>> >>>>> Tom >>>>> >>>>> Am 27.10.12 16:29, schrieb Tom Eugelink: >>>>> >>>>>> About using JavaFX beans server side; can you explain why that >>>>>> would be a bad idea beside the fact that there isn't any support >>>>>> in frames like JDBC? >>>>>> >>>>>> There has been a big demand from the community for real >>>>>> properties in Java. Now JavaFX has become part of the standard >>>>>> JDK, I expect people to start using these properties in other >>>>>> area's as well. The binding concept is rather powerful and once >>>>>> the concept sinks in... This then would have consequences; some >>>>>> bindings no longer can be lazy, we need bean level listeners, >>>>>> etc. But this can all be added quite easily. >>>>>> Then >>>>>> JDBC and JPA need to be enhanced to support them and we're pretty >>>>>> much done. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On 2012-10-27 15:55, Tom Schindl wrote: >>>>>> >>>>>>> If I remember correctly it had to do with listeners and how to >>>>>>> manage that they are not leaked but I could be wrong. >>>>>>> >>>>>>> Anyways nobody guarantees that OpenJFX will run on other vendors >>>>>>> JVMs, am I right? I generally think using JavaFX-Beans on the >>>>>>> server side is a bad idea. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> Am 27.10.12 15:24, schrieb Richard Bair: >>>>>>> >>>>>>>> I cannot imagine what internal stuff Michael could be using or >>>>>>>> when that was added. >>>>>>>> >>>>>>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl >>>>>>>> wrote: >>>>>>>> >>>>>>>> Not only the memory argument is import. >>>>>>>>> >>>>>>>>> What if a customer says i have to run on his j9-jvm? >>>>>>>>> >>>>>>>>> I can be wrong but IIRC Michael told me at JavaOne that the >>>>>>>>> properties code is even using internal (sun....) stuff so even >>>>>>>>> simply dropping in the jar to the j9 classpath is doomed to >>>>>>>>> fail. >>>>>>>>> >>>>>>>>> And beside that using FX-Observables and e.g. JPA don't like >>>>>>>>> each other i guess because of all those lazy list stuff, ... . >>>>>>>>> >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> Am 22.10.12 19:23, schrieb Werner Lehmann: >>>>>>>>> >>>>>>>>>> Richard, >>>>>>>>>> >>>>>>>>>> On 22.10.2012 17:38, Richard Bair wrote: >>>>>>>>>> >>>>>>>>>>> MyObject obj = new MyObject(); obj = >>>>>>>>>>> BlackMagic.makeObservable(obj)**; >>>>>>>>>>> >>>>>>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib >>>>>>>>>> stuff?) >>>>>>>>>> >>>>>>>>>> However, the javafx beans package and collections and such >>>>>>>>>> are >>>>>>>>>>> part >>>>>>>>>>> of the "base" module -- ie: they could be separated from the >>>>>>>>>>> rest of javafx and safely used on the server side or >>>>>>>>>>> elsewhere. Why not just use properties and such on the >>>>>>>>>>> server side definition of classes? Or are those classes >>>>>>>>>>> being auto-generated and thus not taking observable >>>>>>>>>>> properties into account? >>>>>>>>>>> >>>>>>>>>> Currently I want to avoid requiring customers to install the >>>>>>>>>> FX runtime serverside. That will be a moot point with JRE 7+. >>>>>>>>>> Which does not help the 6.x customers, especially if they are >>>>>>>>>> on WebLogic which is usually tied to a specific major >>>>>>>>>> version. >>>>>>>>>> >>>>>>>>>> Another aspect is the footprint regarding memory and bandwidth. >>>>>>>>>> Obviously a StringProperty requires more bytes than a String. >>>>>>>>>> This is >>>>>>>>>> not an issue (usually) when I want to display a relatively >>>>>>>>>> short list of beans in the UI. It gets noticeable when the >>>>>>>>>> server suddenly needs +X megabytes, the instantion of objects >>>>>>>>>> needs +Y ms (also affects deserialization), and sending them >>>>>>>>>> over the network takes +Z ms... >>>>>>>>>> >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>>>>>> GmbH >>>>>>>>> ------------------------------**------------------------------ >>>>>>>>> ** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>>>>> ------------------------------**------------------------------ >>>>>>>>> ** >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>>>>>> 935833 >>>>>>>>> http://www.BestSolution.at phone ++43 512 >>>>>>>>> 935834 >>>>>>>>> >>>>>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus >>>>> GmbH >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------**------------------------------** >>>>> ------------ >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 >>>>> 935833 >>>>> http://www.BestSolution.at phone ++43 512 >>>>> 935834 >>>>> >>>> > From peter.pilgrim at gmail.com Tue Oct 30 09:35:46 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Tue, 30 Oct 2012 16:35:46 +0000 Subject: Black Background behind MediaView Replicating 3D Movie Cube In-Reply-To: <508EFA84.3000105@oracle.com> References: <508EFA84.3000105@oracle.com> Message-ID: On 29 October 2012 21:52, Kevin Rushforth wrote: > The "MediaCube" demo we showed just uses a gradient "fill" on the Scene, but > you should be able to achieve the same thing with a Rectangle of your own. > You just need to turn off depth test on that rectangle. > > -- Kevin Hi Kevin It was not the Scene I am concerned about. It was the backing rectangle for a MediaView. It is like put a 3D plane on another plane, really. What is the Z order for the two planes rotated in 3D space? I expected the black bars on each CubeFace to appear just on a TV when the television station broadcasts a movie of 21:9 ratio when most home HDTVs are 16:9. So I guess I thinking about this wrong. This is the Scala / JavaFX code http://code.google.com/p/scalafx/source/browse/demo/scalafx/graphics3d/VideoCubeDemo.scala If I set the Rectangle DepthTest to DISABLED then the result is worst. The starry background appears through the backing rectangles. The other thing that occurred in my mind is just to disable the preserveRatio and that would solve it, although the aspect ratio would be destroyed. > > Peter Pilgrim wrote: >> >> Hi >> >> This is nothing to do with OpenJFX codebase or anything else >> >> I was working on ScalaFX just now. Writing a port of the CubeSystem >> Graphic 3D with MediaView instead of Rectangles. I am using my own >> downloaded movie trailers e.g. The Hobbit, Prometheus, Looper, Flight >> etc -- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for financial services, London, UK JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim :: :: Skype Call peter_pilgrim :: :: http://java-champions.java.net/ :: From hang.vo at oracle.com Tue Oct 30 09:48:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 30 Oct 2012 16:48:39 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121030164846.8813B47681@hg.openjdk.java.net> Changeset: f536337e8dc5 Author: hudson Date: 2012-10-25 16:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f536337e8dc5 Added tag 8.0-b62 for changeset 3a9f57c30378 ! .hgtags Changeset: 526513110eba Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-30 09:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/526513110eba Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From richard.bair at oracle.com Tue Oct 30 08:10:20 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 30 Oct 2012 08:10:20 -0700 Subject: bound SVG In-Reply-To: <508C4088.5020506@tbee.org> References: <508BF641.2040408@tbee.org> <508C170F.5020808@tbee.org> <508C4088.5020506@tbee.org> Message-ID: <36B381B5-DB8D-4AD0-8344-F4563C27F0AC@oracle.com> > I hoped to be able to switch from a bar to a full rectangle by just using CSS, but I can't set the width in CSS. I could use two rectangles, but I'm also blocked on the fact that the color is set explicitly in the code (setFill), with two rectangles I need to set both fills, but I can't make one of then go away in the CSS - unless scary solitions with translate maybe. BTW, in my agenda (where I need to do something similar) I simply assign a style class and let that handle the presentation. Then I could simply have declared either color "transparent". I feel that the conference example is not using JavaFX's features to the max :-) That's correct, it was never meant to. The conference app is not a sample, it is an application. We cut corners left, right, and center because we had limited time and were trying to target a device (that wasn't demonstrated) which has no JIT. Ahem. In past years we got beat up for not releasing our demos. But of course we never did because they're usually a mess because, like any schedule driven app, things didn't go according to plan :-) As far as your use case, why not set the style directly on the node via setStyle? You can construct the string via some computation in that case. Richard From richard.bair at oracle.com Tue Oct 30 08:40:42 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 30 Oct 2012 08:40:42 -0700 Subject: How does JFX work get prioritised? In-Reply-To: <508F2220.6080905@oracle.com> References: <508F1A77.3080203@oracle.com> <508F2220.6080905@oracle.com> Message-ID: <8E52FB4B-F4B9-48A5-94B6-B9782B8706BA@oracle.com> Haha, threw me under the bus :-). There isn't much process. We do get feedback from our inbound marketing team from both looking at competitors, market trends, and customer requests. If you have commercial work going on and haven't emailed Nicolas Lorain, you ought to do so. These requests coming from our inbound marketing / product management team are their asks for a release. The engineering team has another body of work that we'd like to do, driven by our experience as engineers with the product, things we read on blogs or in emails or on mailing lists such as this, and blind spots and holes that we just know about since we didn't have time in a previous release to do everything we wanted to our satisfaction. Those are our asks. The high level big-picture items are negotiated between engineering and product management. Engineering gives estimates for the amount of work, etc. Product management comes with dates (which are mostly set in stone years in advance, because it is part of the JavaSE release dates, including update releases), although of course dates can be adjusted down the line. These items which will take more than 2 weeks to complete are "Features" in JIRA. Those items which are new API etc but which are less than 2 weeks work are "Tweaks". Bugs are "Bugs" (ie: something doesn't work the way it was meant to work -- these can affect API but are always of the nature that they should have worked but was coded improperly etc). As to what goes into a release, it is a negotiation between Product Management, Engineering, and SQE (Software Quality Engineering). PM says "I want everything", Engineering says "I can give you this and this", and SQE says "I can only test this". And thus we get down to some number of Features that we can handle in a release. For Tweaks and Bugs, it is only a negotiation between Engineering and SQE. If we can write our own tests on engineering side, then SQE doesn't have to be impacted, and those tweaks / bug fixes are easier to get through. Votes are something that we have done an awful job of taking into this process, but both engineering and PM should be taking these into account as customer requests in the planning process. We try to reserve a significant amount of time for bug fixing. I prefer fewer features until we can get the bug backlog under control and keep the quality high. Obviously PM cares about that too to some extent, but they are really the customer advocate and asking for every new feature under the sun that their contacts have requested. Which is why we've had a hard time between me asking for contributions, people giving contributions, and then they aren't being taken. The problem is that, my main issue is that the bug backlog *must* get under control (including performance work), and that every new feature increases the backlog and makes it that much more unlikely that we'll ever get it under control. Of course, the sorts of things people want to contribute more often than not are new features -- but that usually makes our jobs harder, not easier, because of the level of testing etc that has to go into new features, so that even if I take them on the engineering side, SQE can veto based on the amount of work they already have to do. On the other hand, the most valuable contributions at this stage in the project is also the least glamourous -- but fixes. I have a number of those, and these need to be treated as gold. This is also why I'm spending almost all of my time getting the rest of the source code open sourced and improving our build and related processes, and getting the test code all open sourced so that this can be as dead easy a process as possible. Steve, Jasper and I are shortly going to have this documented in the WIKI. I am going to get the build scripts out there today, hopefully, although they won't really work until the rest of the code is open sourced, but I want to make it so that anybody can follow along and see what we're up to. Richard On Oct 29, 2012, at 5:41 PM, Kevin Rushforth wrote: > Richard Bair should answer the more general question you raised. > > -- Kevin > > > Daniel Zwolenski wrote: >> Good to know, but I was just using this issue to frame the question: what's the process you use to determine what's in or out? When you "reconsider" this, who will be doing the reconsidering, and what will be the determining factor of whether it is in or out? >> >> e.g. is each developer or sub-team free to pick their priorities or do they come from a marketing team or a high-level management crew? Maybe there's a committee that meets once a week, month, whatever? What input do the decision makers look at when deciding, are they using solid metrics from market research, surveys, community feedback, etc, or is it more of a gut-feel thing? >> You mention "lobbying". What form of lobbying? What priority do JIRA votes get (traditionally none) vs "private emails", OTN forum posts, or feet stamping and generally being annoying on this mailing list (that hasn't worked for me though ;) ). Does lobbying from certain users (e.g. oracle customers) or types of users (e.g. established corporates vs "I'm a developer") get more weight than others - if so what's the weighting (how many noisy plebs does it take to balance out large corporate)? >> Any chance we could get some insight on any of that? >> >> >> On Tue, Oct 30, 2012 at 11:08 AM, Kevin Rushforth > wrote: >> >> I'll take the heat for this one. I just bulk removed the "Lombard" >> release for all Feature JIRAs (as opposed to Tweaks) that are not >> part of the list of accepted features for the release, without too >> much thought behind it. One reason for doing this is to not leave >> the false impression that they are being actively worked on, so >> that people can either set their expectations appropriately or >> lobby for it being included. >> >> Based on your e-mail, the number of votes on this issue, and a >> couple private e-mails I received, it seems like this is something >> we should explicitly reconsider. >> >> -- Kevin >> >> >> Daniel Zwolenski wrote: >> >> Is it possible for someone from the Oracle JFX team to outline >> how features >> get prioritised for inclusion in a release? >> >> I've been frustrated at times with things I think I are >> important not >> getting done, and I think a few others have had similar >> experiences. Obviously all of us think our bug/feature is the most >> important thing, and not everything can get done and there has >> to be >> priorities. I think it would be less frustrating though if we >> actually knew >> the process that was used to prioritise issues - who decides, >> and what >> metrics are used as input? >> >> I noted today for example, that >> RT-10376, >> >> which is simply to allow maximising the stage >> programmatically, just got >> bumped so its not part of Java8 and is not part of any foreseeable >> release. I personally don't care about this feature so much, >> but it does >> look like a pretty fundamental, basic thing for a windowing >> toolkit to >> have, so highlights the general point: >> >> - It was raised as a "critical feature" by Jasper Potts, so >> it doesn't >> >> seem a case of not being recognised as important within Oracle. >> - It was raised back in 2010 so it doesn't seem a case of >> it coming in >> too late and just not making the cut for the release. >> - Based on comments from Anthony Petrov it seems to be >> already mostly >> >> implemented and just needs to be hooked in, so I'm assuming >> it's not really >> a big resourcing issue. >> - It's got 28 votes from the community, placing it at #8 in >> the most >> >> voted list by my reckoning, so there's no lack of community >> interest in the >> issue (3D geometry support has 12 votes for example). >> >> >From my vantage point, it's difficult to see why a feature >> like this >> wouldn't have been done months ago, let alone be off the road map >> completely, especially when you consider some of the more >> obscure features >> on the roadmap. Confusion over something like this, for me at >> least, >> festers into a general distrust in the process, which results in >> frustration around other issues I do consider important (like >> build/deployment). >> >> Can this confusion be lessened through some better >> communication? Is it >> possible to explain how, in this case and in general, you guys >> prioritise >> JavaFX work? >> >> From richard.bair at oracle.com Tue Oct 30 08:48:26 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 30 Oct 2012 08:48:26 -0700 Subject: JPA properties In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> <508CDEC5.7030907@tbee.org> <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> <508CF2AD.40809@tbee.org> Message-ID: > Fair enough. Calling directly onto a database from the client is probably > not an approach I would go for too often or recommend for a lot of use > cases, but hey, if it works for you, great. In particular, it is not uncommon for client apps to want to stash some data into, say, a local berkeley database. The iBank app for Mac OS X does exactly this. I wrote a little app the used JPA and mapped beans over their database structure for an alternate UI. Being able to do this on the client side is excessively common when you're talking about native bundled applications that aren't talking to a backend (more common in the consumer space), or one where although it talks to a backend system, it maintains a full copy of data locally. Richard From tbee at tbee.org Tue Oct 30 10:35:26 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 30 Oct 2012 18:35:26 +0100 Subject: bound SVG In-Reply-To: <36B381B5-DB8D-4AD0-8344-F4563C27F0AC@oracle.com> References: <508BF641.2040408@tbee.org> <508C170F.5020808@tbee.org> <508C4088.5020506@tbee.org> <36B381B5-DB8D-4AD0-8344-F4563C27F0AC@oracle.com> Message-ID: <50900FDE.4000103@tbee.org> On 2012-10-30 16:10, Richard Bair wrote: >> I hoped to be able to switch from a bar to a full rectangle by just using CSS, but I can't set the width in CSS. I could use two rectangles, but I'm also blocked on the fact that the color is set explicitly in the code (setFill), with two rectangles I need to set both fills, but I can't make one of then go away in the CSS - unless scary solitions with translate maybe. BTW, in my agenda (where I need to do something similar) I simply assign a style class and let that handle the presentation. Then I could simply have declared either color "transparent". I feel that the conference example is not using JavaFX's features to the max :-) > That's correct, it was never meant to. The conference app is not a sample, it is an application. We cut corners left, right, and center because we had limited time and were trying to target a device (that wasn't demonstrated) which has no JIT. Ahem. In past years we got beat up for not releasing our demos. But of course we never did because they're usually a mess because, like any schedule driven app, things didn't go according to plan :-) > > As far as your use case, why not set the style directly on the node via setStyle? You can construct the string via some computation in that case. > > Richard Thanks for your comments. Stephen would like to demo skinning with with the app, but that's not going to happen. It's more image than JavaFX from a design perspective. I was able to solve this problem using a Region, SVG and hardcoded sizes. Tom From ozemale at ozemail.com.au Tue Oct 30 10:53:24 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Wed, 31 Oct 2012 04:53:24 +1100 Subject: Antialiasing in 3D graphics Message-ID: I have read the latest information about the upcoming 3D features planned for JavaFX 8 and like what I see so far. One thing that is not clear to me though is what kinds of antialiasing will be available. I notice that when I run the 3D demos from the 2.2 Ensemble app the cubes etc. have pronounced jaggies and no amount of tweaking the graphics driver settings in the Nvidia Control Panel helps. So will JavaFX simply set the AA level/style or will it support either programmatic or manual customisation? -jct From udo.rader at bestsolution.at Tue Oct 30 13:38:49 2012 From: udo.rader at bestsolution.at (Udo Rader) Date: Tue, 30 Oct 2012 21:38:49 +0100 Subject: status of 3D support on Linux Message-ID: <50903AD9.9010009@bestsolution.at> Hi, we are currently evaluating our options on getting 3D support for Linux based devices and were stunned to find that currently only the proprietary nVidia driver is supported on Linux. Now after http://javafx-jira.kenai.com/browse/RT-24712 ("Support ATI/AMD GPU on the Linux platform") has been resolved I am wondering what that means. So, 3 questions: #1 does resolving the above issue bring 3D support to Linux for AMD/ATI devices? #2 what about other GPUs, such as the extremely common Intel HD GPUs? #3 any plans to support OpenSource/Gallium3D based drivers (ie nouveau/radeon)? IMHO bringing 3D support to Linux based (embedded) devices is very important to bring JavaFX forward. Regards Udo -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From zonski at gmail.com Tue Oct 30 15:41:06 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 31 Oct 2012 09:41:06 +1100 Subject: JPA properties In-Reply-To: References: <02CDE476-CED7-4987-B0FE-AB1D200541F6@oracle.com> <5085204E.7090207@media-interactive.de> <5085811A.4050103@media-interactive.de> <508AA13B.6040104@bestsolution.at> <895211BD-14E9-4772-A6DA-8D3F795C1ED4@oracle.com> <508BE7C6.3010103@bestsolution.at> <508BEFDE.6090602@tbee.org> <508C0BB8.2000204@bestsolution.at> <4BD4D56B-1359-4F00-8618-A663921F0BD4@gmail.com> <508CDEC5.7030907@tbee.org> <8FED90A1-0311-44B9-87B1-38AA7FBF13E6@gmail.com> <508CF2AD.40809@tbee.org> Message-ID: Yea, I was following the thread started by your original question regarding "properties on server side JPA beans" and my comments are all in that context. I just stopped saying the word "server" which I think confused things. I think observable properties on "server-side JPA beans" are a bad idea for all the reasons outlined by Tom S plus my own. The "don't call the database from the client" was also in the same context of client-server - i.e. it's not a great idea to 'fake' a client-server setup by using your database as the 'server'. This is due mainly to reasons of security and performance (particularly with respect to multiple users) but there are other reasons too. Using a local, client-only database as a cache or to store settings, etc (effectively an alternative to the file system) is definitely a valid use case and one I use often. It's a very different situation to client-server though: all calls are local; there's only one db user; the entire JPA tree/cache "belongs" to your app instead of being shared; etc. The argument for observable properties on your client-side JPA cache data is more open to debate than the server side one in my opinion. I can't see anything these properties add that's useful at the JPA layer but I imagine most people would want to do it so they can reuse their "view model" and just serialize it. I tend not to do this, I'd have POJOs specifically representing the JPA cache beans and have different (but similar) observable models for the 'view' - standard 'decoupling'/'separation of concerns', a lot more work but more testable and maintainable. I'm that sort of coder though, and there are people religiously bent the other way. As always it's a case of "fit-for-purpose" plus a good dash of personal preference thrown in for added flavour. For the architectures I use, a framework that could more easily map from one bean to another (observable or otherwise) would be extremely useful. Something more in line with your 'BlackMagic' idea (but I think it is too simple) - a kind of bean-to-bean binding approach, with support for observables a bonus. I'd be interested in work shopping ideas on this if anyone wants to. Not sure this is a 'core' JFX problem though (since I've had the same thing come up in Swing, GWT, Webservices and pretty much everywhere in Java). Seems like something that could/should be an external library? On Wed, Oct 31, 2012 at 2:48 AM, Richard Bair wrote: > > Fair enough. Calling directly onto a database from the client is probably > > not an approach I would go for too often or recommend for a lot of use > > cases, but hey, if it works for you, great. > > In particular, it is not uncommon for client apps to want to stash some > data into, say, a local berkeley database. The iBank app for Mac OS X does > exactly this. I wrote a little app the used JPA and mapped beans over their > database structure for an alternate UI. Being able to do this on the client > side is excessively common when you're talking about native bundled > applications that aren't talking to a backend (more common in the consumer > space), or one where although it talks to a backend system, it maintains a > full copy of data locally. > > Richard From kevin.rushforth at oracle.com Tue Oct 30 15:54:56 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Oct 2012 15:54:56 -0700 Subject: status of 3D support on Linux In-Reply-To: <50903AD9.9010009@bestsolution.at> References: <50903AD9.9010009@bestsolution.at> Message-ID: <50905AC0.6050608@oracle.com> > #1 does resolving the above issue bring 3D support to Linux for > AMD/ATI devices? Yes. This should be available in this week's JDK8 build. Chien was going to send out a "try it and let us know" e-mail, so he may want to follow up on this. > #2 what about other GPUs, such as the extremely common Intel HD GPUs? Unplanned for FX 8. The problem is that the Intel OpenGL drivers on Linux have been historically very bad in terms of quality and compliance. There is some anecdotal evidence that this is changing, but we don't want to support it. There is a system property you can set to force this for testing, but no way to deploy an application using it. > #3 any plans to support OpenSource/Gallium3D based drivers (ie > nouveau/radeon)? Not support, no. But it might "just work" and is something you could try. -- Kevin Udo Rader wrote: > Hi, > > we are currently evaluating our options on getting 3D support for > Linux based devices and were stunned to find that currently only the > proprietary nVidia driver is supported on Linux. > > Now after http://javafx-jira.kenai.com/browse/RT-24712 ("Support > ATI/AMD GPU on the Linux platform") has been resolved I am wondering > what that means. > > So, 3 questions: > > #1 does resolving the above issue bring 3D support to Linux for > AMD/ATI devices? > > #2 what about other GPUs, such as the extremely common Intel HD GPUs? > > #3 any plans to support OpenSource/Gallium3D based drivers (ie > nouveau/radeon)? > > IMHO bringing 3D support to Linux based (embedded) devices is very > important to bring JavaFX forward. > > Regards > > Udo > > -- > Udo Rader, CEO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From chien.yang at oracle.com Tue Oct 30 17:04:50 2012 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 30 Oct 2012 17:04:50 -0700 Subject: Antialiasing in 3D graphics In-Reply-To: References: Message-ID: <50906B22.3090708@oracle.com> JavaFX 8 will support multisample anti-aliasing (MSAA) for 3D Scene and SubScene. Application can request for it at construction time, if it supported by the system GPU. public Scene(Parent root, double width, double height, boolean depthBuffer, boolean antiAliasing) public SubScene(Parent root, double width, double height, boolean depthBuffer, boolean antiAlias) - Chien On 10/30/2012 10:53 AM, John C. Turnbull wrote: > I have read the latest information about the upcoming 3D features planned for JavaFX 8 and like what I see so far. > > One thing that is not clear to me though is what kinds of antialiasing will be available. I notice that when I run the 3D demos from the 2.2 Ensemble app the cubes etc. have pronounced jaggies and no amount of tweaking the graphics driver settings in the Nvidia Control Panel helps. > > So will JavaFX simply set the AA level/style or will it support either programmatic or manual customisation? > > -jct From chien.yang at oracle.com Tue Oct 30 17:21:17 2012 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 30 Oct 2012 17:21:17 -0700 Subject: status of 3D support on Linux In-Reply-To: <50905AC0.6050608@oracle.com> References: <50903AD9.9010009@bestsolution.at> <50905AC0.6050608@oracle.com> Message-ID: <50906EFD.10006@oracle.com> Yes, please give it a try once the binary is available by end of this week. Any feedback on JavaFX stability running on ATI/AMD GPU will be greatly appreciated. So far our testing has been limited to Ubuntu 12.04 (32-bit) using AMD proprietary fglrx driver. Information on installing fglrx driver: https://help.ubuntu.com/community/BinaryDriverHowto/ATI - Chien On 10/30/2012 3:54 PM, Kevin Rushforth wrote: > >> #1 does resolving the above issue bring 3D support to Linux for >> AMD/ATI devices? > > Yes. This should be available in this week's JDK8 build. Chien was > going to send out a "try it and let us know" e-mail, so he may want to > follow up on this. > >> #2 what about other GPUs, such as the extremely common Intel HD GPUs? > > Unplanned for FX 8. The problem is that the Intel OpenGL drivers on > Linux have been historically very bad in terms of quality and > compliance. There is some anecdotal evidence that this is changing, > but we don't want to support it. There is a system property you can > set to force this for testing, but no way to deploy an application > using it. > > >> #3 any plans to support OpenSource/Gallium3D based drivers (ie >> nouveau/radeon)? > > Not support, no. But it might "just work" and is something you could try. > > -- Kevin > > > Udo Rader wrote: >> Hi, >> >> we are currently evaluating our options on getting 3D support for >> Linux based devices and were stunned to find that currently only the >> proprietary nVidia driver is supported on Linux. >> >> Now after http://javafx-jira.kenai.com/browse/RT-24712 ("Support >> ATI/AMD GPU on the Linux platform") has been resolved I am wondering >> what that means. >> >> So, 3 questions: >> >> #1 does resolving the above issue bring 3D support to Linux for >> AMD/ATI devices? >> >> #2 what about other GPUs, such as the extremely common Intel HD GPUs? >> >> #3 any plans to support OpenSource/Gallium3D based drivers (ie >> nouveau/radeon)? >> >> IMHO bringing 3D support to Linux based (embedded) devices is very >> important to bring JavaFX forward. >> >> Regards >> >> Udo >> >> -- >> Udo Rader, CEO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >> http://www.bestsolution.at/ >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From hang.vo at oracle.com Tue Oct 30 17:48:23 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 31 Oct 2012 00:48:23 +0000 Subject: hg: openjfx/8/controls/rt: 15 new changesets Message-ID: <20121031004840.58CBE47694@hg.openjdk.java.net> Changeset: dafaa830d4d0 Author: hudson Date: 2012-10-18 14:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dafaa830d4d0 Added tag 8.0-b61 for changeset 97d1312344e8 ! .hgtags Changeset: 609ede4dbba0 Author: Morris Meyer Date: 2012-10-17 16:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/609ede4dbba0 RT-25434 - FindBugs issue ! javafx-ui-common/src/com/sun/javafx/tk/ImageLoader.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageLoader.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageLoaderFactory.java Changeset: 923b26ed6ea4 Author: kcr Date: 2012-10-19 05:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/923b26ed6ea4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 99a390cd0ec5 Author: Pavel Safrata Date: 2012-10-22 15:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/99a390cd0ec5 RT-25753: toString() of gestures reports inertia. ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java Changeset: 732db3a8f698 Author: "Jasper Potts" Date: 2012-10-22 17:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/732db3a8f698 Added com.sun API for listening to cell changes on a VirtualFlow. Also VirtualFlow performance improvements. Both by Richard Bair from JavaOne demo work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 7e671f637e68 Author: "Jasper Potts" Date: 2012-10-22 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7e671f637e68 Fixed com.sun API for listening to cell changes on a VirtualFlow, should have had getters and setters not public field. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 3a9f57c30378 Author: "Jasper Potts" Date: 2012-10-22 18:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3a9f57c30378 Added ConferenceScheduleApp that was demoed at JavaOne 2012 to new apps experiments directory + apps/experiments/ConferenceScheduleApp/build.xml + apps/experiments/ConferenceScheduleApp/manifest.mf + apps/experiments/ConferenceScheduleApp/nbproject/build-impl.xml + apps/experiments/ConferenceScheduleApp/nbproject/configs/Run_as_WebStart.properties + apps/experiments/ConferenceScheduleApp/nbproject/configs/Run_in_Browser.properties + apps/experiments/ConferenceScheduleApp/nbproject/configs/Test_Mode.properties + apps/experiments/ConferenceScheduleApp/nbproject/genfiles.properties + apps/experiments/ConferenceScheduleApp/nbproject/jfx-impl.xml + apps/experiments/ConferenceScheduleApp/nbproject/project.properties + apps/experiments/ConferenceScheduleApp/nbproject/project.xml + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/AutoLogoutLightBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/ConferenceScheduleApp.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/Page.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/PageContainer.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/PlatformIntegration.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet-Desktop.css + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet.css + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/Theme.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/TouchClickedEventAvoider.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/TouchScrollEventSynthesizer.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/AsciiBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/CheckBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/EmailBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/EventPopoverPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/LoginProgressBarSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/NoopScrollBarSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/Popover.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/PopoverTreeList.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/ResizableWrappingText.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/ScrollPaneSkin3.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SearchBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SimpleVBox.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/SymbolBoard.txt + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TestPopover.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TestVirtualKeyboard.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/TreeBoxItem.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/VirtualKeyboard.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/control/VirtualKeyboardSkin.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/DataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/SessionManagement.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/TwitterJson.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/DevoxxDataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/GetConferenceDataTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/LoginTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/TestDataService.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/devoxx/UpdateScheduleTask.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/back-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/backspace-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/blue-linen.jpg + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/cancel.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/cancel at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/capslock-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/done.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/done at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/duke48.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/enter-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-popover.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/filter-popover at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-shadow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/header-shadow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/ios-list-transparent.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/ios-list-transparent at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-blue-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-blue-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-gray-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-grey-button-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-light-blue-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-red-button.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/large-red-button at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-background-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-background.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-strap-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-badge-strap.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-guest-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-guest-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-login-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-login-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-title-SMALL.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/login-title.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/logout-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/need-to-be-logged-in.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/now-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/pic-shadow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/pic-shadow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-blue-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-blue-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-light-blue-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-light-blue-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-list-border.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-list-border at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow-empty.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow-empty at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/popover-no-arrow at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/refresh-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/refresh-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/rough_diagonal.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/rough_diagonal_blue.jpg + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search-clear.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search-clear at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/search at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/shift-icon.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/short-key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/short-key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/special-key-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/special-key.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/star.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tick.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tick at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bottom-fade.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble-tooth.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble-tooth at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-bubble at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-dot.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-dot at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-presentation.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-presentation at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/timeline-top-fade.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/tweet at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn-pressed at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/view-sessions-btn at 2x.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-dark-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-dark.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-hide.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-light-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-light.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-medium-pressed.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/images/vk-medium.png + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Availability.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Event.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/FilterType.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Level.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Room.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Session.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/SessionTime.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/SessionType.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Speaker.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Track.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Tweet.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/model/Venue.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/CatalogPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/FilterSessionsByTrackPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/FilterSessionsByTypePage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/LoginScreen.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SearchFilterPopoverPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SessionFilterCriteria.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SessionListPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SocialPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/SpeakersPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/TimelinePage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/TracksPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/VenueRoomPage.java + apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/pages/VenuesPage.java Changeset: f536337e8dc5 Author: hudson Date: 2012-10-25 16:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f536337e8dc5 Added tag 8.0-b62 for changeset 3a9f57c30378 ! .hgtags Changeset: 1089c39177ad Author: "Jasper Potts" Date: 2012-10-25 15:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1089c39177ad ConferenceScheduleApp: fixed unicode decoding in JSON parser in app. ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java Changeset: 2b0c055d14b8 Author: "Jasper Potts" Date: 2012-10-25 15:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2b0c055d14b8 ConferenceScheduleApp: fixed unicode decoding in JSON parser in app. Better fix :-) ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/data/JSONParserJP.java Changeset: 15023603f35c Author: Martin Sladecek Date: 2012-10-26 11:58 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/15023603f35c - Node.scene not lazy - impl_computeGeomBounds used only on some transformations ! javafx-ui-common/src/javafx/scene/Node.java Changeset: a3f860f81cf8 Author: Martin Sladecek Date: 2012-10-26 13:10 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a3f860f81cf8 RT-25496 Optimize ImageView bounds ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageViewTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubImageView.java Changeset: 3626aad4f2a5 Author: flar Date: 2012-10-26 15:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3626aad4f2a5 Fix RT-24566: Resolve semantics of texture padding. ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubFilterable.java Changeset: 526513110eba Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-10-30 09:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/526513110eba Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: e901aef78ced Author: jgiles Date: 2012-10-31 01:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e901aef78ced Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From udo.rader at bestsolution.at Wed Oct 31 01:42:16 2012 From: udo.rader at bestsolution.at (Udo Rader) Date: Wed, 31 Oct 2012 09:42:16 +0100 Subject: status of 3D support on Linux In-Reply-To: <50905AC0.6050608@oracle.com> References: <50903AD9.9010009@bestsolution.at> <50905AC0.6050608@oracle.com> Message-ID: <5090E468.7050702@bestsolution.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/30/2012 11:54 PM, Kevin Rushforth wrote: >> #2 what about other GPUs, such as the extremely common Intel HD >> GPUs? > > Unplanned for FX 8. The problem is that the Intel OpenGL drivers > on Linux have been historically very bad in terms of quality and > compliance. There is some anecdotal evidence that this is changing, > but we don't want to support it. There is a system property you can > set to force this for testing, but no way to deploy an application > using it. Yes, the intel drivers have a bad history in some areas. OTOH, you might say the same about general usability of the proprietary drivers under Linux (ie the fglrx driver). >> #3 any plans to support OpenSource/Gallium3D based drivers (ie >> nouveau/radeon)? > > Not support, no. But it might "just work" and is something you > could try. I understand, "support" is a somewhat dangerous term, of course. How then do we force things on unsupported platforms? Right now, 3D simply does not work and we did not find anything about the system property you mention. Thanks Udo - -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkORoAAoJEJA9QoEqa9WBdFMH/il9Q28ajPqoKdNTe9hElmnZ TaNQ3YdELleO06FxiRpKPvhCaWBrLtUGHbmDOLRFnaBhXgVg1MEF6SBif7rkcgjw WAP3POAkWqoCjvfgEMaIVQGZMMZ7529OVxXN3lShdo2PBj4eszhHjB+lQzq87eQR ISzrngZUCiNCApdauJGPPx0AfT1+HWHfOTo9I9P3oLe6IEx7QUtteB6Q+phbFM8p kY7xIHlCXTPWy78IDe8plx+aCfKMeDgSScyiVhYCnIdWYMyjBLwPQrJRqZRSs6/i kGONxWm2933yw3h51labM2qvLX4s+rlDKwhtYY3IFBXBQZc5/LxoVjoFw+YJsno= =SrLb -----END PGP SIGNATURE----- From goddard at seznam.cz Wed Oct 31 02:23:32 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Wed, 31 Oct 2012 10:23:32 +0100 (CET) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20status=20of=203D=20support=20on=20Linux?= In-Reply-To: <5090E468.7050702@bestsolution.at> Message-ID: <137513.13779.51476-14779-2087805509-1351675412@seznam.cz> It's startling that one of the most common GPUs is not supported. I remember that it was supported back in the Java 3D days... Regards, George ------------ P?vodn? zpr?va ------------ Od: Udo Rader P?edm?t: Re: status of 3D support on Linux Datum: 31.10.2012 09:58:03 ---------------------------------------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/30/2012 11:54 PM, Kevin Rushforth wrote: >> #2 what about other GPUs, such as the extremely common Intel HD >> GPUs? > > Unplanned for FX 8. The problem is that the Intel OpenGL drivers > on Linux have been historically very bad in terms of quality and > compliance. There is some anecdotal evidence that this is changing, > but we don't want to support it. There is a system property you can > set to force this for testing, but no way to deploy an application > using it. Yes, the intel drivers have a bad history in some areas. OTOH, you might say the same about general usability of the proprietary drivers under Linux (ie the fglrx driver). >> #3 any plans to support OpenSource/Gallium3D based drivers (ie >> nouveau/radeon)? > > Not support, no. But it might "just work" and is something you > could try. I understand, "support" is a somewhat dangerous term, of course. How then do we force things on unsupported platforms? Right now, 3D simply does not work and we did not find anything about the system property you mention. Thanks Udo - -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkORoAAoJEJA9QoEqa9WBdFMH/il9Q28ajPqoKdNTe9hElmnZ TaNQ3YdELleO06FxiRpKPvhCaWBrLtUGHbmDOLRFnaBhXgVg1MEF6SBif7rkcgjw WAP3POAkWqoCjvfgEMaIVQGZMMZ7529OVxXN3lShdo2PBj4eszhHjB+lQzq87eQR ISzrngZUCiNCApdauJGPPx0AfT1+HWHfOTo9I9P3oLe6IEx7QUtteB6Q+phbFM8p kY7xIHlCXTPWy78IDe8plx+aCfKMeDgSScyiVhYCnIdWYMyjBLwPQrJRqZRSs6/i kGONxWm2933yw3h51labM2qvLX4s+rlDKwhtYY3IFBXBQZc5/LxoVjoFw+YJsno= =SrLb -----END PGP SIGNATURE----- From peter.pilgrim at gmail.com Wed Oct 31 03:21:34 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Wed, 31 Oct 2012 10:21:34 +0000 Subject: Building Javadoc in the OpenJFX distribution Message-ID: Hi What is the way to build the javadocs locally in the openjfx distribution 2.2? % cd rt % ant javadoc % ant ??? TIA -- Peter Pilgrim, From zonski at gmail.com Wed Oct 31 05:31:03 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 31 Oct 2012 23:31:03 +1100 Subject: How does JFX work get prioritised? In-Reply-To: <8E52FB4B-F4B9-48A5-94B6-B9782B8706BA@oracle.com> References: <508F1A77.3080203@oracle.com> <508F2220.6080905@oracle.com> <8E52FB4B-F4B9-48A5-94B6-B9782B8706BA@oracle.com> Message-ID: Thanks for the reply - believe it or not it does help to know this. At least the process is just loose rather than deliberately biased towards commercial customers, etc. I don't think you're going to be surprised when I say that this process doesn't look quite ideal. It's quite a closed process and an unpredictable one. From a community perspective there's no real visibility on what priorities are, how much 'weight' something has or why, and when our fixes will go in if we provide them. That doesn't really foster contributions, or even voting or bug raising. At the same time it can lead to resentment as to "why didn't my bug get fixed!". >From your team's perspective you've pretty much told us that the best way to get something we want in is to spam all your private inboxes and annoy the hell out of everyone and get all our friends to do the same - squeaky wheel policy. I reckon I'm pretty annoying at times and it hasn't paid off yet, I don't think anyone wants to encourage me to be more vocal! I guess it all depends on whether you are happy with this process? If so, then business as usual and at least we now have some insight into the process. If not we as a community then would it be worth throwing it open to the community for ways to improve this process? Perhaps other people have experiences on similar open source projects and can suggest systems that work well (or highlight ones that don't)? I've never been involved with a community process like this but I have worked on a number of JIRA-based projects with clients driving the priority list. For me some of the things that worked would seem to be a good idea for JFX. For example, I'd really love to see the 'Roadmap' gadget working in JFX JIRA (currently it shows as empty), We'd then be able to very easily see the upcoming releases and what features are planned when (or maybe you have another way of showing this - your JIRA setup is a bit weird to me?). Visibility on this would allow community members, your team and your commercial clients to see all the bugs and all the issues ahead of our issue which could well lead to us saying things like "ok, well some of those things really are more important than my issue", or "ok that'll be here mid next year, I can do a work around until then". Another great tool is the voting mechanism. I've tried to push for this before and there was some interest but it never really eventuated. If *everything* could be prioritised on a defined point scoring system (i.e. move away from private emails and get these people to vote) then there really couldn't be much complaining from any party. If commercial users and Oracle employees need to have more weight than us plebs then I could live with that - we just need to weight votes, so a vote by a JFX developer or Oracle gold client is worth 10 points, and a vote by us plebs is worth 1 (or whatever). I know JIRA doesn't support weighted votes out of the box but if you were genuinely interested in doing something like this I would consider trying to write a plugin for it. And then story points have always been my favourite tool for this sort of stuff. If every issue was given a story point ranking then you can say we will aim to get X story points done in this release. If you want to define a ratio say 2/3 have to be bug fix and 1/3 can be new features then that works well for making sure the rate of bug fix is higher than the rate of bug creation. The great thing about story points combined with a roadmap is that if my feature is behind a bunch of bugs well then if I help you guys resolve those boring bugs my feature might make it on the list. In fact that would be your easy comeback whenever someone complains their bug is not being fixed: "help us sort out these bugs and yours is next on the list". Even I'd have no comeback to that. Basically all things just aimed at predictability and visibility. Maybe there are better ways to achieve those than my suggestions, but I do think achieving them is fairly important to a happy, healthy community that actively contributes and feels warm and fuzzy about doing so. And imagine, if you had a defined process like this, you wouldn't have to put up with me trying to be the loudest squeaky wheel all the time. No more emails like this one. Surely that alone would be worth it! On Wed, Oct 31, 2012 at 2:40 AM, Richard Bair wrote: > Haha, threw me under the bus :-). > > There isn't much process. We do get feedback from our inbound marketing > team from both looking at competitors, market trends, and customer > requests. If you have commercial work going on and haven't emailed Nicolas > Lorain, you ought to do so. These requests coming from our inbound > marketing / product management team are their asks for a release. The > engineering team has another body of work that we'd like to do, driven by > our experience as engineers with the product, things we read on blogs or in > emails or on mailing lists such as this, and blind spots and holes that we > just know about since we didn't have time in a previous release to do > everything we wanted to our satisfaction. Those are our asks. > > The high level big-picture items are negotiated between engineering and > product management. Engineering gives estimates for the amount of work, > etc. Product management comes with dates (which are mostly set in stone > years in advance, because it is part of the JavaSE release dates, including > update releases), although of course dates can be adjusted down the line. > These items which will take more than 2 weeks to complete are "Features" in > JIRA. Those items which are new API etc but which are less than 2 weeks > work are "Tweaks". Bugs are "Bugs" (ie: something doesn't work the way it > was meant to work -- these can affect API but are always of the nature that > they should have worked but was coded improperly etc). > > As to what goes into a release, it is a negotiation between Product > Management, Engineering, and SQE (Software Quality Engineering). PM says "I > want everything", Engineering says "I can give you this and this", and SQE > says "I can only test this". And thus we get down to some number of > Features that we can handle in a release. For Tweaks and Bugs, it is only a > negotiation between Engineering and SQE. If we can write our own tests on > engineering side, then SQE doesn't have to be impacted, and those tweaks / > bug fixes are easier to get through. > > Votes are something that we have done an awful job of taking into this > process, but both engineering and PM should be taking these into account as > customer requests in the planning process. > > We try to reserve a significant amount of time for bug fixing. I prefer > fewer features until we can get the bug backlog under control and keep the > quality high. Obviously PM cares about that too to some extent, but they > are really the customer advocate and asking for every new feature under the > sun that their contacts have requested. > > Which is why we've had a hard time between me asking for contributions, > people giving contributions, and then they aren't being taken. The problem > is that, my main issue is that the bug backlog *must* get under control > (including performance work), and that every new feature increases the > backlog and makes it that much more unlikely that we'll ever get it under > control. Of course, the sorts of things people want to contribute more > often than not are new features -- but that usually makes our jobs harder, > not easier, because of the level of testing etc that has to go into new > features, so that even if I take them on the engineering side, SQE can veto > based on the amount of work they already have to do. On the other hand, the > most valuable contributions at this stage in the project is also the least > glamourous -- but fixes. I have a number of those, and these need to be > treated as gold. This is also why I'm spending almost all of my time > getting the rest of the source code open sourced and improving our build > and related processes, and getting the test code all open sourced so that > this can be as dead easy a process as possible. Steve, Jasper and I are > shortly going to have this documented in the WIKI. I am going to get the > build scripts out there today, hopefully, although they won't really work > until the rest of the code is open sourced, but I want to make it so that > anybody can follow along and see what we're up to. > > Richard > > On Oct 29, 2012, at 5:41 PM, Kevin Rushforth wrote: > > > Richard Bair should answer the more general question you raised. > > > > -- Kevin > > > > > > Daniel Zwolenski wrote: > >> Good to know, but I was just using this issue to frame the question: > what's the process you use to determine what's in or out? When you > "reconsider" this, who will be doing the reconsidering, and what will be > the determining factor of whether it is in or out? > >> > >> e.g. is each developer or sub-team free to pick their priorities or do > they come from a marketing team or a high-level management crew? Maybe > there's a committee that meets once a week, month, whatever? What input do > the decision makers look at when deciding, are they using solid metrics > from market research, surveys, community feedback, etc, or is it more of a > gut-feel thing? > >> You mention "lobbying". What form of lobbying? What priority do JIRA > votes get (traditionally none) vs "private emails", OTN forum posts, or > feet stamping and generally being annoying on this mailing list (that > hasn't worked for me though ;) ). Does lobbying from certain users (e.g. > oracle customers) or types of users (e.g. established corporates vs "I'm a > developer") get more weight than others - if so what's the weighting (how > many noisy plebs does it take to balance out large corporate)? > >> Any chance we could get some insight on any of that? > >> > >> > >> On Tue, Oct 30, 2012 at 11:08 AM, Kevin Rushforth < > kevin.rushforth at oracle.com > wrote: > >> > >> I'll take the heat for this one. I just bulk removed the "Lombard" > >> release for all Feature JIRAs (as opposed to Tweaks) that are not > >> part of the list of accepted features for the release, without too > >> much thought behind it. One reason for doing this is to not leave > >> the false impression that they are being actively worked on, so > >> that people can either set their expectations appropriately or > >> lobby for it being included. > >> > >> Based on your e-mail, the number of votes on this issue, and a > >> couple private e-mails I received, it seems like this is something > >> we should explicitly reconsider. > >> > >> -- Kevin > >> > >> > >> Daniel Zwolenski wrote: > >> > >> Is it possible for someone from the Oracle JFX team to outline > >> how features > >> get prioritised for inclusion in a release? > >> > >> I've been frustrated at times with things I think I are > >> important not > >> getting done, and I think a few others have had similar > >> experiences. Obviously all of us think our bug/feature is the > most > >> important thing, and not everything can get done and there has > >> to be > >> priorities. I think it would be less frustrating though if we > >> actually knew > >> the process that was used to prioritise issues - who decides, > >> and what > >> metrics are used as input? > >> > >> I noted today for example, that > >> RT-10376, > >> > >> which is simply to allow maximising the stage > >> programmatically, just got > >> bumped so its not part of Java8 and is not part of any > foreseeable > >> release. I personally don't care about this feature so much, > >> but it does > >> look like a pretty fundamental, basic thing for a windowing > >> toolkit to > >> have, so highlights the general point: > >> > >> - It was raised as a "critical feature" by Jasper Potts, so > >> it doesn't > >> > >> seem a case of not being recognised as important within > Oracle. > >> - It was raised back in 2010 so it doesn't seem a case of > >> it coming in > >> too late and just not making the cut for the release. > >> - Based on comments from Anthony Petrov it seems to be > >> already mostly > >> > >> implemented and just needs to be hooked in, so I'm assuming > >> it's not really > >> a big resourcing issue. > >> - It's got 28 votes from the community, placing it at #8 in > >> the most > >> > >> voted list by my reckoning, so there's no lack of community > >> interest in the > >> issue (3D geometry support has 12 votes for example). > >> > >> >From my vantage point, it's difficult to see why a feature > >> like this > >> wouldn't have been done months ago, let alone be off the road map > >> completely, especially when you consider some of the more > >> obscure features > >> on the roadmap. Confusion over something like this, for me at > >> least, > >> festers into a general distrust in the process, which results in > >> frustration around other issues I do consider important (like > >> build/deployment). > >> > >> Can this confusion be lessened through some better > >> communication? Is it > >> possible to explain how, in this case and in general, you guys > >> prioritise > >> JavaFX work? > >> > >> > > From phidias51 at gmail.com Wed Oct 31 08:00:31 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 31 Oct 2012 08:00:31 -0700 Subject: How does JFX work get prioritised? In-Reply-To: References: <508F1A77.3080203@oracle.com> <508F2220.6080905@oracle.com> <8E52FB4B-F4B9-48A5-94B6-B9782B8706BA@oracle.com> Message-ID: As I recall, the JCP was created to solve just these types of community engagement problems. Anyone can join the JSR's expert panel so you end up with input from individual contributors and corporations. I think when I brought that up earlier, Richard said that at some point (perhaps after Java 8) JavaFX will have its own JSR. If you want story point support there's a plugin for JIRA called Greenhopper (http://www.atlassian.com/software/greenhopper/overview) that does the trick. But from what I've seen so far, the Oracle SDLC is not agile, and not likely to become moreso any time soon. The whole "squeaky wheel" approach is really unworkable for a number of reasons: - Lack of transparency (both for the community and for the development team) - If Nicolas (or anyone else who's made promises) gets run over by a bus, then all of his promises go with him. Depending on the culture of open source projects, one of the approaches that HAS worked in the past involves commitment from both ends of the equation. The person reporting the bug or feature request provides a patch that fixes the problem and a unit test that demonstrates the problem and demonstrates the fix. Those kinds of issues get a higher priority because they are usually quicker to fix. In this particular case, SQE could give feedback to the person providing the patch and unit test, in case there's some corner case that didn't get coverage. The person providing the patch and SQE would run the entire test suite to make sure that no regressions were introduced. If everything looks ok, the patch and unit test are committed, and you see the result in the nightly build. In terms of default priorities: - I would hope that any bug that casts doubt on the future viability of desktop java (like crashes, security issues and webstart issues) gets the highest priority. - Any issue where the the component doesn't meet the minimum standard set by Swing should also be prioritized high (since this would determine whether Swing developers bother switching in the first place). If you want Swing developers to switch, you've got to exceed the capabilities of Swing without adding to the workload. - Any issue that effects the ease of development (i.e. creating/building/deploying JavaFX projects) should get a similar priority since it too would determine the likelihood of enterprise developers switching to JavaFX. - Any nice to have features (like 3D support) would get a lower priority. But that's just my two cents worth. Cheers, Mark On Wed, Oct 31, 2012 at 5:31 AM, Daniel Zwolenski wrote: > Thanks for the reply - believe it or not it does help to know this. At > least the process is just loose rather than deliberately biased towards > commercial customers, etc. > > I don't think you're going to be surprised when I say that this process > doesn't look quite ideal. It's quite a closed process and an unpredictable > one. From a community perspective there's no real visibility on what > priorities are, how much 'weight' something has or why, and when our fixes > will go in if we provide them. That doesn't really foster contributions, or > even voting or bug raising. At the same time it can lead to resentment as > to "why didn't my bug get fixed!". > > >From your team's perspective you've pretty much told us that the best way > to get something we want in is to spam all your private inboxes and annoy > the hell out of everyone and get all our friends to do the same - squeaky > wheel policy. I reckon I'm pretty annoying at times and it hasn't paid off > yet, I don't think anyone wants to encourage me to be more vocal! > > I guess it all depends on whether you are happy with this process? If so, > then business as usual and at least we now have some insight into the > process. If not we as a community then would it be worth throwing it open > to the community for ways to improve this process? Perhaps other people > have experiences on similar open source projects and can suggest systems > that work well (or highlight ones that don't)? > > I've never been involved with a community process like this but I have > worked on a number of JIRA-based projects with clients driving the priority > list. For me some of the things that worked would seem to be a good idea > for JFX. > > For example, I'd really love to see the 'Roadmap' gadget working in JFX > JIRA (currently it shows as empty), We'd then be able to very easily see > the upcoming releases and what features are planned when (or maybe you have > another way of showing this - your JIRA setup is a bit weird to me?). > Visibility on this would allow community members, your team and your > commercial clients to see all the bugs and all the issues ahead of our > issue which could well lead to us saying things like "ok, well some of > those things really are more important than my issue", or "ok that'll be > here mid next year, I can do a work around until then". > > Another great tool is the voting mechanism. I've tried to push for this > before and there was some interest but it never really eventuated. If > *everything* could be prioritised on a defined point scoring system (i.e. > move away from private emails and get these people to vote) then there > really couldn't be much complaining from any party. If commercial users and > Oracle employees need to have more weight than us plebs then I could live > with that - we just need to weight votes, so a vote by a JFX developer or > Oracle gold client is worth 10 points, and a vote by us plebs is worth 1 > (or whatever). I know JIRA doesn't support weighted votes out of the box > but if you were genuinely interested in doing something like this I would > consider trying to write a plugin for it. > > And then story points have always been my favourite tool for this sort of > stuff. If every issue was given a story point ranking then you can say we > will aim to get X story points done in this release. If you want to define > a ratio say 2/3 have to be bug fix and 1/3 can be new features then that > works well for making sure the rate of bug fix is higher than the rate of > bug creation. The great thing about story points combined with a roadmap is > that if my feature is behind a bunch of bugs well then if I help you guys > resolve those boring bugs my feature might make it on the list. In fact > that would be your easy comeback whenever someone complains their bug is > not being fixed: "help us sort out these bugs and yours is next on the > list". Even I'd have no comeback to that. > > Basically all things just aimed at predictability and visibility. Maybe > there are better ways to achieve those than my suggestions, but I do think > achieving them is fairly important to a happy, healthy community that > actively contributes and feels warm and fuzzy about doing so. > > And imagine, if you had a defined process like this, you wouldn't have to > put up with me trying to be the loudest squeaky wheel all the time. No more > emails like this one. Surely that alone would be worth it! > > > On Wed, Oct 31, 2012 at 2:40 AM, Richard Bair >wrote: > > > Haha, threw me under the bus :-). > > > > There isn't much process. We do get feedback from our inbound marketing > > team from both looking at competitors, market trends, and customer > > requests. If you have commercial work going on and haven't emailed > Nicolas > > Lorain, you ought to do so. These requests coming from our inbound > > marketing / product management team are their asks for a release. The > > engineering team has another body of work that we'd like to do, driven by > > our experience as engineers with the product, things we read on blogs or > in > > emails or on mailing lists such as this, and blind spots and holes that > we > > just know about since we didn't have time in a previous release to do > > everything we wanted to our satisfaction. Those are our asks. > > > > The high level big-picture items are negotiated between engineering and > > product management. Engineering gives estimates for the amount of work, > > etc. Product management comes with dates (which are mostly set in stone > > years in advance, because it is part of the JavaSE release dates, > including > > update releases), although of course dates can be adjusted down the line. > > These items which will take more than 2 weeks to complete are "Features" > in > > JIRA. Those items which are new API etc but which are less than 2 weeks > > work are "Tweaks". Bugs are "Bugs" (ie: something doesn't work the way it > > was meant to work -- these can affect API but are always of the nature > that > > they should have worked but was coded improperly etc). > > > > As to what goes into a release, it is a negotiation between Product > > Management, Engineering, and SQE (Software Quality Engineering). PM says > "I > > want everything", Engineering says "I can give you this and this", and > SQE > > says "I can only test this". And thus we get down to some number of > > Features that we can handle in a release. For Tweaks and Bugs, it is > only a > > negotiation between Engineering and SQE. If we can write our own tests on > > engineering side, then SQE doesn't have to be impacted, and those tweaks > / > > bug fixes are easier to get through. > > > > Votes are something that we have done an awful job of taking into this > > process, but both engineering and PM should be taking these into account > as > > customer requests in the planning process. > > > > We try to reserve a significant amount of time for bug fixing. I prefer > > fewer features until we can get the bug backlog under control and keep > the > > quality high. Obviously PM cares about that too to some extent, but they > > are really the customer advocate and asking for every new feature under > the > > sun that their contacts have requested. > > > > Which is why we've had a hard time between me asking for contributions, > > people giving contributions, and then they aren't being taken. The > problem > > is that, my main issue is that the bug backlog *must* get under control > > (including performance work), and that every new feature increases the > > backlog and makes it that much more unlikely that we'll ever get it under > > control. Of course, the sorts of things people want to contribute more > > often than not are new features -- but that usually makes our jobs > harder, > > not easier, because of the level of testing etc that has to go into new > > features, so that even if I take them on the engineering side, SQE can > veto > > based on the amount of work they already have to do. On the other hand, > the > > most valuable contributions at this stage in the project is also the > least > > glamourous -- but fixes. I have a number of those, and these need to be > > treated as gold. This is also why I'm spending almost all of my time > > getting the rest of the source code open sourced and improving our build > > and related processes, and getting the test code all open sourced so that > > this can be as dead easy a process as possible. Steve, Jasper and I are > > shortly going to have this documented in the WIKI. I am going to get the > > build scripts out there today, hopefully, although they won't really work > > until the rest of the code is open sourced, but I want to make it so that > > anybody can follow along and see what we're up to. > > > > Richard > > > > On Oct 29, 2012, at 5:41 PM, Kevin Rushforth wrote: > > > > > Richard Bair should answer the more general question you raised. > > > > > > -- Kevin > > > > > > > > > Daniel Zwolenski wrote: > > >> Good to know, but I was just using this issue to frame the question: > > what's the process you use to determine what's in or out? When you > > "reconsider" this, who will be doing the reconsidering, and what will be > > the determining factor of whether it is in or out? > > >> > > >> e.g. is each developer or sub-team free to pick their priorities or do > > they come from a marketing team or a high-level management crew? Maybe > > there's a committee that meets once a week, month, whatever? What input > do > > the decision makers look at when deciding, are they using solid metrics > > from market research, surveys, community feedback, etc, or is it more of > a > > gut-feel thing? > > >> You mention "lobbying". What form of lobbying? What priority do JIRA > > votes get (traditionally none) vs "private emails", OTN forum posts, or > > feet stamping and generally being annoying on this mailing list (that > > hasn't worked for me though ;) ). Does lobbying from certain users (e.g. > > oracle customers) or types of users (e.g. established corporates vs "I'm > a > > developer") get more weight than others - if so what's the weighting (how > > many noisy plebs does it take to balance out large corporate)? > > >> Any chance we could get some insight on any of that? > > >> > > >> > > >> On Tue, Oct 30, 2012 at 11:08 AM, Kevin Rushforth < > > kevin.rushforth at oracle.com > wrote: > > >> > > >> I'll take the heat for this one. I just bulk removed the "Lombard" > > >> release for all Feature JIRAs (as opposed to Tweaks) that are not > > >> part of the list of accepted features for the release, without too > > >> much thought behind it. One reason for doing this is to not leave > > >> the false impression that they are being actively worked on, so > > >> that people can either set their expectations appropriately or > > >> lobby for it being included. > > >> > > >> Based on your e-mail, the number of votes on this issue, and a > > >> couple private e-mails I received, it seems like this is something > > >> we should explicitly reconsider. > > >> > > >> -- Kevin > > >> > > >> > > >> Daniel Zwolenski wrote: > > >> > > >> Is it possible for someone from the Oracle JFX team to outline > > >> how features > > >> get prioritised for inclusion in a release? > > >> > > >> I've been frustrated at times with things I think I are > > >> important not > > >> getting done, and I think a few others have had similar > > >> experiences. Obviously all of us think our bug/feature is the > > most > > >> important thing, and not everything can get done and there has > > >> to be > > >> priorities. I think it would be less frustrating though if we > > >> actually knew > > >> the process that was used to prioritise issues - who decides, > > >> and what > > >> metrics are used as input? > > >> > > >> I noted today for example, that > > >> RT-10376, > > >> > > >> which is simply to allow maximising the stage > > >> programmatically, just got > > >> bumped so its not part of Java8 and is not part of any > > foreseeable > > >> release. I personally don't care about this feature so much, > > >> but it does > > >> look like a pretty fundamental, basic thing for a windowing > > >> toolkit to > > >> have, so highlights the general point: > > >> > > >> - It was raised as a "critical feature" by Jasper Potts, so > > >> it doesn't > > >> > > >> seem a case of not being recognised as important within > > Oracle. > > >> - It was raised back in 2010 so it doesn't seem a case of > > >> it coming in > > >> too late and just not making the cut for the release. > > >> - Based on comments from Anthony Petrov it seems to be > > >> already mostly > > >> > > >> implemented and just needs to be hooked in, so I'm assuming > > >> it's not really > > >> a big resourcing issue. > > >> - It's got 28 votes from the community, placing it at #8 in > > >> the most > > >> > > >> voted list by my reckoning, so there's no lack of community > > >> interest in the > > >> issue (3D geometry support has 12 votes for example). > > >> > > >> >From my vantage point, it's difficult to see why a feature > > >> like this > > >> wouldn't have been done months ago, let alone be off the road > map > > >> completely, especially when you consider some of the more > > >> obscure features > > >> on the roadmap. Confusion over something like this, for me at > > >> least, > > >> festers into a general distrust in the process, which results > in > > >> frustration around other issues I do consider important (like > > >> build/deployment). > > >> > > >> Can this confusion be lessened through some better > > >> communication? Is it > > >> possible to explain how, in this case and in general, you guys > > >> prioritise > > >> JavaFX work? > > >> > > >> > > > > > From chien.yang at oracle.com Wed Oct 31 08:04:20 2012 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 31 Oct 2012 08:04:20 -0700 Subject: status of 3D support on Linux In-Reply-To: <5090E468.7050702@bestsolution.at> References: <50903AD9.9010009@bestsolution.at> <50905AC0.6050608@oracle.com> <5090E468.7050702@bestsolution.at> Message-ID: <50913DF4.50809@oracle.com> Hi Udo, We are monitoring the GPU driver progress, both open source and proprietary versions, from the various vendors. That is why we decided to add ATI's fglrx driver to our supported platform after it has passed our internal evaluation. We want to ensure good user experience of our JavaFX library. The goal is to avoid rendering artifacts and hard crashes that are beyond our control. Thanks, - Chien On 10/31/12 1:42 AM, Udo Rader wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/30/2012 11:54 PM, Kevin Rushforth wrote: >>> #2 what about other GPUs, such as the extremely common Intel HD >>> GPUs? >> Unplanned for FX 8. The problem is that the Intel OpenGL drivers >> on Linux have been historically very bad in terms of quality and >> compliance. There is some anecdotal evidence that this is changing, >> but we don't want to support it. There is a system property you can >> set to force this for testing, but no way to deploy an application >> using it. > Yes, the intel drivers have a bad history in some areas. OTOH, you > might say the same about general usability of the proprietary drivers > under Linux (ie the fglrx driver). > >>> #3 any plans to support OpenSource/Gallium3D based drivers (ie >>> nouveau/radeon)? >> Not support, no. But it might "just work" and is something you >> could try. > I understand, "support" is a somewhat dangerous term, of course. > > How then do we force things on unsupported platforms? Right now, 3D > simply does not work and we did not find anything about the system > property you mention. > > Thanks > > Udo > > - -- > Udo Rader, CEO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQkORoAAoJEJA9QoEqa9WBdFMH/il9Q28ajPqoKdNTe9hElmnZ > TaNQ3YdELleO06FxiRpKPvhCaWBrLtUGHbmDOLRFnaBhXgVg1MEF6SBif7rkcgjw > WAP3POAkWqoCjvfgEMaIVQGZMMZ7529OVxXN3lShdo2PBj4eszhHjB+lQzq87eQR > ISzrngZUCiNCApdauJGPPx0AfT1+HWHfOTo9I9P3oLe6IEx7QUtteB6Q+phbFM8p > kY7xIHlCXTPWy78IDe8plx+aCfKMeDgSScyiVhYCnIdWYMyjBLwPQrJRqZRSs6/i > kGONxWm2933yw3h51labM2qvLX4s+rlDKwhtYY3IFBXBQZc5/LxoVjoFw+YJsno= > =SrLb > -----END PGP SIGNATURE----- From chien.yang at oracle.com Wed Oct 31 08:19:30 2012 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 31 Oct 2012 08:19:30 -0700 Subject: status of 3D support on Linux In-Reply-To: <137513.13779.51476-14779-2087805509-1351675412@seznam.cz> References: <137513.13779.51476-14779-2087805509-1351675412@seznam.cz> Message-ID: <50914182.9040000@oracle.com> Hi George, Actually Intel OpenGL driver has never been supported on Java and Java 3D. However Intel is making good progress on its Intel HD GPU series recently. It's Windows D3D driver is supported on JavaFX for some time now. We hope similar progress is made on its OpenGL driver. Has everyone tested it on Linux? - Chien On 10/31/12 2:23 AM, goddard at seznam.cz wrote: > It's startling that one of the most common GPUs is not supported. > I remember that it was supported back in the Java 3D days... > > Regards, George > > ------------ P?vodn? zpr?va ------------ > Od: Udo Rader > P?edm?t: Re: status of 3D support on Linux > Datum: 31.10.2012 09:58:03 > ---------------------------------------- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/30/2012 11:54 PM, Kevin Rushforth wrote: >>> #2 what about other GPUs, such as the extremely common Intel HD >>> GPUs? >> Unplanned for FX 8. The problem is that the Intel OpenGL drivers >> on Linux have been historically very bad in terms of quality and >> compliance. There is some anecdotal evidence that this is changing, >> but we don't want to support it. There is a system property you can >> set to force this for testing, but no way to deploy an application >> using it. > Yes, the intel drivers have a bad history in some areas. OTOH, you > might say the same about general usability of the proprietary drivers > under Linux (ie the fglrx driver). > >>> #3 any plans to support OpenSource/Gallium3D based drivers (ie >>> nouveau/radeon)? >> Not support, no. But it might "just work" and is something you >> could try. > I understand, "support" is a somewhat dangerous term, of course. > > How then do we force things on unsupported platforms? Right now, 3D > simply does not work and we did not find anything about the system > property you mention. > > Thanks > > Udo > > - -- > Udo Rader, CEO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQkORoAAoJEJA9QoEqa9WBdFMH/il9Q28ajPqoKdNTe9hElmnZ > TaNQ3YdELleO06FxiRpKPvhCaWBrLtUGHbmDOLRFnaBhXgVg1MEF6SBif7rkcgjw > WAP3POAkWqoCjvfgEMaIVQGZMMZ7529OVxXN3lShdo2PBj4eszhHjB+lQzq87eQR > ISzrngZUCiNCApdauJGPPx0AfT1+HWHfOTo9I9P3oLe6IEx7QUtteB6Q+phbFM8p > kY7xIHlCXTPWy78IDe8plx+aCfKMeDgSScyiVhYCnIdWYMyjBLwPQrJRqZRSs6/i > kGONxWm2933yw3h51labM2qvLX4s+rlDKwhtYY3IFBXBQZc5/LxoVjoFw+YJsno= > =SrLb > -----END PGP SIGNATURE----- > > From udo.rader at bestsolution.at Wed Oct 31 08:51:01 2012 From: udo.rader at bestsolution.at (Udo Rader) Date: Wed, 31 Oct 2012 16:51:01 +0100 Subject: status of 3D support on Linux In-Reply-To: <50913DF4.50809@oracle.com> References: <50903AD9.9010009@bestsolution.at> <50905AC0.6050608@oracle.com> <5090E468.7050702@bestsolution.at> <50913DF4.50809@oracle.com> Message-ID: <509148E5.1030305@bestsolution.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, sure, nobody wants crashing applications. OTOH there is no way to know if an application crashes until someone can at least experimentally test it. For example we are currently trying to evaluate if JavaFX might be a good choice for a new application running on embedded scale devices, all driven by Intel 3600 GMA GPUs. On the one hand, none of our Linux developers are running at least the proprietary fglrx drivers for massive instability reasons (yes: artifacts, memory leaks, ...) and then additionally we find that Intel GPUs are completely unsupported in Linux. So is there a way to at least override the JavaFX GPU blacklist (like the system setting Kevin R mentioned)? And in order to not only complain and whine about how things are: what were be the required steps to improve (at least inofficial) 3D support for JavaFX in Linux? Can "interested parties" improve the situation? Thanks Udo On 10/31/2012 04:04 PM, Chien Yang wrote: > Hi Udo, > > We are monitoring the GPU driver progress, both open source and > proprietary versions, from the various vendors. That is why we > decided to add ATI's fglrx driver to our supported platform after > it has passed our internal evaluation. We want to ensure good user > experience of our JavaFX library. The goal is to avoid rendering > artifacts and hard crashes that are beyond our control. > > Thanks, - Chien > > On 10/31/12 1:42 AM, Udo Rader wrote: On 10/30/2012 11:54 PM, Kevin > Rushforth wrote: >>>>> #2 what about other GPUs, such as the extremely common >>>>> Intel HD GPUs? >>>> Unplanned for FX 8. The problem is that the Intel OpenGL >>>> drivers on Linux have been historically very bad in terms of >>>> quality and compliance. There is some anecdotal evidence that >>>> this is changing, but we don't want to support it. There is a >>>> system property you can set to force this for testing, but no >>>> way to deploy an application using it. > Yes, the intel drivers have a bad history in some areas. OTOH, you > might say the same about general usability of the proprietary > drivers under Linux (ie the fglrx driver). > >>>>> #3 any plans to support OpenSource/Gallium3D based drivers >>>>> (ie nouveau/radeon)? >>>> Not support, no. But it might "just work" and is something >>>> you could try. > I understand, "support" is a somewhat dangerous term, of course. > > How then do we force things on unsupported platforms? Right now, > 3D simply does not work and we did not find anything about the > system property you mention. > > Thanks > > Udo > > -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ Reg. Nr. FN 222302s am > Firmenbuchgericht Innsbruck > - -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkUjlAAoJEJA9QoEqa9WBeBkH/3xCT4WC6HDSTgBm/s9UAEm9 3ko3SPol5QFJ4mehEmB0XOSQYjYlOQwG09E3sSlmNArMfmbdeDgwiK2hghYsUzvj Klwc1Qk5r+f4gcYlJJGpE1asnWdV1Ky7TiwTm1EbP3ZT/BERAFDo8wfcQwiHIsOG t/6MQzsq3mCjH+cIDMT5jxdAqqfMYWNcV6z1uviH5LAFs8iw4WHPh44g58Ve98Na ca+BXljRvKaSODOEQCtXxgVe6zBNzQB3oid15rPnBWJDnwpYhzFxpfCn3P2rBJVq bidcG/k5lAR19WKQTf99pbThFWmm84Vp7TbtmcOYSLOEGr9FmOFJtACoCmFi8aY= =WHw3 -----END PGP SIGNATURE----- From chien.yang at oracle.com Wed Oct 31 09:10:21 2012 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 31 Oct 2012 09:10:21 -0700 Subject: status of 3D support on Linux In-Reply-To: <509148E5.1030305@bestsolution.at> References: <50903AD9.9010009@bestsolution.at> <50905AC0.6050608@oracle.com> <5090E468.7050702@bestsolution.at> <50913DF4.50809@oracle.com> <509148E5.1030305@bestsolution.at> Message-ID: <50914D6D.6060009@oracle.com> Hi Udo, Thank you for your understanding. You can bypass JavaFX GPU blacklist checking mechanism by specifying the following property at start up: -Dprism.forceGPU=false It will be great if you have the resources, in-house, to evaluate a particular GPU that interest you. We may be able to assist you further by taking it off the blacklist, if it passes your internal evaluation process. Of course, this will include passing our internal SQE process too. Thanks, - Chien On 10/31/12 8:51 AM, Udo Rader wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yes, sure, nobody wants crashing applications. > > OTOH there is no way to know if an application crashes until someone > can at least experimentally test it. > > For example we are currently trying to evaluate if JavaFX might be a > good choice for a new application running on embedded scale devices, > all driven by Intel 3600 GMA GPUs. > > On the one hand, none of our Linux developers are running at least the > proprietary fglrx drivers for massive instability reasons (yes: > artifacts, memory leaks, ...) and then additionally we find that Intel > GPUs are completely unsupported in Linux. > > So is there a way to at least override the JavaFX GPU blacklist (like > the system setting Kevin R mentioned)? > > And in order to not only complain and whine about how things are: what > were be the required steps to improve (at least inofficial) 3D support > for JavaFX in Linux? Can "interested parties" improve the situation? > > Thanks > > Udo > > On 10/31/2012 04:04 PM, Chien Yang wrote: >> Hi Udo, >> >> We are monitoring the GPU driver progress, both open source and >> proprietary versions, from the various vendors. That is why we >> decided to add ATI's fglrx driver to our supported platform after >> it has passed our internal evaluation. We want to ensure good user >> experience of our JavaFX library. The goal is to avoid rendering >> artifacts and hard crashes that are beyond our control. >> >> Thanks, - Chien >> >> On 10/31/12 1:42 AM, Udo Rader wrote: On 10/30/2012 11:54 PM, Kevin >> Rushforth wrote: >>>>>> #2 what about other GPUs, such as the extremely common >>>>>> Intel HD GPUs? >>>>> Unplanned for FX 8. The problem is that the Intel OpenGL >>>>> drivers on Linux have been historically very bad in terms of >>>>> quality and compliance. There is some anecdotal evidence that >>>>> this is changing, but we don't want to support it. There is a >>>>> system property you can set to force this for testing, but no >>>>> way to deploy an application using it. >> Yes, the intel drivers have a bad history in some areas. OTOH, you >> might say the same about general usability of the proprietary >> drivers under Linux (ie the fglrx driver). >> >>>>>> #3 any plans to support OpenSource/Gallium3D based drivers >>>>>> (ie nouveau/radeon)? >>>>> Not support, no. But it might "just work" and is something >>>>> you could try. >> I understand, "support" is a somewhat dangerous term, of course. >> >> How then do we force things on unsupported platforms? Right now, >> 3D simply does not work and we did not find anything about the >> system property you mention. >> >> Thanks >> >> Udo >> >> -- Udo Rader, CEO BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >> http://www.bestsolution.at/ Reg. Nr. FN 222302s am >> Firmenbuchgericht Innsbruck >> > - -- > Udo Rader, CEO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQkUjlAAoJEJA9QoEqa9WBeBkH/3xCT4WC6HDSTgBm/s9UAEm9 > 3ko3SPol5QFJ4mehEmB0XOSQYjYlOQwG09E3sSlmNArMfmbdeDgwiK2hghYsUzvj > Klwc1Qk5r+f4gcYlJJGpE1asnWdV1Ky7TiwTm1EbP3ZT/BERAFDo8wfcQwiHIsOG > t/6MQzsq3mCjH+cIDMT5jxdAqqfMYWNcV6z1uviH5LAFs8iw4WHPh44g58Ve98Na > ca+BXljRvKaSODOEQCtXxgVe6zBNzQB3oid15rPnBWJDnwpYhzFxpfCn3P2rBJVq > bidcG/k5lAR19WKQTf99pbThFWmm84Vp7TbtmcOYSLOEGr9FmOFJtACoCmFi8aY= > =WHw3 > -----END PGP SIGNATURE----- From Peter.Zhelezniakov at oracle.com Wed Oct 31 09:11:21 2012 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Wed, 31 Oct 2012 20:11:21 +0400 Subject: API request: Adding WebEngine.userAgent Message-ID: <50914DA9.2070004@oracle.com> Hello, I propose adding [userAgent] property to the WebEngine class. The new property will be used for the value of the User-Agent HTTP header. Rationale: HTTP servers sometimes check the User-Agent header to detect browser they are talking to, and may serve different HTML to different browsers. E.g. if a server detects an unknown browser it may send it unoptimized, lowest-common-denominator version of a Web page, or page optimized for mobile devices. This is why application developers may want to pretend they're running Chrome or Safari or whatever. This work is tracked under RT-22153. With 9 votes, it is the most-voted-for WebView feature. The new methods will read: class javafx.scene.web.WebEngine { /** * Specifies user agent ID string. This string is the value of the * {@code User-Agent} HTTP header. * * @defaultValue true * @since 8.0 */ public final void setUserAgent(String value); public final String getUserAgent(); public final StringProperty userAgentProperty(); } Thanks! -- Peter From lehmann at media-interactive.de Wed Oct 31 09:22:35 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 31 Oct 2012 17:22:35 +0100 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <50914DA9.2070004@oracle.com> References: <50914DA9.2070004@oracle.com> Message-ID: <5091504B.7090509@media-interactive.de> Makes sense. I suggest to use a different defaultValue though ;-) On 31.10.2012 17:11, Peter Zhelezniakov wrote: > The new methods will read: > > class javafx.scene.web.WebEngine { > /** > * Specifies user agent ID string. This string is the value of the > * {@code User-Agent} HTTP header. > * > * @defaultValue true > * @since 8.0 > */ > public final void setUserAgent(String value); > public final String getUserAgent(); > public final StringProperty userAgentProperty(); > } From lehmann at media-interactive.de Wed Oct 31 09:41:36 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 31 Oct 2012 17:41:36 +0100 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <5091504B.7090509@media-interactive.de> References: <50914DA9.2070004@oracle.com> <5091504B.7090509@media-interactive.de> Message-ID: <509154C0.20704@media-interactive.de> On second thought, I don't know this tag in Javadoc. Maybe it means "has a default value? yes". On 31.10.2012 17:22, Werner Lehmann wrote: > I suggest to use a different defaultValue though From hang.vo at oracle.com Wed Oct 31 10:04:05 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 31 Oct 2012 17:04:05 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20121031170411.80359476B9@hg.openjdk.java.net> Changeset: 4e51d2d9a6ff Author: Seeon Birger Date: 2012-10-24 19:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4e51d2d9a6ff Add runtime option to enable virtual keyboard caching. To enable run with -Dcom.sun.javafx.scene.control.skin.FXVK.cache=true ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: ed8fff136275 Author: Lisa.Selle at oracle.com Date: 2012-10-26 22:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ed8fff136275 Merge Changeset: d908a2cb4614 Author: David Hill Date: 2012-10-31 09:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d908a2cb4614 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt From richard.bair at oracle.com Wed Oct 31 14:02:07 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 31 Oct 2012 14:02:07 -0700 Subject: Building Javadoc in the OpenJFX distribution In-Reply-To: References: Message-ID: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> Kevin, do you know? On Oct 31, 2012, at 3:21 AM, Peter Pilgrim wrote: > Hi > > What is the way to build the javadocs locally in the openjfx distribution 2.2? > > % cd rt > > % ant javadoc > > % ant ??? > > TIA > > -- > Peter Pilgrim, From phidias51 at gmail.com Wed Oct 31 14:13:54 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 31 Oct 2012 14:13:54 -0700 Subject: Building Javadoc in the OpenJFX distribution In-Reply-To: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> References: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> Message-ID: There was a maven build the last time I checked. If it's still there, then *mvn javadoc:javadoc* should get you what you need. Cheers, Mark On Wed, Oct 31, 2012 at 2:02 PM, Richard Bair wrote: > Kevin, do you know? > > On Oct 31, 2012, at 3:21 AM, Peter Pilgrim wrote: > > > Hi > > > > What is the way to build the javadocs locally in the openjfx > distribution 2.2? > > > > % cd rt > > > > % ant javadoc > > > > % ant ??? > > > > TIA > > > > -- > > Peter Pilgrim, > > From richard.bair at oracle.com Wed Oct 31 14:27:59 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 31 Oct 2012 14:27:59 -0700 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <509154C0.20704@media-interactive.de> References: <50914DA9.2070004@oracle.com> <5091504B.7090509@media-interactive.de> <509154C0.20704@media-interactive.de> Message-ID: Good question! What is the default value we want to use? "JavaFX-Webkit" or something?' On Oct 31, 2012, at 9:41 AM, Werner Lehmann wrote: > On second thought, I don't know this tag in Javadoc. Maybe it means "has a default value? yes". > > On 31.10.2012 17:22, Werner Lehmann wrote: >> I suggest to use a different defaultValue though From kevin.rushforth at oracle.com Wed Oct 31 16:57:06 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 31 Oct 2012 16:57:06 -0700 Subject: Building Javadoc in the OpenJFX distribution In-Reply-To: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> References: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> Message-ID: <5091BAD2.1040209@oracle.com> I don't think this is wired up for the openjfx repo. It would be a good addition, though, if someone wanted to file a JIRA. We wouldn't do it in 2.2, though, we would do it in 8. Note that eventually we need to integrate our javadocs into the openjdk docs, but it will still be useful to be able to build them separately. -- Kevin Richard Bair wrote: > Kevin, do you know? > > On Oct 31, 2012, at 3:21 AM, Peter Pilgrim wrote: > > >> Hi >> >> What is the way to build the javadocs locally in the openjfx distribution 2.2? >> >> % cd rt >> >> % ant javadoc >> >> % ant ??? >> >> TIA >> >> -- >> Peter Pilgrim, >> > > From randahl at rockit.dk Wed Oct 31 17:21:36 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 1 Nov 2012 01:21:36 +0100 Subject: API request: Adding WebEngine.userAgent In-Reply-To: References: <50914DA9.2070004@oracle.com> <5091504B.7090509@media-interactive.de> <509154C0.20704@media-interactive.de> Message-ID: <31E8A767-17E2-4DD8-8CD9-E61B578F9C06@rockit.dk> Richard, I agree with choosing a JavaFX specific user agent string rather than pretending to be somebody else, but if we do, it should be documented that the default user agent string should only be used, if the JavaFX WebView is not used to visit arbitrary websites. Once a user goes surfing the full web through the WebView there is a risk that some sites might break, since they do not know how to handle a JavaFX specific user agent. Perhaps it would be relevant to support both an ideal, honest JavaFX specific user agent string and a Mozilla/X variant and let developers switch between these two depending on the application use case. Randahl On Oct 31, 2012, at 22:27 , Richard Bair wrote: > Good question! What is the default value we want to use? "JavaFX-Webkit" or something?' > > On Oct 31, 2012, at 9:41 AM, Werner Lehmann wrote: > >> On second thought, I don't know this tag in Javadoc. Maybe it means "has a default value? yes". >> >> On 31.10.2012 17:22, Werner Lehmann wrote: >>> I suggest to use a different defaultValue though > From hang.vo at oracle.com Wed Oct 31 18:37:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Nov 2012 01:37:58 +0000 Subject: hg: openjfx/sandbox-8/controls/rt: TreeTableView take #2: This changeset updates the TreeTableView implementation and API quite drastically, taking it from a proof of concept to what I would say is a relatively decent API and implementation (although there is certainly much more to do). For further details, refer to RT-17288. Message-ID: <20121101013759.DE4B7476D4@hg.openjdk.java.net> Changeset: 3d6245404385 Author: jgiles Date: 2012-11-01 14:13 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/3d6245404385 TreeTableView take #2: This changeset updates the TreeTableView implementation and API quite drastically, taking it from a proof of concept to what I would say is a relatively decent API and implementation (although there is certainly much more to do). For further details, refer to RT-17288. + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/ResizeFeaturesBase.java ! javafx-ui-controls/src/javafx/scene/control/SpanModel.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java + javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java + javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java + javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java