From tom.schindl at bestsolution.at Thu Nov 1 00:47:47 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 01 Nov 2012 08:47:47 +0100 Subject: Building Javadoc in the OpenJFX distribution In-Reply-To: <5091BAD2.1040209@oracle.com> References: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> <5091BAD2.1040209@oracle.com> Message-ID: <50922923.2000406@bestsolution.at> What sense does it make to build them if most of the sources are not yet provided? Tom Am 01.11.12 00:57, schrieb Kevin Rushforth: > 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, >>> >> >> -- 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 Thu Nov 1 01:19:02 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 01 Nov 2012 09:19:02 +0100 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: <50923076.9020609@oracle.com> Hello, the tag should contain the actual default value. Some logic used to be based on it (builders I think), but is not any more. We try to maintain correct values though, because the javafx-specific doclet produces a "Default value" section based on it, which is quite a useful piece of information to have documented. Regards, Pavel On 31.10.2012 17:41, 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 pavel.safrata at oracle.com Thu Nov 1 01:22:51 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 01 Nov 2012 09:22:51 +0100 Subject: Building Javadoc in the OpenJFX distribution In-Reply-To: <50922923.2000406@bestsolution.at> References: <2902EE39-AC44-409F-A8BC-6C93DD646566@oracle.com> <5091BAD2.1040209@oracle.com> <50922923.2000406@bestsolution.at> Message-ID: <5092315B.7090108@oracle.com> Hi Tom, most of the sources are not yet provided, but most of the public API which constitutes the documentation is already open-sourced. So I think it would make perfect sense to let users check their javadoc if they decide to contribute an API modification. Regards, Pavel On 1.11.2012 8:47, Tom Schindl wrote: > What sense does it make to build them if most of the sources are not yet > provided? > > Tom > > Am 01.11.12 00:57, schrieb Kevin Rushforth: >> 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 hang.vo at oracle.com Thu Nov 1 07:48:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Nov 2012 14:48:32 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25931: Gradient.valueOf doesn't parse rgb(), hsl() color notation Message-ID: <20121101144835.6FC54476EE@hg.openjdk.java.net> Changeset: a5b821631839 Author: Eva Krejcirova Date: 2012-11-01 15:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a5b821631839 RT-25931: Gradient.valueOf doesn't parse rgb(), hsl() color notation ! javafx-ui-common/src/com/sun/javafx/scene/paint/GradientUtils.java ! javafx-ui-common/test/unit/javafx/scene/paint/LinearGradientTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/RadialGradientTest.java From Peter.Zhelezniakov at oracle.com Thu Nov 1 08:14:05 2012 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Thu, 01 Nov 2012 19:14:05 +0400 Subject: API request: Adding WebEngine.userAgent In-Reply-To: References: Message-ID: <509291BD.3010006@oracle.com> > From: Werner Lehmann Makes sense. I suggest to use a different defaultValue though ;-) Yep, thanks for noticing. I think I'll remove this line. The default value is system dependent. E.g. on Linux it is Mozilla/5.0 (Linux x86_64) AppleWebKit/537.2 (KHTML, like Gecko) JavaFX/8.0 Safari/537.2 Compare that to Chrome's ID: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5 or Safari's on Mac: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 So we follow the pattern used by other Webkit-based browsers, report proper version of Webkit, and proudly mention JavaFX at the same time ;) -- Peter From vasiliy.baranov at oracle.com Thu Nov 1 08:55:53 2012 From: vasiliy.baranov at oracle.com (Vasiliy Baranov) Date: Thu, 01 Nov 2012 19:55:53 +0400 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <509291BD.3010006@oracle.com> References: <509291BD.3010006@oracle.com> Message-ID: <50929B89.8060201@oracle.com> So, for WebEngine to send out the below system-dependent value, what should be the value of the WebEngine.userAgent property? null? That makes sense to me. It also makes sense for the WebEngine.userAgent property to default to null then. -- Vasiliy On 01.11.2012 19:14, Peter Zhelezniakov wrote: >> From: Werner Lehmann > Makes sense. I suggest to use a different defaultValue though ;-) > > Yep, thanks for noticing. I think I'll remove this line. > > The default value is system dependent. E.g. on Linux it is > > Mozilla/5.0 (Linux x86_64) AppleWebKit/537.2 (KHTML, like Gecko) > JavaFX/8.0 Safari/537.2 > > Compare that to Chrome's ID: > > Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) > Chrome/19.0.1084.52 Safari/536.5 > > or Safari's on Mac: > > Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 > (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 > > So we follow the pattern used by other Webkit-based browsers, report > proper version of Webkit, and proudly mention JavaFX at the same time ;) > From peter.pilgrim at gmail.com Thu Nov 1 10:11:52 2012 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Thu, 1 Nov 2012 17:11:52 +0000 Subject: Where is development branch for the source code and is it open for contribution In-Reply-To: References: <20120915201124.242840@gmx.com> Message-ID: Hi Johan Where you talking about the OpenJDK (jdk8) build from here http://jdk8.java.net/lambda/ ? On 23 October 2012 18:05, Johan Vos wrote: > 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 So far I got to the 6th step 1) mkdir open-jfx-8 2) hg clone http://hg.openjdk.java.net/openjfx/8/master 3) cd master 4) hg clone http://hg.openjdk.java.net/openjfx/8/master/rt 5) mkdir artifacts/sdk/rt/lib 6) cp ${OPENJFX8_HOME}/jre/lib/jfxrt.jar artifacts/sdk/rt/lib So where is the jfxrt.jar downloaded from to bootstrap the compilation? -- Peter Pilgrim, From david.dehaven at oracle.com Thu Nov 1 11:12:20 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 1 Nov 2012 11:12:20 -0700 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: The easy way to find out: http://whatsmyuseragent.com -DrD- > 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 richard.bair at ORACLE.COM Thu Nov 1 14:42:43 2012 From: richard.bair at ORACLE.COM (Richard Bair) Date: Thu, 1 Nov 2012 14:42:43 -0700 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: <4AD430F6-A34A-4E13-8906-09106B5D981C@ORACLE.COM> That is one heck of a version string: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 Safari/536.25 My feeling is that the default user agent name for FX should be clearly FX and well defined, not null. It should be exactly what would be available to JS code executing within the WebEngine. Richard On Nov 1, 2012, at 11:12 AM, David DeHaven wrote: > > The easy way to find out: > http://whatsmyuseragent.com > > -DrD- > >> 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 Richard.Bair at oracle.com Thu Nov 1 14:44:01 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Thu, 1 Nov 2012 14:44:01 -0700 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <31E8A767-17E2-4DD8-8CD9-E61B578F9C06@rockit.dk> References: <50914DA9.2070004@oracle.com> <5091504B.7090509@media-interactive.de> <509154C0.20704@media-interactive.de> <31E8A767-17E2-4DD8-8CD9-E61B578F9C06@rockit.dk> Message-ID: > 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. If we can do that (it looks like Safari does just this), then lets definitely do it. Richard From richard.bair at oracle.com Thu Nov 1 14:45:36 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Nov 2012 14:45:36 -0700 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <509291BD.3010006@oracle.com> References: <509291BD.3010006@oracle.com> Message-ID: <685C6482-51C8-4387-AFEF-951FE7F78FA8@oracle.com> > So we follow the pattern used by other Webkit-based browsers, report > proper version of Webkit, and proudly mention JavaFX at the same time ;) Sounds good :-). From hang.vo at oracle.com Thu Nov 1 22:51:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Nov 2012 05:51:39 +0000 Subject: hg: openjfx/8/master/rt: 7 new changesets Message-ID: <20121102055215.AA64747722@hg.openjdk.java.net> Changeset: 1089c39177ad Author: "Jasper Potts" Date: 2012-10-25 15:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/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/master/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/master/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/master/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/master/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/master/rt/rev/526513110eba Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 8e85e840a981 Author: hudson Date: 2012-11-01 18:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8e85e840a981 Added tag 8.0-b63 for changeset 526513110eba ! .hgtags From lehmann at media-interactive.de Fri Nov 2 04:55:09 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 2 Nov 2012 12:55:09 +0100 Subject: How to trigger property invalidation? Message-ID: <5093B49D.1040005@media-interactive.de> Hi, for an ObjectProperty, is it possible to trigger invalidation manually when MyBean.myProperty changes? Basically I'd like to call markInvalid() but it is private. And set() compares old and new value by reference before invalidating, so won't see the change either. Workaround seems to be to copy the bean to another instance and assign the new instance to the object property. Rgds Werner From pavel.safrata at oracle.com Fri Nov 2 07:50:56 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Fri, 02 Nov 2012 15:50:56 +0100 Subject: How to trigger property invalidation? In-Reply-To: <5093B49D.1040005@media-interactive.de> References: <5093B49D.1040005@media-interactive.de> Message-ID: <5093DDD0.8030106@oracle.com> Hi Werner, I think that you cannot trigger invalidation manually by design. The property holds a reference and should not be concerned with changes of anything else than the reference. There would be various issues with it, for example there are change notifications bound to the invalidation, which would produce a weird notification of the property being changed to the same value. I think the right approach is to listen directly on the myProperty instead of tweaking the invalidation mechanism. With Regards, Pavel On 2.11.2012 12:55, Werner Lehmann wrote: > Hi, > > for an ObjectProperty, is it possible to trigger invalidation > manually when MyBean.myProperty changes? Basically I'd like to call > markInvalid() but it is private. And set() compares old and new value > by reference before invalidating, so won't see the change either. > > Workaround seems to be to copy the bean to another instance and assign > the new instance to the object property. > > Rgds > Werner From lehmann at media-interactive.de Fri Nov 2 08:25:15 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 2 Nov 2012 16:25:15 +0100 Subject: How to trigger property invalidation? In-Reply-To: <5093DDD0.8030106@oracle.com> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> Message-ID: <5093E5DB.2000503@media-interactive.de> Pavel, unfortunately I cannot listen to changes on myProperty because it is not an observable property: MyBean is a domain bean provided by the server and those beans do not have observable properties. Thanks for the clarification though. In my case this means that I have to clone the bean everytime when a slider position changes so that I can replace the property value I am actually observing (the MyBean property). Seems to be quick enough but is hardly elegant... Werner On 02.11.2012 15:50, Pavel Safrata wrote: > Hi Werner, > I think that you cannot trigger invalidation manually by design. The > property holds a reference and should not be concerned with changes of > anything else than the reference. There would be various issues with it, > for example there are change notifications bound to the invalidation, > which would produce a weird notification of the property being changed > to the same value. I think the right approach is to listen directly on > the myProperty instead of tweaking the invalidation mechanism. > > With Regards, > Pavel > > On 2.11.2012 12:55, Werner Lehmann wrote: >> Hi, >> >> for an ObjectProperty, is it possible to trigger invalidation >> manually when MyBean.myProperty changes? Basically I'd like to call >> markInvalid() but it is private. And set() compares old and new value >> by reference before invalidating, so won't see the change either. >> >> Workaround seems to be to copy the bean to another instance and assign >> the new instance to the object property. >> >> Rgds >> Werner From steve.x.northover at oracle.com Fri Nov 2 09:03:06 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 02 Nov 2012 12:03:06 -0400 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <508FAEDB.90600@oracle.com> References: <5086FE81.8000601@oracle.com> <508A8D13.6030808@oracle.com> <508ABD28.6080402@oracle.com> <508E6D58.3050301@oracle.com> <508E9E04.10209@oracle.com> <508FAEDB.90600@oracle.com> Message-ID: <5093EEBA.40108@oracle.com> Hi Pavel, In order to make more progress on the implementation, we have decided to enter JIRA issues for your API suggestions and follow up there. Leif will be entering the JIRA and posting the bug id's back to the list so that anyone who is interested can follow along. Thanks for your input, Steve On 30/10/2012 6:41 AM, Pavel Safrata wrote: > 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 richard.bair at oracle.com Fri Nov 2 09:30:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 09:30:49 -0700 Subject: How to trigger property invalidation? In-Reply-To: <5093E5DB.2000503@media-interactive.de> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> <5093E5DB.2000503@media-interactive.de> Message-ID: <68AF14FB-8AA8-4CFF-AAB6-B9F264F0EE81@oracle.com> In Region we have a custom property that we can use to force invalidation. Is this sort of what you're looking for? private InsetsProperty insets = new InsetsProperty(); public final Insets getInsets() { return insets.get(); } public final ReadOnlyObjectProperty insetsProperty() { return insets; } private final class InsetsProperty extends ReadOnlyObjectProperty { private Insets cache = null; private ExpressionHelper helper = null; @Override public Object getBean() { return Region.this; } @Override public String getName() { return "insets"; } @Override public void addListener(InvalidationListener listener) { helper = ExpressionHelper.addListener(helper, this, listener); } @Override public void removeListener(InvalidationListener listener) { helper = ExpressionHelper.removeListener(helper, listener); } @Override public void addListener(ChangeListener listener) { helper = ExpressionHelper.addListener(helper, this, listener); } @Override public void removeListener(ChangeListener listener) { helper = ExpressionHelper.removeListener(helper, listener); } void fireValueChanged() { cache = null; requestLayout(); ExpressionHelper.fireValueChangedEvent(helper); } @Override public Insets get() { // If a shape is specified, then we don't really care whether there are any borders // specified, since borders of shapes do not contribute to the insets. if (_shape != null) return getPadding(); // If there is no border or the border has no insets itself, then the only thing // affecting the insets is the padding, so we can just return it directly. final Border b = getBorder(); if (b == null || Insets.EMPTY.equals(b.getInsets())) { return getPadding(); } // There is a border with some non-zero insets and we do not have a _shape, so we need // to take the border's insets into account if (cache == null) { // Combine the padding and the border insets. // TODO note that negative border insets were being ignored, but // I'm not sure that that made sense or was reasonable, so I have // changed it so that we just do simple math. // TODO Stroke borders should NOT contribute to the insets. Ensure via tests. final Insets borderInsets = b.getInsets(); final Insets paddingInsets = getPadding(); cache = new Insets( borderInsets.getTop() + paddingInsets.getTop(), borderInsets.getRight() + paddingInsets.getRight(), borderInsets.getBottom() + paddingInsets.getBottom(), borderInsets.getLeft() + paddingInsets.getLeft() ); } return cache; } }; From richard.bair at oracle.com Fri Nov 2 10:41:34 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 10:41:34 -0700 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <4FE2E232.8090405@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> Message-ID: <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> Looks OK to me. Lets not deprecated the protected constructors though, unless there is a good reason to (even if they are more or less useless). Richard On Jun 21, 2012, at 1:58 AM, Martin Sladecek wrote: > Hi, > here's my proposal for new constructors and methods for events in javafx.scene.input package (for 3.0) > > I changed all impl_*event factory methods to constructors and added a variant with (Object source, EventTarget target, ...), as Event, InputEvent, GestureEvent already had such constructors as part of public API. Usually, these constructors are used only when the target (or source) is known, so no copies must be made during the event dispatch process. > > Because Event has a "copyFor" method that returns a copy of the current object, changing some properties to the values passed in, I used the same pattern for all the impl_copy methods. I also added copyFor(Object source, EvenTarget target, EventType type) to events that have multiple types. > > Regarding the rest of @treatAsPrivate methods, I think all of them may be part of public API, as they don't expose any internal information or structures. > > I also made most of the classes final. > > ContextMenuEvent: > public ContextMenuEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean keyboardTrigger) > public ContextMenuEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean keyboardTrigger) > > DragEvent: > public DragEvent(Object source, EventTarget target, EventType eventType, Dragboard dragboard, double x, double y, double screenX, double screenY, TransferMode transferMode, Object gestureSource, Object gestureTarget) > public DragEvent(EventType eventType, Dragboard dragboard,double x, double y, double screenX, double screenY, TransferMode transferMode, Object gestureSource, Object gestureTarget) > public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, Dragboard dragboard) > public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, EventType eventType) > public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, TransferMode transferMode, EventType eventType) > public DragEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > public Object getAcceptingObject() // source that accepted the drag > > GestureEvent: (there were 2 protected constructors that were creating empty events, I'd like to make them deprecated) > protected GestureEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia) > protected GestureEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia) > > InputMethodEvent: > public InputMethodEvent(Object source, EventTarget target, EventType eventType, List composed, String committed, int caretPosition) > > InputMethodTextRun: > public InputMethodTextRun(String text, InputMethodHighlight highlight) > > KeyEvent: > public KeyEvent(Object source, EventTarget target, EventType eventType, String character, String text, int code, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown) > public KeyEvent(EventType eventType, String character, String text, int code, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown) > public KeyEvent(EventType eventType, String character, String text, KeyCode code, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown) > public KeyEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > > MouseEvent: > public MouseEvent(EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger) > public MouseEvent(EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, boolean stillSincePress) > public MouseEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, boolean stillSincePress) > public MouseEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > public boolean isPopupTrigger() //This was impl_ before, but it's used in some controls, so it might be useful > public static MouseDragEvent copyForMouseDragEvent(MouseEvent e, Object newSource, EventTarget newTarget, EventType type, Object gestureSource) // this will do a copy of mouse event, creating a mouseDragEvent from it. It's used internally and it's just a convenience, so can it doesn't have to be added at all to the public API > > MouseDragEvent: > public MouseDragEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, MouseButton button, int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, Object gestureSource) > public MouseDragEvent( EventType eventType, double x, double y, double screenX, double screenY, MouseButton button, int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, Object gestureSource) > RotateEvent: > public RotateEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double angle, double totalAngle) > public RotateEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double angle, double totalAngle) > public RotateEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > > ScrollEvent: > public ScrollEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double deltaX, double deltaY, double gestureDeltaX, double gestureDeltaY, HorizontalTextScrollUnits textDeltaXUnits, double textDeltaX, VerticalTextScrollUnits textDeltaYUnits, double textDeltaY, int touchCount) > public ScrollEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double deltaX, double deltaY, double gestureDeltaX, double gestureDeltaY, HorizontalTextScrollUnits textDeltaXUnits, double textDeltaX, VerticalTextScrollUnits textDeltaYUnits, double textDeltaY, int touchCount) > > public ScrollEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > > SwipeEvent: > public SwipeEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, int touchCount) > public SwipeEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, int touchCount) > > public SwipeEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > > ZoomEvent: > public ZoomEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double zoomFactor, double totalZoomFactor) > public ZoomEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double zoomFactor, double totalZoomFactor) > public ZoomEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > > TouchEvent: > public TouchEvent(Object source, EventTarget target, EventType eventType, TouchPoint touchPoint, List touchPoints, int eventSetId, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct) > public TouchEvent(EventType eventType, TouchPoint touchPoint, List touchPoints, int eventSetId, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct) > public TouchEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > public boolean isDirect() // was impl_ because (according to a comment in code) there are no indirect events yet, but GestureEvent already has this public. > javafx.stage.WindowEvent: > public WindowEvent copyFor(Object newSource, EventTarget newTarget, EventType type) > > > -Martin > > On 06/15/2012 11:44 PM, Richard Bair wrote: >> >>>> As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated). >>> And what do you think about impl_copy methods? Personally I think we should remove them completely and turn them to some internal utility methods. >> My initial thought was a copy constructor. >> >>> Also, some events are not 100% immutable, as they are modified during the Scene processing through some impl_methods, like MouseEvent.impl_setClickParam. We'd either need to make some/all of the Event fields protected and do this modifications through subclasses or create some "accessor" in javafx.scene.input package for calling these methods from javafx.scene package. >> Good question, I guess we can revisit these in context of the other impl_ method removal things we're working on. >> >> Richard > From richard.bair at oracle.com Fri Nov 2 10:49:21 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 10:49:21 -0700 Subject: API REVIEW: BaseObservableList In-Reply-To: <4FEC12E3.3020708@oracle.com> References: <4FEC12E3.3020708@oracle.com> Message-ID: <268F5B60-095B-43AF-AC27-CC47DEC73D9F@oracle.com> > Hello, > BaseObservableList was already discussed for 2.1, but we decided to defer it to some later release at the end. Full discussion here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000224.html. > > Based on the discussion, I reworked it into two new classes: BaseObservableList (for simple observable lists that are not necessarily modifiable) and it's subclass BaseModifiableObservableList. Our naming convention is FooBase rather than BaseFoo, so these should be ObservableListBase, ModifiableObservableListBase. > *public abstract class BaseObservableList extends AbstractList implements ObservableList:* > > First of all, it will implement following ObservableList methods: > > public final void addListener(InvalidationListener listener) > public final void removeListener(InvalidationListener listener) > public final void addListener(ListChangeListener listener) > public final void removeListener(ListChangeListener listener) > > ... and will contain these new methods: > > // calls all the listeners of this ObservableList > protected final void callListeners(ListChangeListener.Change change) I think we're using the term "fire" elsewhere rather than "call", so this should probably be "fire(ListChangeListener.Change change)" instead. > // true if there are some registered listeners > protected final boolean hasListeners() The name "hasListeners" is great, but a bummer it isn't recognized by JavaBeans as a getter. Then again, this isn't really a getter because we're not providing a ReadOnlyProperty (and this is a mutable state). So lets keep "has". > Following methods were part of IterableChangeBuilder in the original discussion. Now they will be part of BaseObservableList and can be used for creating a Change and firing it, so you don't need to create subclasses of ListChangeListener.Change yourself. > > protected final void nextUpdate(int pos) > protected final void nextSet(int idx, E old) > protected final void nextReplace(int from, int to, ArrayList removed) > protected final void nextRemove(int idx, List removed) > protected final void nextRemove(int idx, E removed) > protected final void nextPermutation(int from, int to, int[] perm) > protected final void nextAdd(int from, int to) > protected final void endChange() > protected final void beginChange() > > All next* methods need to be enclosed in beginChange() / endChange() pair. The calls can be also nested and after the outermost endChange() call, callListeners() will be called with the newly created Change. It seems odd that these are on the base class itself. I don't remember the previous conversation so maybe I said something different before :-). Steve, I'm wondering what you think on this point? > *public abstract class BaseModifiableObservableList extends BaseObservableList: > * > This class introduces three new abstract methods: > > protected abstract void doAdd(int index, E element); > protected abstract E doSet(int index, E element); > protected abstract E doRemove(int index); > > These methods are meant to contain simple list manipulations. The BaseModifiableObservableList implementation takes care of Change construction (using BaseObservableList methods), but subclasses can override this behavior. This part looks good. Richard From martin.sladecek at oracle.com Fri Nov 2 11:12:59 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Fri, 02 Nov 2012 19:12:59 +0100 Subject: How to trigger property invalidation? In-Reply-To: <5093E5DB.2000503@media-interactive.de> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> <5093E5DB.2000503@media-interactive.de> Message-ID: <50940D2B.1010808@oracle.com> Hi Werner, maybe an ObjectProperty isn't really what you are looking for. If you have single bean with an non-observable property (BTW, how do you know it has changed?) and you want to convert it to an FX property, why not using a property of the same type as MyBean.myProperty and set FX property when myProperty changes? -Martin On 11/02/2012 04:25 PM, Werner Lehmann wrote: > Pavel, > > unfortunately I cannot listen to changes on myProperty because it is > not an observable property: MyBean is a domain bean provided by the > server and those beans do not have observable properties. Thanks for > the clarification though. > > In my case this means that I have to clone the bean everytime when a > slider position changes so that I can replace the property value I am > actually observing (the MyBean property). Seems to be quick enough but > is hardly elegant... > > Werner > > On 02.11.2012 15:50, Pavel Safrata wrote: >> Hi Werner, >> I think that you cannot trigger invalidation manually by design. The >> property holds a reference and should not be concerned with changes of >> anything else than the reference. There would be various issues with it, >> for example there are change notifications bound to the invalidation, >> which would produce a weird notification of the property being changed >> to the same value. I think the right approach is to listen directly on >> the myProperty instead of tweaking the invalidation mechanism. >> >> With Regards, >> Pavel >> >> On 2.11.2012 12:55, Werner Lehmann wrote: >>> Hi, >>> >>> for an ObjectProperty, is it possible to trigger invalidation >>> manually when MyBean.myProperty changes? Basically I'd like to call >>> markInvalid() but it is private. And set() compares old and new value >>> by reference before invalidating, so won't see the change either. >>> >>> Workaround seems to be to copy the bean to another instance and assign >>> the new instance to the object property. >>> >>> Rgds >>> Werner From phidias51 at gmail.com Fri Nov 2 11:14:02 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 2 Nov 2012 11:14:02 -0700 Subject: Creating Clearer Method Names & Concepts Message-ID: I still find myself tripping over the names of methods or concepts in the JavaFX API -- where the API says "X", but only after you dig into the documentation do you discover that it really means Y. For example, property "Invalidation" doesn't really communicate what the code is actually doing. The property isn't invalid, it's value has never been validated (we don't yet have that concept in the API), so how can the property be "invalid"? All that's really indicated is that the property value has been changed -- although the subtle distinction between InvalidationListener and ChangeListener is lost on me and I always use a ChangeListener. At some point when we have a validation framework for JavaFX, how will the concomitant method calls that come with that framework, play out with the existing method calls. There will probably be a lot of head scratching going on. And there's the documentation for *Axis.toNumericValue*, and * Axis.toRealValue*: http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toNumericValue(T) http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toRealValue(double) Granted, "All axis values must be representable by some numeric value." But what I really want to know is are we translating from user space coordinates to data space coordinates? Or vice-versa? What is a "real value" and what is a "numeric value"? Aren't all values in an XY chart numbers? And why is that if I'm translating from user space to data space that I still need to take into account the width of the Y-Axis? Shouldn't I be able to get coordinates relative to the chart's content space? Cheers, Mark From tbee at tbee.org Fri Nov 2 11:20:16 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 02 Nov 2012 19:20:16 +0100 Subject: Creating Clearer Method Names & Concepts In-Reply-To: References: Message-ID: <50940EE0.2030307@tbee.org> Oh! Let me try to explain that (and see if I got it right). The bind is lazy, so when a property changes all bound properties are made invalid (this is when the Invalidation event is fired), but they are not recalculated. Only when the getter is executed, that property really is recalculated (with all kinds of performance cascading things going on) and then new value is known (this is when the Changed event is fired). Have I got it right? Tom On 2012-11-02 19:14, Mark Fortner wrote: > I still find myself tripping over the names of methods or concepts in the > JavaFX API -- where the API says "X", but only after you dig into the > documentation do you discover that it really means Y. > > For example, property "Invalidation" doesn't really communicate what the > code is actually doing. The property isn't invalid, it's value has never > been validated (we don't yet have that concept in the API), so how can the > property be "invalid"? All that's really indicated is that the property > value has been changed -- although the subtle distinction between > InvalidationListener and ChangeListener is lost on me and I always use a > ChangeListener. > > At some point when we have a validation framework for JavaFX, how will the > concomitant method calls that come with that framework, play out with the > existing method calls. There will probably be a lot of head scratching > going on. > > And there's the documentation for *Axis.toNumericValue*, and * > Axis.toRealValue*: > > http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toNumericValue(T) > > http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toRealValue(double) > > Granted, "All axis values must be representable by some numeric value." But > what I really want to know is are we translating from user space > coordinates to data space coordinates? Or vice-versa? What is a "real > value" and what is a "numeric value"? Aren't all values in an XY chart > numbers? > > And why is that if I'm translating from user space to data space that I > still need to take into account the width of the Y-Axis? Shouldn't I be > able to get coordinates relative to the chart's content space? > > > Cheers, > > Mark From richard.bair at oracle.com Fri Nov 2 11:28:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 11:28:29 -0700 Subject: Creating Clearer Method Names & Concepts In-Reply-To: <50940EE0.2030307@tbee.org> References: <50940EE0.2030307@tbee.org> Message-ID: That is correct. Essentially, the property is not invalid when it changes, only when it *might* have changed (since determining the value of the binding might require the resolution of some arbitrarily complicated graph of bindings, and would therefore be expensive to do eagerly). It means, that the value is unknown and requires recomputation. An InvalidationListener therefore is notified whenever a property becomes invalid, vs when we know the value has actually changed. I believe that when a ChangeListener is installed, we will figure out whether the thing has changed immediately (making it eager) and send notification. I tend to always use Invalidation listeners because the method signature is shorter ;-). Also, unless I explicitly read the value in the listener, I won't cause it to be recomputed (but if I do read it in the listener, then of course that is what I wanted to do, so no harm done). I can't vouch for the names on the Axis, I don't remember those. Richard On Nov 2, 2012, at 11:20 AM, Tom Eugelink wrote: > Oh! Let me try to explain that (and see if I got it right). > > The bind is lazy, so when a property changes all bound properties are made invalid (this is when the Invalidation event is fired), but they are not recalculated. Only when the getter is executed, that property really is recalculated (with all kinds of performance cascading things going on) and then new value is known (this is when the Changed event is fired). > > Have I got it right? > > Tom > > > > On 2012-11-02 19:14, Mark Fortner wrote: >> I still find myself tripping over the names of methods or concepts in the >> JavaFX API -- where the API says "X", but only after you dig into the >> documentation do you discover that it really means Y. >> >> For example, property "Invalidation" doesn't really communicate what the >> code is actually doing. The property isn't invalid, it's value has never >> been validated (we don't yet have that concept in the API), so how can the >> property be "invalid"? All that's really indicated is that the property >> value has been changed -- although the subtle distinction between >> InvalidationListener and ChangeListener is lost on me and I always use a >> ChangeListener. >> >> At some point when we have a validation framework for JavaFX, how will the >> concomitant method calls that come with that framework, play out with the >> existing method calls. There will probably be a lot of head scratching >> going on. >> >> And there's the documentation for *Axis.toNumericValue*, and * >> Axis.toRealValue*: >> >> http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toNumericValue(T) >> >> http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toRealValue(double) >> >> Granted, "All axis values must be representable by some numeric value." But >> what I really want to know is are we translating from user space >> coordinates to data space coordinates? Or vice-versa? What is a "real >> value" and what is a "numeric value"? Aren't all values in an XY chart >> numbers? >> >> And why is that if I'm translating from user space to data space that I >> still need to take into account the width of the Y-Axis? Shouldn't I be >> able to get coordinates relative to the chart's content space? >> >> >> Cheers, >> >> Mark > From phidias51 at gmail.com Fri Nov 2 11:38:10 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 2 Nov 2012 11:38:10 -0700 Subject: Creating Clearer Method Names & Concepts In-Reply-To: References: <50940EE0.2030307@tbee.org> Message-ID: And the second part of that first question is "how it will play with the validation framework"? If I'm creating a text field bound to a SimpleTextProperty and the user enters a semantically invalid value into the field (i.e. they stuck the contents of the great American novel into a 120 char field), what should I listen for? Am I going to have an "validation" property as well as a "invalidation" property? Perhaps EagerChangeListener and LazyChangeListener, or Optimistic/PessimisticChangeListener would be clearer? I know it's probably in people's noise level at this point, but the semantics behind the names of things often make all the difference when you're trying to figure things out. Mark Cheers, Mark On Fri, Nov 2, 2012 at 11:28 AM, Richard Bair wrote: > That is correct. Essentially, the property is not invalid when it changes, > only when it *might* have changed (since determining the value of the > binding might require the resolution of some arbitrarily complicated graph > of bindings, and would therefore be expensive to do eagerly). It means, > that the value is unknown and requires recomputation. > > An InvalidationListener therefore is notified whenever a property becomes > invalid, vs when we know the value has actually changed. > > I believe that when a ChangeListener is installed, we will figure out > whether the thing has changed immediately (making it eager) and send > notification. > > I tend to always use Invalidation listeners because the method signature > is shorter ;-). Also, unless I explicitly read the value in the listener, I > won't cause it to be recomputed (but if I do read it in the listener, then > of course that is what I wanted to do, so no harm done). > > I can't vouch for the names on the Axis, I don't remember those. > > Richard > > On Nov 2, 2012, at 11:20 AM, Tom Eugelink wrote: > > > Oh! Let me try to explain that (and see if I got it right). > > > > The bind is lazy, so when a property changes all bound properties are > made invalid (this is when the Invalidation event is fired), but they are > not recalculated. Only when the getter is executed, that property really is > recalculated (with all kinds of performance cascading things going on) and > then new value is known (this is when the Changed event is fired). > > > > Have I got it right? > > > > Tom > > > > > > > > On 2012-11-02 19:14, Mark Fortner wrote: > >> I still find myself tripping over the names of methods or concepts in > the > >> JavaFX API -- where the API says "X", but only after you dig into the > >> documentation do you discover that it really means Y. > >> > >> For example, property "Invalidation" doesn't really communicate what the > >> code is actually doing. The property isn't invalid, it's value has > never > >> been validated (we don't yet have that concept in the API), so how can > the > >> property be "invalid"? All that's really indicated is that the property > >> value has been changed -- although the subtle distinction between > >> InvalidationListener and ChangeListener is lost on me and I always use a > >> ChangeListener. > >> > >> At some point when we have a validation framework for JavaFX, how will > the > >> concomitant method calls that come with that framework, play out with > the > >> existing method calls. There will probably be a lot of head scratching > >> going on. > >> > >> And there's the documentation for *Axis.toNumericValue*, and * > >> Axis.toRealValue*: > >> > >> > http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toNumericValue(T) > >> > >> > http://docs.oracle.com/javafx/2/api/javafx/scene/chart/Axis.html#toRealValue(double) > >> > >> Granted, "All axis values must be representable by some numeric value." > But > >> what I really want to know is are we translating from user space > >> coordinates to data space coordinates? Or vice-versa? What is a "real > >> value" and what is a "numeric value"? Aren't all values in an XY chart > >> numbers? > >> > >> And why is that if I'm translating from user space to data space that I > >> still need to take into account the width of the Y-Axis? Shouldn't I be > >> able to get coordinates relative to the chart's content space? > >> > >> > >> Cheers, > >> > >> Mark > > > > From java.whoover at gmail.com Fri Nov 2 11:46:39 2012 From: java.whoover at gmail.com (Will Hoover) Date: Fri, 2 Nov 2012 14:46:39 -0400 Subject: How to trigger property invalidation? In-Reply-To: <50940D2B.1010808@oracle.com> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> <5093E5DB.2000503@media-interactive.de> <50940D2B.1010808@oracle.com> Message-ID: <5094153a.444cec0a.54c5.ffff89be@mx.google.com> ...or you could use a BeanPathAdapter that handles all your POJO field to JFX property conversions for you (http://wp.me/P2rLDc-1s) and listen for changes to the bean: BeanPathAdapter myPojoAdapter = new BeanPathAdapter<>(myPojo); TextField tf = new TextField(); myPojoAdapter.bindBidirectional("myPojoField.anotherField.destinationField", tf.valueProperty()); myPojoAdapter.fieldPathValueProperty().addListener( new ChangeListener() { @Override public void changed( final ObservableValue observable, final FieldPathValue oldValue, final FieldPathValue newValue) { System.out.println("Value changed from path: " + oldValue.getPath() + " value: " + oldValue.getValue() + " to path: " + newValue.getPath() + " value: " + newValue.getValue()); } }); ... another shameless plug ;) -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Martin Sladecek Sent: Friday, November 02, 2012 2:13 PM To: openjfx-dev at openjdk.java.net Subject: Re: How to trigger property invalidation? Hi Werner, maybe an ObjectProperty isn't really what you are looking for. If you have single bean with an non-observable property (BTW, how do you know it has changed?) and you want to convert it to an FX property, why not using a property of the same type as MyBean.myProperty and set FX property when myProperty changes? -Martin On 11/02/2012 04:25 PM, Werner Lehmann wrote: > Pavel, > > unfortunately I cannot listen to changes on myProperty because it is > not an observable property: MyBean is a domain bean provided by the > server and those beans do not have observable properties. Thanks for > the clarification though. > > In my case this means that I have to clone the bean everytime when a > slider position changes so that I can replace the property value I am > actually observing (the MyBean property). Seems to be quick enough but > is hardly elegant... > > Werner > > On 02.11.2012 15:50, Pavel Safrata wrote: >> Hi Werner, >> I think that you cannot trigger invalidation manually by design. The >> property holds a reference and should not be concerned with changes >> of anything else than the reference. There would be various issues >> with it, for example there are change notifications bound to the >> invalidation, which would produce a weird notification of the >> property being changed to the same value. I think the right approach >> is to listen directly on the myProperty instead of tweaking the invalidation mechanism. >> >> With Regards, >> Pavel >> >> On 2.11.2012 12:55, Werner Lehmann wrote: >>> Hi, >>> >>> for an ObjectProperty, is it possible to trigger >>> invalidation manually when MyBean.myProperty changes? Basically I'd >>> like to call >>> markInvalid() but it is private. And set() compares old and new >>> value by reference before invalidating, so won't see the change either. >>> >>> Workaround seems to be to copy the bean to another instance and >>> assign the new instance to the object property. >>> >>> Rgds >>> Werner From richard.bair at oracle.com Fri Nov 2 13:24:25 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:24:25 -0700 Subject: Creating Clearer Method Names & Concepts In-Reply-To: References: <50940EE0.2030307@tbee.org> Message-ID: > I know it's probably in people's noise level at this point, but the > semantics behind the names of things often make all the difference when > you're trying to figure things out. I agree, names actually are one of the hardest aspects of API design, particularly because so many names are reused in computer science (like binding!) for so many different things. I do not anticipate that when we do validation that the bindings themselves will expose this new validation concept (I imagine the Controls themselves will do so), but who knows. From richard.bair at oracle.com Fri Nov 2 13:36:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:36:39 -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: > 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. Actually we use a lot of agile principles in our sprint planning and such. We have been looking at the whole range of Atlassian products for a (long) while including Greenhopper. For now though we've used Confluence for most of our planning. We're actively rewriting our processes to use the wikis on https://wikis.oracle.com/display/OpenJDK/OpenJFX instead, so that this information is available. Often the sprint plans are viewable directly in JIRA (although it is custom per team). When we've gotten past the security / open source tasks, getting the process / etc all nailed down will be the top priority. Just by means of time frame, my expectation is that sometime in February next year we'll be fully complete with the open source process, including creating necessary mailing lists, consolidating information on the wiki, updating all the project pages, getting the repos properly hosted etc. By then we'd better be done, because we'll be neck deep in bug fixes for the 8 release. > 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. Our view is that we need to get all the tests into the hands of all developers (both inside & outside Oracle), and all information to all users (both inside and outside Oracle). There are of course some things that won't be opened up (specific tests cases sent confidentially from companies, security issues, etc) but 98% or so of the entire project & process can and will be opened up. Cheers Richard From richard.bair at oracle.com Fri Nov 2 13:48:20 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:48:20 -0700 Subject: TextField Document model In-Reply-To: <527B2117-D44E-4770-99BF-332CDF8E07C1@gmail.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> <527B2117-D44E-4770-99B! F-332CDF8E07C1@gmail.com> Message-ID: <20BB8CD3-C4DC-4D27-8E12-10A4BF0E7B74@oracle.com> > 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. To my knowledge it won't work with Lambda (to have an interface built out of two one-method interfaces). >> 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. That is a great use case. Richard From richard.bair at oracle.com Fri Nov 2 13:48:53 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:48:53 -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> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> Message-ID: <04EB5ABB-FE24-4DF8-B2B9-6DB9024F52C3@oracle.com> Hi Mark, I'm wondering if you had a chance to try this out? Cheers Richard On Oct 26, 2012, at 10:28 PM, Mark Claassen wrote: > 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 Fri Nov 2 13:50:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:50:49 -0700 Subject: Memory Leaks In-Reply-To: References: <50831490.2030007@oracle.com> <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> <50858479.3010600@oracle.com> Message-ID: <5077CB6B-AFDA-418E-A896-DFE43667F0EB@oracle.com> Thanks for the link, I didn't know about this feature (passing it on). Unless we make our version numbers more verbose (including build numbers), it won't help to accumulate what fixes went into a specific build (as I understand it), but at least for major releases we could have a comprehensive report. Richard On Oct 22, 2012, at 2:54 PM, Daniel Zwolenski wrote: > 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 richard.bair at oracle.com Fri Nov 2 13:52:37 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:52:37 -0700 Subject: API Review: Use ObservableNumberValue as parameter for valueAt() methods In-Reply-To: <407D5289-53F2-43F0-90D2-24D6BD34647F@oracle.com> References: <407D5289-53F2-43F0-90D2-24D6BD34647F@oracle.com> Message-ID: The existing methods would continue to function though, is that right? They wouldn't need to be deprecated from a functional perspective (i.e.: they aren't totally broken), but they're just extra noise in the API? Richard On Sep 18, 2012, at 12:19 AM, Michael Heinrichs wrote: > Hi, > > currently the various valueAt() methods expect an ObservableIntegerValue for the index. (The valueAt() methods create a binding to request a specific element in an ObservableList.) This is wrong, the type should have been an ObservableNumberValue, because this fits to the general philosophy of the binding API. (In general the binding API tries to loosen the type system as much as possible without dropping the ability to use primitives internally.) > > I want to add new versions of the various valueAt() methods that expect ObservableNumberValue for the index. The current methods will be marked as deprecated and should be removed in a future incompatible update of the JavaFX API. > > Thanks, > Michael From richard.bair at oracle.com Fri Nov 2 13:54:12 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 13:54:12 -0700 Subject: API review: Conversion methods in Binding API In-Reply-To: <2979DA98-06DD-40C0-9685-57794B055883@oracle.com> References: <2979DA98-06DD-40C0-9685-57794B055883@oracle.com> Message-ID: <0BFCF167-7860-4F41-BC50-EA913883496D@oracle.com> I haven't seen this as a request by developers yet, I tend to think we ought to keep this feature / tweak in our backlog and revisit if / when we see some demand from users? Richard On Sep 18, 2012, at 12:00 AM, Michael Heinrichs wrote: > Hi, > > there are sometimes situations, when a developer has a general typed value, but needs a specific type, e.g. a user may have an ObjectProperty but needs an ObservableIntegerValue. I want to add some conversion methods for these kind of cases. http://javafx-jira.kenai.com/browse/RT-19020 > > class BooleanExpression: > public static BooleanExpression booleanExpression(ObservableValue) > The current booleanExpression() method will be marked as deprecated and should be removed when we do an incompatible update of the JavaFX API. Same for the methods in DoubleExpression etc. > > class DoubleExpression: > public static DoubleExpression doubleExpression(ObservableValue) > > class FloatExpression: > public static FloatExpression floatExpression(ObservableValue) > > class IntegerExpression: > public static IntegerExpression integerExpression(ObservableValue) > > class LongExpression: > public static LongExpression longExpression(ObservableValue) > > class ObjectExpression: > public BooleanBinding asBoolean() > public DoubleBinding asDouble() > public FloatBinding asFloat() > public IntegerBinding asInteger() > public LongBinding asLong() > The bindings returned by these methods will return the default value, if the type of the wrapped Object does not match the expected. > > class Bindings: > public static BooleanExpression convertToBoolean(ObservableValue) > public static DoubleExpression convertToDouble(ObservableValue) > public static FloatExpression convertToFloat(ObservableValue) > public static IntegerExpression convertToInteger(ObservableValue) > public static LongExpression convertToLong(ObservableValue) > > Thanks, > Michael From knut.arne.vedaa at broadpark.no Fri Nov 2 14:09:23 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Fri, 02 Nov 2012 22:09:23 +0100 Subject: Creating Clearer Method Names & Concepts In-Reply-To: References: <50940EE0.2030307@tbee.org> Message-ID: <50943683.2050402@broadpark.no> Binding in JavaFX is certainly another source of confusion. You have "binding" and you have "Binding": A Property has a method "bind", of which the doc says: "Create a unidirection binding for this Property." While there is also the interface Binding, of which the doc says: "A Binding calculates a value that depends on one or more sources." The fact that these concepts are related, but not the same, but still share the same name, makes it more difficult for newcomers to get a grasp of the concepts in the API. At least so it was for me. Probably too late to change, though. But perhaps documentation could be more clear about it. In general, I think naming is a compromise between succintness and uniqueness. In order to guarantee uniqueness you would need to use long descriptive names (which probably are seen often enough in Java frameworks as it is). Shorter ones look better, but clash more easily. Sometimes it might even be better to use names that are not perhaps 100% logical when seen in isolation. Knut Arne Vedaa On 02.11.2012 21:24, Richard Bair wrote: >> I know it's probably in people's noise level at this point, but the >> semantics behind the names of things often make all the difference when >> you're trying to figure things out. > > I agree, names actually are one of the hardest aspects of API design, particularly because so many names are reused in computer science (like binding!) for so many different things. I do not anticipate that when we do validation that the bindings themselves will expose this new validation concept (I imagine the Controls themselves will do so), but who knows. > From richard.bair at oracle.com Fri Nov 2 14:24:41 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 14:24:41 -0700 Subject: Creating Clearer Method Names & Concepts In-Reply-To: <50943683.2050402@broadpark.no> References: <50940EE0.2030307@tbee.org> <50943683.2050402@broadpark.no> Message-ID: <347CDA2F-4B96-4AF5-9739-ED9D06D312A0@oracle.com> > Binding in JavaFX is certainly another source of confusion. You have "binding" and you have "Binding": > > A Property has a method "bind", of which the doc says: "Create a unidirection binding for this Property." > > While there is also the interface Binding, of which the doc says: "A Binding calculates a value that depends on one or more sources." I guess I didn't see these as different, as the "bind" method uses a Binding (or just listens to it if it is of the right type): public void bind(final ObservableValue rawObservable) { if (rawObservable == null) { throw new NullPointerException("Cannot bind to null"); } ObservableIntegerValue newObservable; if (rawObservable instanceof ObservableIntegerValue) { newObservable = (ObservableIntegerValue)rawObservable; } else if (rawObservable instanceof ObservableNumberValue) { final ObservableNumberValue numberValue = (ObservableNumberValue)rawObservable; newObservable = new IntegerBinding() { { super.bind(rawObservable); } @Override protected int computeValue() { return numberValue.intValue(); } }; } else { newObservable = new IntegerBinding() { { super.bind(rawObservable); } @Override protected int computeValue() { final Number value = rawObservable.getValue(); return (value == null)? 0 : value.intValue(); } }; } if (!newObservable.equals(observable)) { unbind(); observable = newObservable; if (listener == null) { listener = new Listener(); } observable.addListener(listener); markInvalid(); } } So the "bind" method is just shorthand, really, for using Bindings on that property. From knut.arne.vedaa at broadpark.no Fri Nov 2 15:46:47 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Fri, 02 Nov 2012 23:46:47 +0100 Subject: Creating Clearer Method Names & Concepts In-Reply-To: <347CDA2F-4B96-4AF5-9739-ED9D06D312A0@oracle.com> References: <50940EE0.2030307@tbee.org> <50943683.2050402@broadpark.no> <347CDA2F-4B96-4AF5-9739-ED9D06D312A0@oracle.com> Message-ID: <50944D57.40808@broadpark.no> On 02.11.2012 22:24, Richard Bair wrote:>> Binding in JavaFX is certainly another source of confusion. You have "binding" and you have "Binding": >> >> A Property has a method "bind", of which the doc says: "Create a unidirection binding for this Property." >> >> While there is also the interface Binding, of which the doc says: "A Binding calculates a value that depends on one or more sources." > > I guess I didn't see these as different, as the "bind" method uses a Binding (or just listens to it if it is of the right type): > > public void bind(final ObservableValue rawObservable) { > if (rawObservable == null) { > throw new NullPointerException("Cannot bind to null"); > } [more code] > So the "bind" method is just shorthand, really, for using Bindings on that property. Interesting. This is not what the API user sees, though. I'm still unclear about the semantics of it. What is a "binding" (in this context)? Knut Arne From knut.arne.vedaa at broadpark.no Fri Nov 2 15:50:32 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Fri, 02 Nov 2012 23:50:32 +0100 Subject: Creating Clearer Method Names & Concepts In-Reply-To: References: <50940EE0.2030307@tbee.org> <50943683.2050402@broadpark.no> Message-ID: <50944E38.5090208@broadpark.no> On 02.11.2012 22:23, Mark Fortner wrote: > The other thing to keep in mind is that the semantics introduced in JSE > shouldn't also clash with those in JEE. For example, there's a > Validation framework already in place there (not sure why it wasn't > picked up on the client side, but that's another story). If they decide > to rework that framework for client-side use, then "valid" must mean the > same thing on both client and server. All meaning is context-dependent (at least according to postmodernism). "Valid" can have different meanings in different contexts. So it might not necessarily be a problem if the contexts are unrelated. But I agree in general, of course. Knut Arne From richard.bair at oracle.com Fri Nov 2 16:01:46 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 16:01:46 -0700 (PDT) Subject: Creating Clearer Method Names & Concepts In-Reply-To: <50944E38.5090208@broadpark.no> References: <50940EE0.2030307@tbee.org> <50943683.2050402@broadpark.no> <50944E38.5090208@broadpark.no> Message-ID: <37E9D885-813F-4CD7-9DCE-ED6AFDDA2DC6@oracle.com> >> The other thing to keep in mind is that the semantics introduced in JSE >> shouldn't also clash with those in JEE. For example, there's a >> Validation framework already in place there (not sure why it wasn't >> picked up on the client side, but that's another story). If they decide >> to rework that framework for client-side use, then "valid" must mean the >> same thing on both client and server. The main issue is one of dependency & JSR-ness. If the Validation API was part of JavaSE, it would have been a no-brainer. But with JavaFX going into JavaSE, and Validation being only in JavaEE, we have a problem. Which is, actually, one reason we haven't put in a validation framework yet at all in JavaFX, so we don't reinvent the wheel nor create an untenable dependency from SE to EE. Richard From zonski at gmail.com Fri Nov 2 16:18:21 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 3 Nov 2012 10:18:21 +1100 Subject: JFX build and deployment - squeaking wheel Message-ID: Currently there is no good way to build and distribute a JavaFX application. The options we have either don't work at all, or have such a poor user and developer experience as to be as good as broken. This has been the single point of frustration for me and also the primary reason my only commercial client using JFX is considering moving off it. For me there is no other bug or problem in the list that even registers on the scale compared to this one. It is a show-stopper: Failure to Launch. JIRA should have one bug: "User can't run JavaFX". Everything else could be deleted. There is no point in having 3D, Media, Charts, CSS, Animations or really even a TextBox if we can't actually get the thing to run on the users' machines. At the same time there seems to be zero interest or movement in this area. I am left to assume that either: a) I have it wrong, and others are building and deploying just fine - please tell me how you do it! b) No one is really deploying happily and the JFX team just aren't aware how crippling this problem is I've raised this many times before, but given the squeaky wheel policy for feature prioritisation, I'm going to sum it all up again. As with all of my squeaking, it comes with suggestions for you to take or refute as you like. I think I pretty much have to address this to Richard, because no one else seems in a position to do anything about this. Richard, if you don't want to read all of the below, what I'd really like to know is: *what is the roadmap for JavaFX deployment options?* Do you plan to extend or fix any of the current JFX deployment options (JAR, Applet, JNLP, Native) and if so how and when? If there's no plans, well that would be just as useful to know. I know there's a focus on open sourcing right now and I can see how that is a super high priority for you. Where does deployment rank on the priorities list though? JARs and Executable JARs Why they are unusable: - Require a JVM installation which is currently a horrible, scary user experience and a big turn off - Local classpath, JRE version matching issues, etc - JFX Runtime is not on the JRE path so this needs to be co-bundled but then DLL loading and JRE version matching gets weird quickly - No way to auto-update the app - need to send out a JAR to manually replace the app If the JFX runtime boot classpath issue was fixed then this becomes a legitimate deployment option but only for situations where you have control over the users environment (e.g. an office where you can control the images installed on people's machines). It's not ever going to be a good way to mass distribute an application to the general public or even within a standard business environment where the OS platform is not controlled. Applets Why they are unusable: - Require a JVM installation which is currently a horrible, scary user experience and a big turn off - Problems with the plugin detecting versions of Java installed and actually running (i.e. it doesn't work most of the time) - All sorts of security problems and issues, now and forever more - Don't really integrate well with the browser or the page-based browser model so not overly useful - Offline usage not well supported - Requires constant upgrading to latest version of JRE/JFX which is not safely backwards compatible - app could break with each new release I don't think Applets are worth fixing in their current form so one option is to ditch them entirely. This would free up some deployment resources to work on other options and remove some nasty requirements (like forced auto-updating of the JRE for security reasons). An interesting alternative to applets is to port the JRE to run on top of JavaScript and make this available as a plugin for all the major browsers. This would allow "Java in the Browser", which is basically what Applets are trying to do. This idea was floated by Richard a while back (i.e. I'm not taking credit for it). Since it's all running in the browser's sand-box it would only require the installation of the plugin, not a native JRE like we have now, potentially removing all the security problems we have with the current approach. In a perfect world JFX would run in this JScript JRE but I'd actually settle for just being able to mess with the DOM via Java. i.e. JFX would be a (huge) bonus but the JScript VM on it's own, with access to the DOM, would be a pretty huge win. There are a lot of big challenges to making this work though. Cross-browser support for this could be very tricky. The plugin would need to be a simple one-click install, etc. My gut feel is that fixing the native installers would be a quicker, easier win and something like this would be interesting to look at down the road. If it could work though it would be a huge boon to Java in the Client. JNLP Why it is unusable: - Requires a JVM installation which is currently a horrible, scary user experience and a big turn off - Problems with the plugin detecting versions of Java installed and actually running (i.e. it doesn't work most of the time) - All sorts of security problems and issues, now and forever more - Requires (I think) constant upgrading to latest version of JRE/JFX which is not safely backwards compatible - app could break with each new release I really love JNLP as an ideal but it just doesn't work. Conceptually it is flawed (because you have to do a horrible Java install in order make your installations easier, all wrong) but at the moment it is also functionally broken. I have tried with several different machines to load JNLP files and every one of them has failed in a unique and special way. The main problem seems to be JRE detection and version management, plus making the user actually install the JRE is horrible. Again one option is to ditch them freeing up resources. Since the flaws all revolve around Java version management, another option might be to provide an alternative to this. Instead of making the user download and install the JRE, provide a native app that acts as the Java launcher but which internally manages all the JREs. When this app reads a JNLP file it then downloads and unzips (i.e. not installs) the appropriate JRE into it's own local directory. It can then manage multiple JREs and share these between apps, etc, Writing this would be easy, but the JRE would need be made available as a zip (legally only Oracle would be allowed to do this). It would be a kind of "Java App Manager". It could be extended to be a Java App store if you really wanted to, where the actual app manager could browse a repository of apps and download and launch them as required, etc. The big problem with this is of course getting the App Manager onto the desktop in the first place. A plugin might be able to install it but this might well just open up more problems. If the actual installer for the App Manager was extremely simple (as simple as installing Chrome for example - there's your bench mark) then perhaps it would be ok to make users do this. If it has legs as an idea then this area would need further expanding and thinking. Native installers with Co-Bundled JREs Why they are unusable: - Current build tools are hard to use and understand - mysterious configuration options, all melded in with jnlp/applet build, all ant based - Huge distribution bundle sizes due to co-bundled JRE app size - Need to install third party native packagers that then get magically picked up from the environment, no way to configure this - Need to run a separate build on each target platform to produce the native installer for that platform (not very "Java") - No way to auto update apps once installed - No way to easily distribute the appropriate native to the client (i.e. the user has to know what OS and architecture they are on and choose the corresponding native file) - Limited configuration options currently, the installer itself can not be overly/easily customised to make a nicer, custom tailored installation experience for an application. This is the option with the most potential. It removes the major security hassles with Applet and JNLP (each app is now responsible for ensuring it's own security and updating if needed), which in turn removes the need to force JRE automatic updates. The installation experience is not too bad (still worse than a webapp but a lot cleaner than all the options above). It also is the only option to potentially work on mobile platforms, and as OS's are starting to lock down things to app-stores this is the option most likely to survive when that trend becomes rule (i.e. a system-wide JRE and hence JNLP, Applets and JARs are all on the cards to be blocked on Mac and Windows before too long). In it's current form however native bundling of JFX apps is not much above an interesting proof of concept and is not usable in a practical way, except in very limited situations. There also doesn't seem to be much if any developments in this area - nothing is visibly moving forward on it. The first problem is the size of the distributables due to the technical and legal barriers to cutting out the fat from the JRE. Project Jigsaw was promised to fix this but it got bumped to way too far down the track. Last word from Richard was there was still plans to make the JRE trimmable in Java 8 but we've got no idea what this actually means or any solid guarantees this will happen. It sucks that we have to wait for J8 for this, but will suck even more if J8 rolls around and it's still not possible. The next major hurdle are the build tools. These are currently horrible to work with, taking us back to the days of 'make' files. Having to download and install an extra native packager is nasty (JFX is suppose to be the packager). Having to run the build on each platform you want to distribute on is even worse. We need build tools that are clean and simple, that have the native bundlers already in them (whether that means co-bundling the existing third-party tool, or writing your own native bundlers). We need to be able to build for all platforms from the one platform (i.e. if I run the build on my 64 bit windows machine I should be able to produce a 32-bit, 64-bit MSIs, DMG's, DEBs, and one day APKs and iPhone apps). I'm well aware that there are massive technical (and potentially legal) issues to this but I don't believe they are insurmountable. And of course, we need auto-updating. As I demonstrated with some POC code, this is not particularly difficult, however the current native packaging from JFX do not provide enough features to do this properly. Native installers look like our best bet but there is a lot of work to be done in this area and from an outsiders view at least there seems to be zero attention or interest in this. If you're going to say "yes, great, why don't you contribute to the above", I'll highlight that all of the above needs to be integrated with the JFX deployment tools and some of it has legal issues, so even if I wanted to spend the hours doing this, it won't be usable. I did try to assist on this with AU code and that contribution was largely ignored. The community can assist you to do this, but we cannot do this ourselves. Unless that is, we totally ignore the existence of your tools and write our own from scratch, in which case we could solve a lot of the above issues. That's a hell of a lot of work and re-inventing the wheel though - I'd at least want to see a roadmap on the deployment strategies planned from JFX, otherwise we could be double-handling and anything the community does could be superseded by JFX stuff that we didn't even know was planned or in progress. From richard.bair at oracle.com Fri Nov 2 16:40:08 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Nov 2012 16:40:08 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: Message-ID: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> > a) I have it wrong, and others are building and deploying just fine - > please tell me how you do it! I think there is truth to this -- many of the customers I've been working with have not had a problem with deployment. There are different reasons for this -- one is that there are other commercial tools for creating pre-packaged co-bundled Java applications (this isn't a new technology we invented, it has been happening in the Java desktop world for a decade. We're just trying to make it the preferred approach and build it into our own tooling). Another reason could be that many of the other folks have much tighter control on their deployment scenario. > b) No one is really deploying happily and the JFX team just aren't aware > how crippling this problem is And there are people in this bucket too. We have customers all across the spectrum, and just about every missing feature (in Media, Accessibility, i18n, etc) are also critical P0's for those who encounter them and need the missing functionality. > JARs and Executable JARs > > Why they are unusable: > > - Require a JVM installation which is currently a horrible, scary user > experience and a big turn off > - Local classpath, JRE version matching issues, etc > - JFX Runtime is not on the JRE path so this needs to be co-bundled but > then DLL loading and JRE version matching gets weird quickly > - No way to auto-update the app - need to send out a JAR to manually > replace the app You also need to add that some systems are configured to treat jar files as zip files, and thus double clicking doesn't work. > Applets > JNLP > Again one option is to ditch them freeing up resources. This will free up resources in 8-15 years. We have support contracts and people who pay money for this stuff, and many year support plans. Just to put this in perspective, there are no easy answers here. > Native installers with Co-Bundled JREs > > Why they are unusable: > > - Current build tools are hard to use and understand - mysterious > configuration options, all melded in with jnlp/applet build, all ant based > - Huge distribution bundle sizes due to co-bundled JRE app size > - Need to install third party native packagers that then get magically > picked up from the environment, no way to configure this > - Need to run a separate build on each target platform to produce the > native installer for that platform (not very "Java") > - No way to auto update apps once installed > - No way to easily distribute the appropriate native to the client (i.e. > the user has to know what OS and architecture they are on and choose the > corresponding native file) > - Limited configuration options currently, the installer itself can not > be overly/easily customised to make a nicer, custom tailored installation > experience for an application. As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable. We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to. Richard From zonski at gmail.com Fri Nov 2 17:07:01 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 3 Nov 2012 11:07:01 +1100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> Message-ID: <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> > As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable. We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to. I am definitely watching for the open sourcing of that to happen. I'm hoping all the code around the native packager, the native launcher code for each platform and everything to do with native building will be part of that open sourced code. I'm hoping there will be no technical or legal barriers to us using that code within our own build tools and completely avoid the bundled jre build tools (so we don't have to wait months/years for our fixes to be officially included before our tools can be used). Is it all community work then or are there plans for any work to be done in this area from the official jfx team - and if so what/when? I don't want to double up on any work (as happened with the native launcher work - Igor and I wrote the same code because I didn't know he was working on it). Is the jre trimming option (ie project jigsaw precursor) still planned for java 8 and can you give us any indication on what this will look like and how it will work? Will the legals be solved as well as the technical issues? What contributions do you want as a number 1 priority. I tried to start AU because it was the only thing on this topic I've seen interest in from jfx and so I assumed it was something more likely to get picked up but Igor seemed to lose interest. If you had to pick one thing in this area to get done what would it be and if it was done when would be the earliest it would get included in a jfx release? From pedro.duquevieira at gmail.com Fri Nov 2 19:14:34 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 3 Nov 2012 02:14:34 +0000 Subject: JFX build and deployment - squeaking wheel Message-ID: As for the applets and the jnlp part (specially applets) I already brought up this subject more than once but either didn't got a response, or got just some general pointers but no concrete plans for release. I think as for offline desktop deployment things are currently handled well. On the other hand applets are seriously crippled. I personally think that this is a really good area where Java could excel and consequently draw in a big percentage of developers. Flash is dying and developers are getting aware that HTML5 isn't what it was promised to be, so there is really no good technology for creating feature rich web apps. Sure you can use HTML5 to create nice looking document based web apps but not more than that, at least not currently. I just wish I could deploy my apps with this beautifully crafted JavaFX controls through the web seamlessly and painlessly (just like flash does it) :-) Thanks, best regards, -- Pedro Duque Vieira From randahl at rockit.dk Fri Nov 2 20:08:57 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 3 Nov 2012 04:08:57 +0100 Subject: Can ESC to exit full screen be avoided? Message-ID: When I run my application in full screen (on a mac) I am using the escape key for a feature in my application. However if I hit escape, JavaFX (or perhaps Mac OS X) sends my app out of full screen mode. Can this be avoided? I have tried invoking event.consume() on the ESC key event, but that does not prevent the exit from full screen. Thanks Randahl From swpalmer at gmail.com Fri Nov 2 20:18:22 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 2 Nov 2012 23:18:22 -0400 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> Message-ID: On 2012-11-02, at 7:40 PM, Richard Bair wrote: >> a) I have it wrong, and others are building and deploying just fine - >> please tell me how you do it! > > I think there is truth to this -- many of the customers I've been working with have not had a problem with deployment. There are different reasons for this -- one is that there are other commercial tools for creating pre-packaged co-bundled Java applications (this isn't a new technology we invented, it has been happening in the Java desktop world for a decade. We're just trying to make it the preferred approach and build it into our own tooling). Another reason could be that many of the other folks have much tighter control on their deployment scenario. We are in this group. Granted the javafxpackager, while a cool idea, was useless to us. We bundled JavaFX with our app using custom hacks for a while. Now we require 7u7 where it is included, and still need hacks to get it on the classpath. But it means our distribution is a simple Zip file. Extract and double click on our launch script and it works. We have another product that installs our app with a bundled JRE using a standard Windows .msi installer. Deployment is nowhere near a show stopper for us, but there are many issues that have been and a few that are restricting what we want to deliver. >> b) No one is really deploying happily and the JFX team just aren't aware >> how crippling this problem is > > And there are people in this bucket too. > > We have customers all across the spectrum, and just about every missing feature (in Media, Accessibility, i18n, etc) are also critical P0's for those who encounter them and need the missing functionality. > >> JARs and Executable JARs >> >> Why they are unusable: No need to go through the list. This isn't a JavaFX issue. They have always been unusable for anyone but Java developers... But of course no sane developer would even consider a that as a distribution method for general non-techie users. Windows *requires* an installer. Mac *requires* an Application Bundle. (Linux, well it isn't for non-techie users anyway, but you would typically make a RPM or DEB package... Of course any typical user would be clueless about such things if they tried Linux - you would have to get your app in the Linux distros cental repository so the package manager handled everything for you.) >> Applets >> JNLP > >> Again one option is to ditch them freeing up resources. > > This will free up resources in 8-15 years. We have support contracts and people who pay money for this stuff, and many year support plans. Just to put this in perspective, there are no easy answers here. These could work.. JNLP is still far too difficult and unreliable... But the idea isn't entirely bad. Applets mostly work, but have enough glitches that it is still better to try to get JNLP working. Applets lacked attention from Sun back when it counted. If they got more polish the, Flash wouldn't exist today. >> Native installers with Co-Bundled JREs >> >> Why they are unusable: I disagree that they are unusable, in fact I think they are the best option, but they require a lot of platform specific knowledge and non-java tools. I do agree with some of you're arguments against them though. >> >> - Current build tools are hard to use and understand - mysterious >> configuration options, all melded in with jnlp/applet build, all ant based Yes. This is partly the initial blunder of javafxpackager. That is a tool that was over engineered for the first release. It should have taken a single parameter - your executable Jar file, and produced a platform specific installer with optional embedded JRE. Optionally, JVM parameters and app parameters could be specified - exactly as they would be when invoking command-line 'java' No other inputs should be required because they can all be inferred from the Jar. E.g. If you can double-click to run it then you can find the JRE to bundle for a stand-alone app and all the dependencies from the manifest classpath. Applet and JNLP could be generated as well, though they may need a couple more parameters, width x height that sort of thing. Nearly Everything in the JNLP could be generated automatically from the Jar and JVM params. The blunder was disrupting the development workflow with a tool that required Ant and tried to take over established practices. Like creating a jar and signing it. We had that part figured out already. >> - Huge distribution bundle sizes due to co-bundled JRE app size That has been a non-issue for many years for most desktop users. A couple minutes of download time at most and the end users will do it. >> - Need to install third party native packagers that then get magically >> picked up from the environment, no way to configure this Yep that is awkward. Anyone want to rewrite WiX in pure Java + JNA? >> - Need to run a separate build on each target platform to produce the >> native installer for that platform (not very "Java") A non-issue, since you have to test on those platforms anyway and therefore have them available. >> - No way to auto update apps once installed No Oracle-provided way. You could roll your own over a weekend, or use existing frameworks (some platform specific) >> - No way to easily distribute the appropriate native to the client (i.e. >> the user has to know what OS and architecture they are on and choose the >> corresponding native file) Not true. Most web sites grab that from the browser's user-agent info. And many users know enough anyway - they just have to know to click on the Apple, the penguin, or the Windows icon. >> - Limited configuration options currently, the installer itself can not >> be overly/easily customised to make a nicer, custom tailored installation >> experience for an application. It is more extensible than I first thought, but yes it still sucks in that you still have to do separate installers using distinctly different tools. > As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable. Application Bundles for Mac should be easy to make from any platform, if the launcher stub binary is part of the cross-platform javafxpackager. It's the .dmg that is tricker, but zips of app bundles work well too.. I'm guessing Linux packages could be done in a pure Java way if someone had the time to write the tool to create the RPM or DEB from pure Java (maybe it's easy?). At least the C source would be available for reference - and contamination via GPL :(. Windows .msi files would be hardest to deal with I think because I know of no way to make them without Windows. If you are going to bundle an embedded JRE you will at least need to download the JRE for each platform. Are there copies of all of the platform-specific JREs that aren't exe's or msi's or dmgs or rpms so they can be extracted and embedded by a tool that runs on any platform? Or would you include the raw JRE installer/package and have the installer bootstrap code just run it first somehow? > We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to. I hope some nerds with a lot of free time take an interest in it. :-) The rest of us probably don't have the time to spend making javafxpackager do what needs to be done when we have our main product to be working on. The installers are always an after-thought so no employer is going to let me spend much time contributing to javafxpackager when I could be improving the main product. (For Oracle at least it is part of the "main product") Cheers, Scott P. From kevin.rushforth at oracle.com Fri Nov 2 21:28:40 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Nov 2012 21:28:40 -0700 Subject: Can ESC to exit full screen be avoided? In-Reply-To: References: Message-ID: <50949D78.5030202@oracle.com> By design, there is no way to avoid having ESC exit from full-screen mode. There is a JIRA filed to allow trusted apps to be able to disable this: http://javafx-jira.kenai.com/browse/RT-15314 but it is not currently planned for FX 8. -- Kevin Randahl Fink Isaksen wrote: > When I run my application in full screen (on a mac) I am using the escape key for a feature in my application. However if I hit escape, JavaFX (or perhaps Mac OS X) sends my app out of full screen mode. Can this be avoided? > > I have tried invoking event.consume() on the ESC key event, but that does not prevent the exit from full screen. > > Thanks > > Randahl From randahl at rockit.dk Fri Nov 2 21:44:37 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 3 Nov 2012 05:44:37 +0100 Subject: Can ESC to exit full screen be avoided? In-Reply-To: <50949D78.5030202@oracle.com> References: <50949D78.5030202@oracle.com> Message-ID: <49F0A8F2-8624-4E23-8ADF-D87E5DA7B111@rockit.dk> Ah yes, I see ? and it is even the 14th most voted for issue. I too would very much like to see this implemented. R. On Nov 3, 2012, at 5:28 , Kevin Rushforth wrote: > By design, there is no way to avoid having ESC exit from full-screen mode. There is a JIRA filed to allow trusted apps to be able to disable this: > > http://javafx-jira.kenai.com/browse/RT-15314 > > but it is not currently planned for FX 8. > > -- Kevin > > > Randahl Fink Isaksen wrote: >> When I run my application in full screen (on a mac) I am using the escape key for a feature in my application. However if I hit escape, JavaFX (or perhaps Mac OS X) sends my app out of full screen mode. Can this be avoided? >> >> I have tried invoking event.consume() on the ESC key event, but that does not prevent the exit from full screen. >> >> Thanks >> >> Randahl From joshua at marinacci.org Fri Nov 2 22:45:20 2012 From: joshua at marinacci.org (Josh Marinacci) Date: Fri, 2 Nov 2012 22:45:20 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> Message-ID: > > > - Need to install third party native packagers that then get magically > > > picked up from the environment, no way to configure this > > > > > > > > Yep that is awkward. Anyone want to rewrite WiX in pure Java + JNA? > > > > - Need to run a separate build on each target platform to produce the > > > native installer for that platform (not very "Java") > > > > > > > > A non-issue, since you have to test on those platforms anyway and therefore have them available. It *is* an issue, actually. Once you get into production most people use build servers, usually on linux. It is quite often that my test system and my build system are different machines. > > As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable. > > > Application Bundles for Mac should be easy to make from any platform, if the launcher stub binary is part of the cross-platform javafxpackager. It's the .dmg that is tricker, but zips of app bundles work well too.. I'm guessing Linux packages could be done in a pure Java way if someone had the time to write the tool to create the RPM or DEB from pure Java (maybe it's easy?). At least the C source would be available for reference - and contamination via GPL :(. > Windows .msi files would be hardest to deal with I think because I know of no way to make them without Windows. > If you are going to bundle an embedded JRE you will at least need to download the JRE for each platform. Are there copies of all of the platform-specific JREs that aren't exe's or msi's or dmgs or rpms so they can be extracted and embedded by a tool that runs on any platform? Or would you include the raw JRE installer/package and have the installer bootstrap code just run it first somehow? My AppBundler tool (different from the Java.net AppBundler) can create Mac bundles on my Linux build server. The same with windows using izpack (EXE, no installer). Instead of DMGs I use Zips, which work just fine (with one little trick to ensure the executable bit is set correctly). I've never bothered to create Linux specific builds. I just point those users to the WebStart version. I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. http://nsis.sourceforge.net/Screenshots Seems like something we could integrate. As for actually embedding a JRE into an EXE, I don't know how to do that yet. - J > > We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to. > > > I hope some nerds with a lot of free time take an interest in it. :-) > The rest of us probably don't have the time to spend making javafxpackager do what needs to be done when we have our main product to be working on. The installers are always an after-thought so no employer is going to let me spend much time contributing to javafxpackager when I could be improving the main product. (For Oracle at least it is part of the "main product") > > > > Cheers, > > Scott P. From richard.bair at oracle.com Sat Nov 3 06:39:02 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 3 Nov 2012 06:39:02 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> Message-ID: > What contributions do you want as a number 1 priority. I tried to start AU because it was the only thing on this topic I've seen interest in from jfx and so I assumed it was something more likely to get picked up but Igor seemed to lose interest. If you had to pick one thing in this area to get done what would it be and if it was done when would be the earliest it would get included in a jfx release? I am looking at assignments on our side so that we can have somebody senior dedicated full time to the packaging etc who is not involved in the plugin, such that we don't get side-tracked by security issues / etc in the plugin that are always coming up. When that is done, it should be a lot clearer. The AU code I think is a must, but I think a lot of the other issues are also pretty critical. Also there has been some realignment and I expect we will get better tooling support for this in NetBeans as well in the future. Richard From richard.bair at oracle.com Sat Nov 3 06:45:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 3 Nov 2012 06:45:31 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> Message-ID: <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> > I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. Richard From Goddard at seznam.cz Sat Nov 3 06:47:06 2012 From: Goddard at seznam.cz (Jiri Prajzner) Date: Sat, 03 Nov 2012 14:47:06 +0100 (CET) Subject: Audio Effects Message-ID: <4eq.2Us7.1je3fqfxk5N.1GbI1Q@seznam.cz> Hello, will there be a package with audio effects? We've got javafx.scene.effects, but those are all visual effects and even if they'd not, we can't apply them to javafx.scene.media classes because those are not Nodes, technically. I could use javax.sound, but then it's another dependency and different style of API etc. Regards, Jiri -- http://www.dredwerkz.cz(http://www.dredwerkz.cz) +420 739 575 905 218 659 431 http://www.plurk.com/goddard(http://www.plurk.com/goddard) From richard.bair at oracle.com Sat Nov 3 07:05:14 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 3 Nov 2012 07:05:14 -0700 Subject: Audio Effects In-Reply-To: <4eq.2Us7.1je3fqfxk5N.1GbI1Q@seznam.cz> References: <4eq.2Us7.1je3fqfxk5N.1GbI1Q@seznam.cz> Message-ID: <78E1BD3A-5F6E-4F01-8893-F1B6DFA9A55A@oracle.com> We've talked a little about it, but we haven't done anything in this area. I'd say it is a greenfield area for anybody so inclined to work on the feature. Richard On Nov 3, 2012, at 6:47 AM, "Jiri Prajzner" wrote: > Hello, > > will there be a package with audio effects? > We've got javafx.scene.effects, but those are all visual effects and even if > they'd not, we can't apply them to javafx.scene.media classes because those > are not Nodes, technically. > I could use javax.sound, but then it's another dependency and different > style of API etc. > > Regards, Jiri > > -- > http://www.dredwerkz.cz(http://www.dredwerkz.cz) > +420 739 575 905 > 218 659 431 > http://www.plurk.com/goddard(http://www.plurk.com/goddard) From joshua at marinacci.org Sat Nov 3 09:10:55 2012 From: joshua at marinacci.org (Joshua Marinacci) Date: Sat, 3 Nov 2012 09:10:55 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> Message-ID: <8202752180379267598@unknownmsgid> Ah. So an MSI is not just another installer format? It has special properties make it different than NSIS? Most likely sent from Planet Earth On Nov 3, 2012, at 6:45 AM, Richard Bair wrote: >> I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. > > The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. > > Richard > From swpalmer at gmail.com Sat Nov 3 11:07:15 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 3 Nov 2012 14:07:15 -0400 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <8202752180379267598@unknownmsgid> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> Message-ID: <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> Right. MSI is sort of an official MicroSoft Installer format. The .msi file is read by the built-in Windows installer APIs. Sort of like how .pkg is handled natively by OS X, and .rpm and .deb are handled natively by Linux distros. Exe installers could be anything, they just aren't the same. though often they are special bootstrappers tacked on to one or more MSI databases. MSI is a table-based description of the stuff to install. (It isn't particularly good mind you, it's just well supported by the Windows OS.) Scott On 2012-11-03, at 12:10 PM, Joshua Marinacci wrote: > Ah. So an MSI is not just another installer format? It has special > properties make it different than NSIS? > > Most likely sent from Planet Earth > > On Nov 3, 2012, at 6:45 AM, Richard Bair wrote: > >>> I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. >> >> The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. >> >> Richard >> From joshua at marinacci.org Sat Nov 3 11:08:37 2012 From: joshua at marinacci.org (Josh Marinacci) Date: Sat, 3 Nov 2012 11:08:37 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> Message-ID: Interesting. Is this what the new Windows Store uses as well? -- Josh Marinacci joshondesign.com On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote: > Right. MSI is sort of an official MicroSoft Installer format. The .msi file is read by the built-in Windows installer APIs. Sort of like how .pkg is handled natively by OS X, and .rpm and .deb are handled natively by Linux distros. Exe installers could be anything, they just aren't the same. though often they are special bootstrappers tacked on to one or more MSI databases. MSI is a table-based description of the stuff to install. (It isn't particularly good mind you, it's just well supported by the Windows OS.) > > Scott > > On 2012-11-03, at 12:10 PM, Joshua Marinacci wrote: > > > Ah. So an MSI is not just another installer format? It has special > > properties make it different than NSIS? > > > > Most likely sent from Planet Earth > > > > On Nov 3, 2012, at 6:45 AM, Richard Bair wrote: > > > > > > I just tried using the AppBundler (the other one from Java.net (http://Java.net)) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. > > > > > > The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. > > > > > > Richard From pedro.duquevieira at gmail.com Sat Nov 3 12:18:23 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 3 Nov 2012 19:18:23 +0000 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: Message-ID: I'm still clueless about this. Could somebody please respond? Are you going to ditch applets completely? It seems that unfortunately this is the case. Thanks On Sat, Nov 3, 2012 at 2:14 AM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > As for the applets and the jnlp part (specially applets) I already brought > up this subject more than once but either didn't got a response, or got > just some general pointers but no concrete plans for release. > > I think as for offline desktop deployment things are currently handled > well. > > On the other hand applets are seriously crippled. I personally think that > this is a really good area where Java could excel and consequently draw in > a big percentage of developers. Flash is dying and developers are getting > aware that HTML5 isn't what it was promised to be, so there is really no > good technology for creating feature rich web apps. Sure you can use HTML5 > to create nice looking document based web apps but not more than that, at > least not currently. > > I just wish I could deploy my apps with this beautifully crafted JavaFX > controls through the web seamlessly and painlessly (just like flash does > it) :-) > > Thanks, best regards, > > -- > Pedro Duque Vieira > -- Pedro Duque Vieira From Goddard at seznam.cz Sat Nov 3 12:40:45 2012 From: Goddard at seznam.cz (Jiri Prajzner) Date: Sat, 03 Nov 2012 20:40:45 +0100 (CET) Subject: Audio Effects Message-ID: <5WG.2UtP.30WqaTJV2Pa.1GbNCz@seznam.cz> Cool. What would be the starting point? - using javax.sound classes - adding effect properties to javafx.scene.media(http://javafx.scene.media) classes - make javafx.scene.media(http://javafx.scene.media) inherit from Node This also brings another question - are the audio classes actual nodes in upcoming 3D scenegraph? (haven't looked thoroughly at the proposal yet) Regards, Jiri -- http://www.dredwerkz.cz(http://www.dredwerkz.cz) +420 739 575 905 218 659 431 http://www.plurk.com/goddard(http://www.plurk.com/goddard) From richard.bair at oracle.com Sat Nov 3 12:42:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 3 Nov 2012 12:42:49 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: Message-ID: <52F17D6D-6DAB-4D44-A601-30BEB911FF74@oracle.com> Applets certainly are not going to be ditched entirely, but we do have to face the current trends in the industry which are decidedly _away_ from plugins. Although we dedicate engineers to the applet and will continue to do so, we have to be pragmatic and realize that native application deployment is our best opportunity to have a bullet-proof and robust deployment scenario, which also has no associated security issues. Richard On Nov 3, 2012, at 12:18 PM, Pedro Duque Vieira wrote: > I'm still clueless about this. > > Could somebody please respond? > > Are you going to ditch applets completely? It seems that unfortunately this > is the case. > > Thanks > > > On Sat, Nov 3, 2012 at 2:14 AM, Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > >> As for the applets and the jnlp part (specially applets) I already brought >> up this subject more than once but either didn't got a response, or got >> just some general pointers but no concrete plans for release. >> >> I think as for offline desktop deployment things are currently handled >> well. >> >> On the other hand applets are seriously crippled. I personally think that >> this is a really good area where Java could excel and consequently draw in >> a big percentage of developers. Flash is dying and developers are getting >> aware that HTML5 isn't what it was promised to be, so there is really no >> good technology for creating feature rich web apps. Sure you can use HTML5 >> to create nice looking document based web apps but not more than that, at >> least not currently. >> >> I just wish I could deploy my apps with this beautifully crafted JavaFX >> controls through the web seamlessly and painlessly (just like flash does >> it) :-) >> >> Thanks, best regards, >> >> -- >> Pedro Duque Vieira >> > > > > -- > Pedro Duque Vieira From zonski at gmail.com Sat Nov 3 19:13:08 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 4 Nov 2012 13:13:08 +1100 Subject: Why isn't JavaFX on the jdk1.7.0_u10build12 class path? In-Reply-To: <46CD8C3C-9012-4097-AFE6-EF79AE5BDFA6@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> <46CD8C3C-9012-4097-AFE6-EF79AE5BDFA6@gmail.com> Message-ID: I have added an extra command to my Maven plugin that does this fix for you (i.e. copies the JAR across). See: https://github.com/zonski/javafx-maven-plugin It's still a nasty cludge but at least it is partially hidden for Maven users. Note this is only tested on Windows. If anyone runs it on any other plaforms and has problems, let me know. Additionally there is a kickstarter project for anyone wanting to use this: https://github.com/zonski/hello-javafx-maven-example On Thu, Oct 25, 2012 at 9:46 AM, Scott Palmer wrote: > 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 lehmann at media-interactive.de Sun Nov 4 10:43:44 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Sun, 4 Nov 2012 19:43:44 +0100 Subject: How to trigger property invalidation? In-Reply-To: <5093E5DB.2000503@media-interactive.de> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> <5093E5DB.2000503@media-interactive.de> Message-ID: <5096B760.3070304@media-interactive.de> Thanks to everyone who responded. Let me combine my rpelies in this email to avoid spamming the list too much. On 02.11.2012 17:30, Richard Bair wrote: > In Region we have a custom property that we can use to force invalidation. Is this sort of what you're looking for? More or less. But this seems like a new implementation of a property interface, with manual listener management etc. It is not a problem, technically, but reinvents the wheel. The existing wheel already has a markInvalid method, unfortunately it is private, not protected. Everything else would be fine. This reminds me of using POJOs for a TableView. It is easy to get the data into the control using a PropertyValueFactory. But it is quite hard to have the control update itself (or a cell) if I know that property X of POJO Y has changed. Again, this could be solved simply by providing an invalidate method on the TableView (or PropertyValueFactory). Without this you need to write a lot of code to make this happen (basically provide observable values wrapping each POJO bean in a generic way - which is not trivial as recently discussed on this list, blackmagic etc). On 02.11.2012 19:12, Martin Sladecek wrote: > Hi Werner, > maybe an ObjectProperty isn't really what you are looking for. If you > have single bean with an non-observable property (BTW, how do you know > it has changed?) and you want to convert it to an FX property, why not > using a property of the same type as MyBean.myProperty and set FX > property when myProperty changes? Basically I made an FX custom control which serves as editor for a domain bean (nothing too fancy). To understand this better, assume the following example. Let the bean represent an employee with first name, last name, address, etc properties. The editor would look like a form with text fields for this stuff. I figured it would be neat to have an observable "employee" property on that editor control: - set an employee value to initialize the editor control, - get an employee to retrieve the currently edited employee state, and - add a property listener to implement a dirty flag or somesuch. Obviously the editor knows when the employee changes. But it cannot simply invalidate the property when only the address changes (assuming that address is another bean). I am working around this by creating a whole new employee instance with just a tiny change over the original employee so that I can assign this to the property, thus forcing invalidation. To make things worse, in my case I am using a slider to represent a zoom level - and that creates a lot of noise (every move of the slider triggers a copy of the bean). On 02.11.2012 19:46, Will Hoover wrote: > ...or you could use a BeanPathAdapter that handles all your POJO field to > JFX property conversions for you (http://wp.me/P2rLDc-1s) and listen for > changes to the bean: Will, I have seen your articles and really liked to read about this because it seemed to solve a problem I had (see above about the TableView problem). This may be something to revisit later for me. Right now it seems a little bit over the top, plus I am not at liberty to require J7+, unfortunately. Rgds Werner From lehmann at media-interactive.de Sun Nov 4 10:56:04 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Sun, 4 Nov 2012 19:56:04 +0100 Subject: Memory Leaks In-Reply-To: <5077CB6B-AFDA-418E-A896-DFE43667F0EB@oracle.com> References: <50831490.2030007@oracle.com> <93CAD8AA-5953-412F-9311-C8CE9AAA7992@oracle.com> <50858479.3010600@oracle.com> <5077CB6B-AFDA-418E-A896-DFE43667F0EB@oracle.com> Message-ID: <5096BA44.6040206@media-interactive.de> By the way, 2.2 is still considered as unreleased in Jira (with 2.0 being the latest released version). When reporting a bug for 2.2 you have to pick a value from the "unreleased" part of the list of version numbers. Not a big deal but maybe easy enough to fix. On 02.11.2012 21:50, Richard Bair wrote: > Thanks for the link, I didn't know about this feature (passing it > on). Unless we make our version numbers more verbose (including build > numbers), it won't help to accumulate what fixes went into a specific > build (as I understand it), but at least for major releases we could > have a comprehensive report. From pavel.safrata at oracle.com Mon Nov 5 00:46:31 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 05 Nov 2012 09:46:31 +0100 Subject: How to trigger property invalidation? In-Reply-To: <5096B760.3070304@media-interactive.de> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> <5093E5DB.2000503@media-interactive.de> <5096B760.3070304@media-interactive.de> Message-ID: <50977CE7.5030403@oracle.com> Hello Werner, On 4.11.2012 19:43, Werner Lehmann wrote: > > On 02.11.2012 19:12, Martin Sladecek wrote: > > Hi Werner, > > maybe an ObjectProperty isn't really what you are looking for. If you > > have single bean with an non-observable property (BTW, how do you know > > it has changed?) and you want to convert it to an FX property, why not > > using a property of the same type as MyBean.myProperty and set FX > > property when myProperty changes? > > Basically I made an FX custom control which serves as editor for a > domain bean (nothing too fancy). > > To understand this better, assume the following example. Let the bean > represent an employee with first name, last name, address, etc > properties. The editor would look like a form with text fields for > this stuff. I figured it would be neat to have an observable > "employee" property on that editor control: > - set an employee value to initialize the editor control, > - get an employee to retrieve the currently edited employee state, and > - add a property listener to implement a dirty flag or somesuch. > > Obviously the editor knows when the employee changes. But it cannot > simply invalidate the property when only the address changes (assuming > that address is another bean). > > I am working around this by creating a whole new employee instance > with just a tiny change over the original employee so that I can > assign this to the property, thus forcing invalidation. To make things > worse, in my case I am using a slider to represent a zoom level - and > that creates a lot of noise (every move of the slider triggers a copy > of the bean). I understand your concern, I've come across a similar issue some time ago. Your approach looks technically nice but conceptually is not so nice because the property refers to an employee, and even if the employee moved to a different address, it's still the same employee. Admitting it doesn't look so neat, here is the approach we've chosen: The control has an observable "employee" property The Employee has observable properties "first name", "last name" etc. The Employee also has an EmployeeChangedEvent and fires it on itself whenever some of its properties changes So you can: - set an employee value to initialize the editor control - get an employee to retrieve the currently edited employee (and than read the state from it) - observe on the particular employee properties to see the changes done by the control, and/or - listen to the employee changed event to implement the general dirty flag The concept is nicer there because you tell to the control "now, edit this employee" and when edited it doesn't tell you "now, I'm editing a different employee" but instead tells you "I'm editing still the same employee, but its address has changed" via the "address" property listener, and "some of its properties have changed" via the event. Regards, Pavel From hang.vo at oracle.com Mon Nov 5 02:33:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Nov 2012 10:33:30 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121105103336.D4EAC47786@hg.openjdk.java.net> Changeset: 04a583291281 Author: Martin Sladecek Date: 2012-11-05 11:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/04a583291281 RT-16011: Release Nodes when they are no longer part of the scenegraph. ! javafx-ui-common/src/javafx/scene/Node.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubNode.java Changeset: 70af26170488 Author: Martin Sladecek Date: 2012-11-05 11:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/70af26170488 merge From lehmann at media-interactive.de Mon Nov 5 02:57:34 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 5 Nov 2012 11:57:34 +0100 Subject: How to trigger property invalidation? In-Reply-To: <50977CE7.5030403@oracle.com> References: <5093B49D.1040005@media-interactive.de> <5093DDD0.8030106@oracle.com> <5093E5DB.2000503@media-interactive.de> <5096B760.3070304@media-interactive.de> <50977CE7.5030403@oracle.com> Message-ID: <50979B9E.2000608@media-interactive.de> Hi Pavel, On 05.11.2012 09:46, Pavel Safrata wrote: > I understand your concern, I've come across a similar issue some time > ago. Your approach looks technically nice but conceptually is not so > nice because the property refers to an employee, and even if the > employee moved to a different address, it's still the same employee. > Admitting it doesn't look so neat, here is the approach we've chosen: thanks. It is true, editing the employee does not make it a different employee. That's exactly why I'd prefer to invalidate the property without replacing the employee instance ;-) I realize that making everything observable would solve this problem - while creating a new one: server provides a POJO, and for GUI I'd have to copy the data to an "FX-Employee" bean. And that's exactly one of the topics in this other property thread on the list (blackmagic (I like that), property paths, etc). Personally I don't want to create those FX observable beans shadowing the domain beans to get observability. The data of a single employee would go from the database to a Hibernate bean to a domain bean to an FX bean and back. That's a lot of copying and boilerplate. But I also realize that there is no easy way to have both. It seems easy enough to make markInvalid protected but even then I'd have to find a workaround for 2.2.x. Rgds Werner From martin.sladecek at oracle.com Mon Nov 5 03:50:45 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 05 Nov 2012 12:50:45 +0100 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> Message-ID: <5097A815.4000803@oracle.com> On 11/02/2012 06:41 PM, Richard Bair wrote: > Looks OK to me. Lets not deprecated the protected constructors though, > unless there is a good reason to (even if they are more or less useless). Well, one good reason is that they won't stay in the API once there will be FX JSR, as I guess all deprecated methods will be removed then. But otherwise there's no reason to deprecated them (like security or something), it just keeps the API clean IMO. -Martin From lehmann at media-interactive.de Mon Nov 5 04:23:28 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 5 Nov 2012 13:23:28 +0100 Subject: JIRA down Message-ID: <5097AFC0.1070906@media-interactive.de> Hi, JIRA not available, again. Apparently it has been shut down without removing a lock file. Maybe lockfile removal can be included in the shutdown process? Werner From hang.vo at oracle.com Mon Nov 5 07:36:11 2012 From: hang.vo at oracle.com (Mong Hang Vo) Date: Mon, 05 Nov 2012 07:36:11 -0800 Subject: JIRA down In-Reply-To: <5097AFC0.1070906@media-interactive.de> References: <5097AFC0.1070906@media-interactive.de> Message-ID: <5097DCEB.4090309@oracle.com> Werner, The following blocker submitted. We are working with Kenai staffs to bring JavaFX back on-line as soon as we can. http://kenai.com/jira/browse/KENAI-3818 (avaFX JIRA down because jira.home directory was locked) Thanks, Mong Werner Lehmann wrote: > Hi, > > JIRA not available, again. Apparently it has been shut down without > removing a lock file. Maybe lockfile removal can be included in the > shutdown process? > > Werner From richard.bair at oracle.com Mon Nov 5 07:31:17 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Nov 2012 07:31:17 -0800 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <5097A815.4000803@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> <5097A815.4000803@oracle.com> Message-ID: <57C629E2-7F22-47EC-B7FE-9B99262FF1CC@oracle.com> On Nov 5, 2012, at 3:50 AM, Martin Sladecek wrote: > On 11/02/2012 06:41 PM, Richard Bair wrote: >> Looks OK to me. Lets not deprecated the protected constructors though, unless there is a good reason to (even if they are more or less useless). > Well, one good reason is that they won't stay in the API once there will be FX JSR, as I guess all deprecated methods will be removed then. This is true, however we want to limit this usage to those cases that are absolutely necessary, as any change is bound to make it more difficult for somebody to upgrade or raises the possibility of breaking somebody in the wild, which is not something I would want to do. > But otherwise there's no reason to deprecated them (like security or something), it just keeps the API clean IMO. I think the reason needs to be more compelling to break developers. I'm as obsessive compulsive about API design as the next guy, but I think we need to accept a certain amount of imperfection and be doubly careful that new API is seen as being forever, unless it is well and truly broken (security, etc). Richard From martin.sladecek at oracle.com Mon Nov 5 07:51:31 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 05 Nov 2012 16:51:31 +0100 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <57C629E2-7F22-47EC-B7FE-9B99262FF1CC@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> <5097A815.4000803@oracle.com> <57C629E2-7F22-47EC-B7FE-9B99262FF1CC@oracle.com> Message-ID: <5097E083.3060404@oracle.com> I would agree when talking in general, but this case is different. The constructors will create Gesture event will everything set to default value (0, false). All of these fields are private and final and there are no setters (and never were) and I can't imagine anything where such event could be useful, not even when used together with some "copyFor" method. Both of these constructors will just generate gesture events at (0,0), with no modifiers set. This can be probably used just for testing this one particular case, so I'm fairly sure removing this will never break any code. -Martin On 11/05/2012 04:31 PM, Richard Bair wrote: > On Nov 5, 2012, at 3:50 AM, Martin Sladecek wrote: > >> On 11/02/2012 06:41 PM, Richard Bair wrote: >>> Looks OK to me. Lets not deprecated the protected constructors though, unless there is a good reason to (even if they are more or less useless). >> Well, one good reason is that they won't stay in the API once there will be FX JSR, as I guess all deprecated methods will be removed then. > This is true, however we want to limit this usage to those cases that are absolutely necessary, as any change is bound to make it more difficult for somebody to upgrade or raises the possibility of breaking somebody in the wild, which is not something I would want to do. > >> But otherwise there's no reason to deprecated them (like security or something), it just keeps the API clean IMO. > I think the reason needs to be more compelling to break developers. I'm as obsessive compulsive about API design as the next guy, but I think we need to accept a certain amount of imperfection and be doubly careful that new API is seen as being forever, unless it is well and truly broken (security, etc). > > Richard From richard.bair at oracle.com Mon Nov 5 08:32:50 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Nov 2012 08:32:50 -0800 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <5097E083.3060404@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> <5097A815.4000803@oracle.com> <57C629E2-7F22-47EC-B7FE-9B99262FF1CC@oracle.com> <5097E083.3060404@oracle.com> Message-ID: OK. On Nov 5, 2012, at 7:51 AM, Martin Sladecek wrote: > I would agree when talking in general, but this case is different. > > The constructors will create Gesture event will everything set to default value (0, false). All of these fields are private and final and there are no setters (and never were) and I can't imagine anything where such event could be useful, not even when used together with some "copyFor" method. > Both of these constructors will just generate gesture events at (0,0), with no modifiers set. This can be probably used just for testing this one particular case, so I'm fairly sure removing this will never break any code. > > -Martin > > On 11/05/2012 04:31 PM, Richard Bair wrote: >> On Nov 5, 2012, at 3:50 AM, Martin Sladecek wrote: >> >>> On 11/02/2012 06:41 PM, Richard Bair wrote: >>>> Looks OK to me. Lets not deprecated the protected constructors though, unless there is a good reason to (even if they are more or less useless). >>> Well, one good reason is that they won't stay in the API once there will be FX JSR, as I guess all deprecated methods will be removed then. >> This is true, however we want to limit this usage to those cases that are absolutely necessary, as any change is bound to make it more difficult for somebody to upgrade or raises the possibility of breaking somebody in the wild, which is not something I would want to do. >> >>> But otherwise there's no reason to deprecated them (like security or something), it just keeps the API clean IMO. >> I think the reason needs to be more compelling to break developers. I'm as obsessive compulsive about API design as the next guy, but I think we need to accept a certain amount of imperfection and be doubly careful that new API is seen as being forever, unless it is well and truly broken (security, etc). >> >> Richard > From hang.vo at oracle.com Mon Nov 5 09:58:59 2012 From: hang.vo at oracle.com (Mong Hang Vo) Date: Mon, 05 Nov 2012 09:58:59 -0800 Subject: JIRA down In-Reply-To: <5097DCEB.4090309@oracle.com> References: <5097AFC0.1070906@media-interactive.de> <5097DCEB.4090309@oracle.com> Message-ID: <5097FE63.90407@oracle.com> JavaFX JIRA issue should be resolved now. Thanks, Mong On 11/5/2012 7:36 AM, Mong Hang Vo wrote: > Werner, > > The following blocker submitted. We are working with Kenai staffs to > bring JavaFX back on-line as soon as we can. > > http://kenai.com/jira/browse/KENAI-3818 > (avaFX JIRA down because jira.home directory was locked) > > Thanks, > Mong > > Werner Lehmann wrote: >> Hi, >> >> JIRA not available, again. Apparently it has been shut down without >> removing a lock file. Maybe lockfile removal can be included in the >> shutdown process? >> >> Werner > From hang.vo at oracle.com Mon Nov 5 10:48:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Nov 2012 18:48:40 +0000 Subject: hg: openjfx/8/graphics/rt: COMMENT-ONLY (fixing internal comments) Message-ID: <20121105184843.DDEEE47797@hg.openjdk.java.net> Changeset: 9e5f8388c043 Author: Felipe Heidrich Date: 2012-11-05 10:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9e5f8388c043 COMMENT-ONLY (fixing internal comments) ! javafx-ui-common/src/javafx/scene/layout/Region.java From randahl at rockit.dk Mon Nov 5 10:50:17 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 5 Nov 2012 19:50:17 +0100 Subject: JavaFX and the Missing Interfaces Message-ID: I have been struggling with a number of problems stemming from the way JavaFX is designed ? specifically the lack of interfaces for many of the extension points in the class hierarchy. It takes some thorough explaining with code examples, so instead of just an unformatted e-mail I posted a more readable explanation of the problem on-line: Please read http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html I hope we could have a constructive discussion on this matter on this list before I go ahead and file a Jira, so the Jira issue becomes the best possible basis for solving the design problem. Thanks Randahl From knut.arne.vedaa at broadpark.no Mon Nov 5 11:49:05 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Mon, 05 Nov 2012 20:49:05 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: Message-ID: <50981831.9040206@broadpark.no> While you want NodeBase implements Node but would be happy with Node implements SceneNode I'd propose a third alternative (which I prefer to the first): Node implements NodeLike This naming scheme is used a lot in Scala's standard library (but for traits and not interfaces, the former which can have concrete members). Speaking of - if I understand your blog post correctly, what you want is this: trait IControl extends Control { def iCommonMethod = "something" } class ITextField extends TextField with IControl def fooBar(iControl: IControl) { iControl setTooltip new Tooltip("foo bar") iControl.iCommonMethod } fooBar(iTextField) val iTextField = new ITextField iTextField.iCommonMethod Which is perfectly valid Scala code. So if you can't convince the powers that be to refactor the API, you have at least another option, hint hint. :) Knut Arne Vedaa On 05.11.2012 19:50, Randahl Fink Isaksen wrote: > I have been struggling with a number of problems stemming from the way JavaFX is designed ? specifically the lack of interfaces for many of the extension points in the class hierarchy. > > It takes some thorough explaining with code examples, so instead of just an unformatted e-mail I posted a more readable explanation of the problem on-line: > Please read http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html > > I hope we could have a constructive discussion on this matter on this list before I go ahead and file a Jira, so the Jira issue becomes the best possible basis for solving the design problem. > > Thanks > > Randahl > From zonski at gmail.com Mon Nov 5 12:20:59 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Nov 2012 07:20:59 +1100 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: Message-ID: +1 I think we've had this conversation before. Maybe something to do with interfaces being too brittle where if you add a method anyone implementing it will now be missing a method, whereas with a base class they can add a stub method? Other frameworks use interfaces extensively though (eg Spring, java.util.Collections), generally with positive outcomes. On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen wrote: > I have been struggling with a number of problems stemming from the way JavaFX is designed ? specifically the lack of interfaces for many of the extension points in the class hierarchy. > > It takes some thorough explaining with code examples, so instead of just an unformatted e-mail I posted a more readable explanation of the problem on-line: > Please read http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html > > I hope we could have a constructive discussion on this matter on this list before I go ahead and file a Jira, so the Jira issue becomes the best possible basis for solving the design problem. > > Thanks > > Randahl From richard.bair at oracle.com Mon Nov 5 12:26:21 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Nov 2012 12:26:21 -0800 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: Message-ID: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> That is correct, when you are designing a class hierarchy such that is intended to be extended via subclassing, interfaces are pretty much a non-starter. If each Node in the scene graph had an associated interface, then we'd have to create new versions of the interfaces for each release where we add a single new method -- or the interfaces would have to be some subset. Maybe somebody can show how this would work in more concrete terms? I don't even see how it would be practical at all. Richard On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: > +1 > > I think we've had this conversation before. Maybe something to do with interfaces being too brittle where if you add a method anyone implementing it will now be missing a method, whereas with a base class they can add a stub method? > > Other frameworks use interfaces extensively though (eg Spring, java.util.Collections), generally with positive outcomes. > > > > On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen wrote: > >> I have been struggling with a number of problems stemming from the way JavaFX is designed ? specifically the lack of interfaces for many of the extension points in the class hierarchy. >> >> It takes some thorough explaining with code examples, so instead of just an unformatted e-mail I posted a more readable explanation of the problem on-line: >> Please read http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >> >> I hope we could have a constructive discussion on this matter on this list before I go ahead and file a Jira, so the Jira issue becomes the best possible basis for solving the design problem. >> >> Thanks >> >> Randahl From zonski at gmail.com Mon Nov 5 12:33:01 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Nov 2012 07:33:01 +1100 Subject: JavaFX and the Missing Interfaces In-Reply-To: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> Message-ID: > Maybe somebody can show how this would work in more concrete terms? I > don't even see how it would be practical at all. > As in how it would be used by end developers and to what benefit, or as in how to make it workable in the current JFX codebase? > Richard > > On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: > > > +1 > > > > I think we've had this conversation before. Maybe something to do with > interfaces being too brittle where if you add a method anyone implementing > it will now be missing a method, whereas with a base class they can add a > stub method? > > > > Other frameworks use interfaces extensively though (eg Spring, > java.util.Collections), generally with positive outcomes. > > > > > > > > On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen > wrote: > > > >> I have been struggling with a number of problems stemming from the way > JavaFX is designed ? specifically the lack of interfaces for many of the > extension points in the class hierarchy. > >> > >> It takes some thorough explaining with code examples, so instead of > just an unformatted e-mail I posted a more readable explanation of the > problem on-line: > >> Please read > http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html > >> > >> I hope we could have a constructive discussion on this matter on this > list before I go ahead and file a Jira, so the Jira issue becomes the best > possible basis for solving the design problem. > >> > >> Thanks > >> > >> Randahl > > From phidias51 at gmail.com Mon Nov 5 12:41:31 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Mon, 5 Nov 2012 12:41:31 -0800 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> Message-ID: I guess the benefit of doing it this way is that it would make it easier to swap out implementations, and do unit testing/mocking. The downside if the API is changing frequently then every release is liable to break something. But that's why people have continuous integration servers. :-) Mark Cheers, Mark On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: > > Maybe somebody can show how this would work in more concrete terms? I > > don't even see how it would be practical at all. > > > > As in how it would be used by end developers and to what benefit, or as in > how to make it workable in the current JFX codebase? > > > > > Richard > > > > On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: > > > > > +1 > > > > > > I think we've had this conversation before. Maybe something to do with > > interfaces being too brittle where if you add a method anyone > implementing > > it will now be missing a method, whereas with a base class they can add a > > stub method? > > > > > > Other frameworks use interfaces extensively though (eg Spring, > > java.util.Collections), generally with positive outcomes. > > > > > > > > > > > > On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen > > wrote: > > > > > >> I have been struggling with a number of problems stemming from the way > > JavaFX is designed ? specifically the lack of interfaces for many of the > > extension points in the class hierarchy. > > >> > > >> It takes some thorough explaining with code examples, so instead of > > just an unformatted e-mail I posted a more readable explanation of the > > problem on-line: > > >> Please read > > http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html > > >> > > >> I hope we could have a constructive discussion on this matter on this > > list before I go ahead and file a Jira, so the Jira issue becomes the > best > > possible basis for solving the design problem. > > >> > > >> Thanks > > >> > > >> Randahl > > > > > From richard.bair at oracle.com Mon Nov 5 12:42:40 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Nov 2012 12:42:40 -0800 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> Message-ID: <1FFBE826-3E14-4F04-9C54-2BEAA536D0C0@oracle.com> > Maybe somebody can show how this would work in more concrete terms? I don't even see how it would be practical at all. > > As in how it would be used by end developers and to what benefit, or as in how to make it workable in the current JFX codebase? The problem is that we cannot add new methods to an interface in a subsequent release. If we were to do so, then although all running binaries would still work fine (assuming you don't mix 'n match newer code with older libraries that don't support the new methods), any code that was implementing the interface would need to be modified at compile time. So for example, Randahl has MyRectangle implementing the SceneRectangle interface but not extending from the Rectangle class. We add some method to SceneRectangle in 8.1. He now has to modify his code when he tries to compile with 8.1 to implement this new method. This level of source incompatibility is not allowed on JavaSE. The normal course of affairs is to therefore have SceneRectangle2 with the new method and have Rectangle implement both SceneRectangle and SceneRectangle2. And so on. And we are guaranteed to then have a great multitude of interfaces over the course of the next 10 years. There are a very few places where the likelihood of future changes is minor and an interface could have been used. But in the whole we consciously avoided the use of interface in most places whenever possible, because without defender methods (which were not even considered at the time and won't be available until 8 and have their own set of caveats and are not universally useful) there is no way to evolve an interface over subsequent releases without source incompatibility. In addition, note that Parent returns concrete Node's, and couldn't be changed to return the interfaces, so it isn't clear to me that there is any benefit to having interfaces at this point in time anyway. Not to mention having both interfaces and concrete classes in such cases increases the class count, in some cases significantly (depending on how far it was taken). So my question was, how would using interfaces in an API designed for extension (such as the scene graph -- or any GUI toolkit, really, with a deep class hierarchy) be workable? I'm not aware of it ever being done successfully in such cases, whereas every example I know of uses a concrete class hierarchy for such a design. Not that I particularly care what has been done before if it could be done better, but I don't see how using interfaces helps. It really comes down to evolution -- interfaces don't allow for it. At least, not without introducing a lot of noise. Richard From pedro.duquevieira at gmail.com Mon Nov 5 12:46:51 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 5 Nov 2012 20:46:51 +0000 Subject: JavaFX and the Missing Interfaces Message-ID: I've read your blog post. May I suggest doing: Interface IControl { Control getControlRepresentation(); (...) } This way you enforce every implementing class to have a Control representation. And also as a plus you don't need to recur to casting when you need to call methods from Control, because you can get a Control representation via getControlRepresentation(). This is basically composition instead of inheritance, which I think IMHO is better most of the time. Also one more note, the methods of the API are final because of security reasons. I guess Java is to blame for this. My 2cents, best regards, -- Pedro Duque Vieira From John_Smith at symantec.com Mon Nov 5 12:47:58 2012 From: John_Smith at symantec.com (John Smith) Date: Mon, 5 Nov 2012 12:47:58 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160793A882@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > Is the jre trimming option (ie project jigsaw precursor) still planned for java 8 and can you give us any indication on what this will look like and how it will work? There was a presentation at JavaOne by Bob Vandette which detailed how some of this may work: https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8ABE54064406AC304AD59/CON4538_Vandette.pdf The focus of the presentation is on java for embedded platforms, but there is discussion of jre trimming in general in there including a developmental tool named jrecreate and targeted, reduced functionality profiles supported by the javac and jar commands. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Friday, November 02, 2012 5:07 PM To: Richard Bair Cc: openjfx-dev at openjdk.java.net Subject: Re: JFX build and deployment - squeaking wheel > As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable. We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to. I am definitely watching for the open sourcing of that to happen. I'm hoping all the code around the native packager, the native launcher code for each platform and everything to do with native building will be part of that open sourced code. I'm hoping there will be no technical or legal barriers to us using that code within our own build tools and completely avoid the bundled jre build tools (so we don't have to wait months/years for our fixes to be officially included before our tools can be used). Is it all community work then or are there plans for any work to be done in this area from the official jfx team - and if so what/when? I don't want to double up on any work (as happened with the native launcher work - Igor and I wrote the same code because I didn't know he was working on it). Is the jre trimming option (ie project jigsaw precursor) still planned for java 8 and can you give us any indication on what this will look like and how it will work? Will the legals be solved as well as the technical issues? What contributions do you want as a number 1 priority. I tried to start AU because it was the only thing on this topic I've seen interest in from jfx and so I assumed it was something more likely to get picked up but Igor seemed to lose interest. If you had to pick one thing in this area to get done what would it be and if it was done when would be the earliest it would get included in a jfx release? From richard.bair at oracle.com Mon Nov 5 12:58:27 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Nov 2012 12:58:27 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> Message-ID: I'm not sure, to be honest. On Nov 3, 2012, at 11:08 AM, Josh Marinacci wrote: > Interesting. Is this what the new Windows Store uses as well? > > -- > Josh Marinacci > joshondesign.com > > On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote: > >> Right. MSI is sort of an official MicroSoft Installer format. The .msi file is read by the built-in Windows installer APIs. Sort of like how .pkg is handled natively by OS X, and .rpm and .deb are handled natively by Linux distros. Exe installers could be anything, they just aren't the same. though often they are special bootstrappers tacked on to one or more MSI databases. MSI is a table-based description of the stuff to install. (It isn't particularly good mind you, it's just well supported by the Windows OS.) >> >> Scott >> >> On 2012-11-03, at 12:10 PM, Joshua Marinacci wrote: >> >>> Ah. So an MSI is not just another installer format? It has special >>> properties make it different than NSIS? >>> >>> Most likely sent from Planet Earth >>> >>> On Nov 3, 2012, at 6:45 AM, Richard Bair wrote: >>> >>>>> I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. >>>> >>>> The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. >>>> >>>> Richard > From zonski at gmail.com Mon Nov 5 13:41:38 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Nov 2012 08:41:38 +1100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160793A882@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793A882@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Awesome, thanks John! That is actually the best news in this space for a while. >From Richard's comments (and working my way through all the JavaOne videos), I'm working out that deployment is not a show stopper for the current JFX main ("enterprise") clients since it sounds like they are deploying "on site" into very controlled eco-systems and not really using any of the JFX packaging tools to their full extent. Ok, fair enough. Whereas I'm looking at Java being deployed to the general public, and I've been trying to use the JFX tools to do this with all the problems listed previously. From what I can gather no one is really deploying to the public happily, and the reason there is so little activity/progress on it is because the bigger fish don't need it (yet). Believe it or not, that actually takes a lot of the frustration out of it - I can comprehend the logic at last, which makes it a lot easier to swallow. Maybe instead of "enterprise" apps I should use the term "consumer" apps (not sure that's quite right either though - too far the other way)? All my "enterprise" apps are consumer apps to some extent. At a minimum users want to use them on their home PC when working from home, but just as common is for people to use them in distributed offices (branch/retail outlets for example) or in uncontrolled environments (schools across australia) or on disparate laptop or tablet devices (safety inspectors, insurance brokers, etc, going out to customer sites, etc). I just don't have the luxury to dictate the platform nor can I push releases or Java updates out to these guys magically. Since the end users may be low tech and have to do the setups themselves, I also need the simplest, quickest of installs to get them going. I guess for a cargo unloading system, there is not a lot of working from home or a big need for iPad support (although I'd if they had iPads for their in-field workers they'd use them). For my use case the 70MB downloads are no good for me - a teacher in country Australia will take a very long time to download 70MB and a mining inspector in Papua New Guinea will take even longer on a satellite connection (I think you American's might be spoiled for internet speed). And it's also why I need smart-devices (or at least a medium range plan for them - I never needed it today, just needed a strategy and a roadmap for it), since "consumer" apps have to run on "consumer" platforms and Android and iOS are fast becoming the dominant player in this space. So (finally) understanding that my use case is a secondary one, I'm really interested to know more about this Compact profile stuff for Java 8. I'm assuming the Minimal Hotspot and compact profile will all run on a standard desktop, i.e. there's nothing about it that will make it "embedded" specific? I'd love to know more about the "FX Embedded" project. Is this an actual different implementation or just the FX code bundled up in a way that it can be included as a JAR? It doesn't seem to be on any of the 3 compact profiles so I am assuming there's a different approach for actually including it - i.e. it's not a JRE command line thing like the rest of it? Will we be able to run FX Embedded on the "compact JRE profile 1" on a standard desktop or will it be specific to embedded hardware? If not will be able to pull in FX regular and run it on profile 1 VMs? Can we leave out things like charts and the web browser, etc, in order to make the JRE even more lean (would it help?). How can I get more info on this project, monitor it's progress and/or be involved with early access, etc? Any and all links, tips, announcements and resources would be of huge interest. On a side note, I assume Oracle has noted the conversations on legal problems with porting OpenJDK/OpenJFX to iOS? This compact JRE stuff opens the door at a technical level to Android and iOS support but licencing restrictions would still rule out iOS as I understand it. On Tue, Nov 6, 2012 at 7:47 AM, John Smith wrote: > > Is the jre trimming option (ie project jigsaw precursor) still planned > for java 8 and can you give us any indication on what this will look like > and how it will work? > > There was a presentation at JavaOne by Bob Vandette which detailed how > some of this may work: > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8ABE54064406AC304AD59/CON4538_Vandette.pdf > The focus of the presentation is on java for embedded platforms, but there > is discussion of jre trimming in general in there including a developmental > tool named jrecreate and targeted, reduced functionality profiles supported > by the javac and jar commands. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski > Sent: Friday, November 02, 2012 5:07 PM > To: Richard Bair > Cc: openjfx-dev at openjdk.java.net > Subject: Re: JFX build and deployment - squeaking wheel > > > As I've mentioned before (and during the keynote at JavaOne 2012), this > is where I want to put my effort. The difficult problem is being able to > build installers from any system for any other system, but baring that, the > rest is pretty solvable. We're open sourcing the javafx packager, which > hopefully helps make this a little easier to contribute to. > > I am definitely watching for the open sourcing of that to happen. I'm > hoping all the code around the native packager, the native launcher code > for each platform and everything to do with native building will be part of > that open sourced code. I'm hoping there will be no technical or legal > barriers to us using that code within our own build tools and completely > avoid the bundled jre build tools (so we don't have to wait months/years > for our fixes to be officially included before our tools can be used). > > Is it all community work then or are there plans for any work to be done > in this area from the official jfx team - and if so what/when? I don't want > to double up on any work (as happened with the native launcher work - Igor > and I wrote the same code because I didn't know he was working on it). > > Is the jre trimming option (ie project jigsaw precursor) still planned for > java 8 and can you give us any indication on what this will look like and > how it will work? Will the legals be solved as well as the technical issues? > > What contributions do you want as a number 1 priority. I tried to start AU > because it was the only thing on this topic I've seen interest in from jfx > and so I assumed it was something more likely to get picked up but Igor > seemed to lose interest. If you had to pick one thing in this area to get > done what would it be and if it was done when would be the earliest it > would get included in a jfx release? > > > From John_Smith at symantec.com Mon Nov 5 14:32:40 2012 From: John_Smith at symantec.com (John Smith) Date: Mon, 5 Nov 2012 14:32:40 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > Is this what the new Windows Store uses as well? No, Windows Store does not use MSI, it uses appx files and Open Packaging Conventions. There is no installer, updater or uninstaller for the package, just some metadata which a store client can use to install, update or uninstall a component. appx is just like a zip file with a manifest, similar to a jar file. Those interested, can see here for info: http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspx App packages and deployment (Windows Store apps) http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspx App packager (MakeAppx.exe) - kind of the Windows Store equivalent of javafxpackager.exe http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspx Packaging, deployment, and query of Windows Store apps -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Monday, November 05, 2012 12:58 PM To: Josh Marinacci Cc: openjfx-dev at openjdk.java.net Subject: Re: JFX build and deployment - squeaking wheel I'm not sure, to be honest. On Nov 3, 2012, at 11:08 AM, Josh Marinacci wrote: > Interesting. Is this what the new Windows Store uses as well? > > -- > Josh Marinacci > joshondesign.com > > On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote: > >> Right. MSI is sort of an official MicroSoft Installer format. The >> .msi file is read by the built-in Windows installer APIs. Sort of >> like how .pkg is handled natively by OS X, and .rpm and .deb are >> handled natively by Linux distros. Exe installers could be anything, >> they just aren't the same. though often they are special >> bootstrappers tacked on to one or more MSI databases. MSI is a >> table-based description of the stuff to install. (It isn't >> particularly good mind you, it's just well supported by the Windows >> OS.) >> >> Scott >> >> On 2012-11-03, at 12:10 PM, Joshua Marinacci wrote: >> >>> Ah. So an MSI is not just another installer format? It has special >>> properties make it different than NSIS? >>> >>> Most likely sent from Planet Earth >>> >>> On Nov 3, 2012, at 6:45 AM, Richard Bair wrote: >>> >>>>> I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. >>>> >>>> The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. >>>> >>>> Richard > From hang.vo at oracle.com Mon Nov 5 14:48:54 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Nov 2012 22:48:54 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121105224858.840074779F@hg.openjdk.java.net> Changeset: 8e85e840a981 Author: hudson Date: 2012-11-01 18:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8e85e840a981 Added tag 8.0-b63 for changeset 526513110eba ! .hgtags Changeset: 0f2f18efc353 Author: Paru Somashekar Date: 2012-11-05 22:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0f2f18efc353 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From randahl at rockit.dk Mon Nov 5 14:54:30 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 5 Nov 2012 23:54:30 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> Message-ID: <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. Randahl On Nov 5, 2012, at 21:41 , Mark Fortner wrote: > I guess the benefit of doing it this way is that it would make it easier to > swap out implementations, and do unit testing/mocking. The downside if the > API is changing frequently then every release is liable to break something. > But that's why people have continuous integration servers. :-) > > Mark > > Cheers, > > Mark > > > > > On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: > >>> Maybe somebody can show how this would work in more concrete terms? I >>> don't even see how it would be practical at all. >>> >> >> As in how it would be used by end developers and to what benefit, or as in >> how to make it workable in the current JFX codebase? >> >> >> >>> Richard >>> >>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>> >>>> +1 >>>> >>>> I think we've had this conversation before. Maybe something to do with >>> interfaces being too brittle where if you add a method anyone >> implementing >>> it will now be missing a method, whereas with a base class they can add a >>> stub method? >>>> >>>> Other frameworks use interfaces extensively though (eg Spring, >>> java.util.Collections), generally with positive outcomes. >>>> >>>> >>>> >>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>> wrote: >>>> >>>>> I have been struggling with a number of problems stemming from the way >>> JavaFX is designed ? specifically the lack of interfaces for many of the >>> extension points in the class hierarchy. >>>>> >>>>> It takes some thorough explaining with code examples, so instead of >>> just an unformatted e-mail I posted a more readable explanation of the >>> problem on-line: >>>>> Please read >>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>> >>>>> I hope we could have a constructive discussion on this matter on this >>> list before I go ahead and file a Jira, so the Jira issue becomes the >> best >>> possible basis for solving the design problem. >>>>> >>>>> Thanks >>>>> >>>>> Randahl >>> >>> >> From zonski at gmail.com Mon Nov 5 15:22:38 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Nov 2012 10:22:38 +1100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Also very, very interesting. This format looks quite easy to work with and as far as I can see would allow for Windows apps to be built on other platforms (e.g. Linux). We should in theory just be able to include the JRE in the bundle and then call javaw.exe via the manifest. No native building necessary, just a sort of "zipping". I'm still digging but I can't see a way to pass command line params, so specifying "javaw.exe -jar myapp.jar" via the AppxManifest.xml might be problematic. Hopefully there is something there for this, but it wouldn't surprise me if MS didn't support this on purpose. An alternative might be to have a custom launcher.exe that reads a bundled app-profile file and then launches java.exe as a new process with the appropriate details, or a modified JRE that does the same thing but without starting a new process. Not sure if we'll run into the same legal restrictions as Mac store though with OpenJDK and GPL (probably) so might have to limit it to whatever can be done with the Oracle JRE. Ensemble in the Windows store maybe? I don't have a windows 8 machine yet though. Do we know if JFX will need/benefit-from any changes to work on Win8 or will the current Win implementation be the same used on Win8 going forward? On Tue, Nov 6, 2012 at 9:32 AM, John Smith wrote: > > Is this what the new Windows Store uses as well? > > No, Windows Store does not use MSI, it uses appx files and Open Packaging > Conventions. > > There is no installer, updater or uninstaller for the package, just some > metadata which a store client can use to install, update or uninstall a > component. > appx is just like a zip file with a manifest, similar to a jar file. > > Those interested, can see here for info: > http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspxApp packages and deployment (Windows Store apps) > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspxApp packager (MakeAppx.exe) - kind of the Windows Store equivalent of > javafxpackager.exe > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspxPackaging, deployment, and query of Windows Store apps > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair > Sent: Monday, November 05, 2012 12:58 PM > To: Josh Marinacci > Cc: openjfx-dev at openjdk.java.net > Subject: Re: JFX build and deployment - squeaking wheel > > I'm not sure, to be honest. > > On Nov 3, 2012, at 11:08 AM, Josh Marinacci wrote: > > > Interesting. Is this what the new Windows Store uses as well? > > > > -- > > Josh Marinacci > > joshondesign.com > > > > On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote: > > > >> Right. MSI is sort of an official MicroSoft Installer format. The > >> .msi file is read by the built-in Windows installer APIs. Sort of > >> like how .pkg is handled natively by OS X, and .rpm and .deb are > >> handled natively by Linux distros. Exe installers could be anything, > >> they just aren't the same. though often they are special > >> bootstrappers tacked on to one or more MSI databases. MSI is a > >> table-based description of the stuff to install. (It isn't > >> particularly good mind you, it's just well supported by the Windows > >> OS.) > >> > >> Scott > >> > >> On 2012-11-03, at 12:10 PM, Joshua Marinacci > wrote: > >> > >>> Ah. So an MSI is not just another installer format? It has special > >>> properties make it different than NSIS? > >>> > >>> Most likely sent from Planet Earth > >>> > >>> On Nov 3, 2012, at 6:45 AM, Richard Bair > wrote: > >>> > >>>>> I just tried using the AppBundler (the other one from Java.net) to > create a Mac bundle with an embedded JRE and it worked pretty well. For > Windows is an MSI file a requirement or could some other installer system > work? I just found NSIS which can generate Windows installers from linux. > >>>> > >>>> The reason MSI is important is that for many large sites with IT > departments, they don't want to have to go around from machine to machine > manually installing software and, they don't trust users to be able to > download and install software themselves (either by policy or by some means > of enforcement). Giving the IT department an MSI allows them to remotely > push updates / software onto the correct users machines according to > whatever policies they've crafted in their business. Or remove the software > when the time comes. > >>>> > >>>> Richard > > > > From swpalmer at gmail.com Mon Nov 5 15:29:33 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 5 Nov 2012 18:29:33 -0500 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: On Mon, Nov 5, 2012 at 5:32 PM, John Smith wrote: > > Is this what the new Windows Store uses as well? > > No, Windows Store does not use MSI, it uses appx files and Open Packaging > Conventions. > > There is no installer, updater or uninstaller for the package, just some > metadata which a store client can use to install, update or uninstall a > component. > appx is just like a zip file with a manifest, similar to a jar file. > > Those interested, can see here for info: > http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspxApp packages and deployment (Windows Store apps) > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspxApp packager (MakeAppx.exe) - kind of the Windows Store equivalent of > javafxpackager.exe > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspxPackaging, deployment, and query of Windows Store apps > > Ah good, they basically copied Apple again. (I worry when they try to "innovate".) :-) So Windows now uses nearly the same format as Mac - an "embraced and extended" flavour the OS X "Application Bundle". It seems they are on track to keep their pace of remaining ten years behind the competition, but at least they are moving in the right direction. Okay, poking fun at Microsoft aside, this looks good as far as cross-platform creation of the .appx package is concerned. But's it's Windows 8 only, right? Scott From dbhole at redhat.com Mon Nov 5 19:44:34 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 5 Nov 2012 22:44:34 -0500 Subject: Contribution to OpenJFX Message-ID: <20121106034434.GB14271@redhat.com> Hi Everyone, My name is Deepak Bhole and I manage the OpenJDK group at Red Hat. It is very exciting to see OpenJFX get ever closer to a full drop! JavaFX technology holds a lot of promise and developing it in an open-source manner only makes it more so. We (Red Hat) would like to contribute to this project just like we contribute to OpenJDK. We would like to start by working with developers here to fix build, integration, etc. issues. Most of this work will also benefit other Linux distros, as we will be working on ensuring proper integration with Linux installations in general. Our subsequent areas of contribution will be defined by bugs and enhancement requests filed by users/the community as adoption increases. We look forward to working with everyone as more code becomes available! Cheers, Deepak From hang.vo at oracle.com Mon Nov 5 20:19:14 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 04:19:14 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121106041917.C32E7477A7@hg.openjdk.java.net> Changeset: 2eccad815147 Author: ptbrunet Date: 2012-11-05 22:00 -0600 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2eccad815147 clean up some logging ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleNode.java ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleStage.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleControl.java Changeset: 6a40a582b6fd Author: ptbrunet Date: 2012-11-05 22:01 -0600 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6a40a582b6fd merged From martin.sladecek at oracle.com Tue Nov 6 00:15:58 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 06 Nov 2012 09:15:58 +0100 Subject: API review: Conversion methods in Binding API In-Reply-To: <0BFCF167-7860-4F41-BC50-EA913883496D@oracle.com> References: <2979DA98-06DD-40C0-9685-57794B055883@oracle.com> <0BFCF167-7860-4F41-BC50-EA913883496D@oracle.com> Message-ID: <5098C73E.9060802@oracle.com> One request just came last Friday: http://javafx-jira.kenai.com/browse/RT-25996 ;-) -Martin On 11/02/2012 09:54 PM, Richard Bair wrote: > I haven't seen this as a request by developers yet, I tend to think we ought to keep this feature / tweak in our backlog and revisit if / when we see some demand from users? > > Richard > > On Sep 18, 2012, at 12:00 AM, Michael Heinrichs wrote: > >> Hi, >> >> there are sometimes situations, when a developer has a general typed value, but needs a specific type, e.g. a user may have an ObjectProperty but needs an ObservableIntegerValue. I want to add some conversion methods for these kind of cases. http://javafx-jira.kenai.com/browse/RT-19020 >> >> class BooleanExpression: >> public static BooleanExpression booleanExpression(ObservableValue) >> The current booleanExpression() method will be marked as deprecated and should be removed when we do an incompatible update of the JavaFX API. Same for the methods in DoubleExpression etc. >> >> class DoubleExpression: >> public static DoubleExpression doubleExpression(ObservableValue) >> >> class FloatExpression: >> public static FloatExpression floatExpression(ObservableValue) >> >> class IntegerExpression: >> public static IntegerExpression integerExpression(ObservableValue) >> >> class LongExpression: >> public static LongExpression longExpression(ObservableValue) >> >> class ObjectExpression: >> public BooleanBinding asBoolean() >> public DoubleBinding asDouble() >> public FloatBinding asFloat() >> public IntegerBinding asInteger() >> public LongBinding asLong() >> The bindings returned by these methods will return the default value, if the type of the wrapped Object does not match the expected. >> >> class Bindings: >> public static BooleanExpression convertToBoolean(ObservableValue) >> public static DoubleExpression convertToDouble(ObservableValue) >> public static FloatExpression convertToFloat(ObservableValue) >> public static IntegerExpression convertToInteger(ObservableValue) >> public static LongExpression convertToLong(ObservableValue) >> >> Thanks, >> Michael From Peter.Zhelezniakov at oracle.com Tue Nov 6 01:13:02 2012 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Tue, 06 Nov 2012 13:13:02 +0400 Subject: API request: Adding WebEngine.userAgent In-Reply-To: References: Message-ID: <5098D49E.4030006@oracle.com> Vasiliy Baranov wrote: > So, for WebEngine to send out the below system-dependent value, what > should be the value of the WebEngine.userAgent property? null? That > makes sense to me. It also makes sense for the WebEngine.userAgent > property to default to null then. This is magic I'd like to avoid. Most apps would set this property at most once and so would need no shortcut to the default value. So the value of the property would be the actual UA string at all times. The default value would be different on different platforms -- that seems fine to me. Application code would sometimes want to conditionalize on os.name -- that seems fine too. -- Peter From hang.vo at oracle.com Tue Nov 6 02:04:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 10:04:45 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121106100452.17D5D477AE@hg.openjdk.java.net> Changeset: 9d03e07c0278 Author: Martin Sladecek Date: 2012-11-06 10:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9d03e07c0278 RT-9383 Add proper constructors & factory methods to event classes, remove impl ! javafx-ui-common/src/com/sun/javafx/scene/EnteredExitedHandler.java ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/InputEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodTextRun.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.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/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/TransferMode.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/stage/WindowEvent.java ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/InputMethodEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/InputMethodTextRunTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyCodeTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyCombinationTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/RotateEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ScrollEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/SwipeEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ZoomEventTest.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 9b6c86c2e88f Author: Martin Sladecek Date: 2012-11-06 10:50 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b6c86c2e88f merge From tbee at tbee.org Tue Nov 6 03:13:02 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Nov 2012 12:13:02 +0100 Subject: out of memory Message-ID: <5098F0BE.6040207@tbee.org> A user of MigPane reported that he ran into a out of memory exception. http://migcalendar.com/forums/viewtopic.php?f=8&t=3916&p=8717#p8717 I've created a memory dump of this and using the memory analyser tool I only see that it is being held by weak references and the scene node. Class Name | Shallow Heap | Retained Heap ---------------------------------------------------------------------------------------------------------------- javafx.scene.control.Button @ 0x319ba2f8 | 408 | 1,672 - [60490] javafx.scene.Node[98113] @ 0x29cc8810 | 392,464 | 392,464 - dirtyNodes javafx.scene.Scene @ 0x27f65d00 | 376 | 396,728 |- this$0 javafx.scene.Scene$ScenePeerListener @ 0x28003d60 | 16 | 16 | - sceneListener com.sun.javafx.tk.quantum.ViewScene @ 0x27ffb710 | 64 | 168 | |- scene com.sun.javafx.tk.quantum.PrismPen @ 0x27ffc7f0 | 48 | 2,344 | | - pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 Native Stack | 72 | 480 | |- scene com.sun.javafx.tk.quantum.GlassViewEventHandler @ 0x27ffc820| 48 | 408 | |- scene com.sun.javafx.tk.quantum.WindowStage @ 0x27f694e8 | 88 | 184 | - Total: 3 entries | | |- this$0 javafx.scene.Scene$ScenePulseListener @ 0x27f6a300 | 16 | 16 |- oldScene, value javafx.scene.Node$4 @ 0x31121ca8 | 48 | 48 - Total: 3 entries | | ---------------------------------------------------------------------------------------------------------------- What is this dirtyNodes collection and when are nodes placed in it? Tom From martin.sladecek at oracle.com Tue Nov 6 04:14:51 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 06 Nov 2012 13:14:51 +0100 Subject: API Review: Use ObservableNumberValue as parameter for valueAt() methods In-Reply-To: References: <407D5289-53F2-43F0-90D2-24D6BD34647F@oracle.com> Message-ID: <5098FF3B.1050200@oracle.com> Yes, the (old) ObservableIntegerValue method would just directly call the new version with ObservableNumberValue (which is superclass of ObservableIntegerValue), so it would just create extra noise in the API. -Martin On 11/02/2012 09:52 PM, Richard Bair wrote: > The existing methods would continue to function though, is that right? They wouldn't need to be deprecated from a functional perspective (i.e.: they aren't totally broken), but they're just extra noise in the API? > > Richard > > On Sep 18, 2012, at 12:19 AM, Michael Heinrichs wrote: > >> Hi, >> >> currently the various valueAt() methods expect an ObservableIntegerValue for the index. (The valueAt() methods create a binding to request a specific element in an ObservableList.) This is wrong, the type should have been an ObservableNumberValue, because this fits to the general philosophy of the binding API. (In general the binding API tries to loosen the type system as much as possible without dropping the ability to use primitives internally.) >> >> I want to add new versions of the various valueAt() methods that expect ObservableNumberValue for the index. The current methods will be marked as deprecated and should be removed in a future incompatible update of the JavaFX API. >> >> Thanks, >> Michael From kevin.rushforth at oracle.com Tue Nov 6 04:36:18 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Nov 2012 04:36:18 -0800 Subject: out of memory In-Reply-To: <5098F0BE.6040207@tbee.org> References: <5098F0BE.6040207@tbee.org> Message-ID: <50990442.4010106@oracle.com> The dirty nodes collection is a list of nodes in a scene that have had their state modified. It is processed and cleared as part of the node synchronization step each pulse. -- Kevin Tom Eugelink wrote: > A user of MigPane reported that he ran into a out of memory exception. > > http://migcalendar.com/forums/viewtopic.php?f=8&t=3916&p=8717#p8717 > > I've created a memory dump of this and using the memory analyser tool > I only see that it is being held by weak references and the scene node. > > Class Name | Shallow Heap | Retained Heap > ---------------------------------------------------------------------------------------------------------------- > > javafx.scene.control.Button @ > 0x319ba2f8 | 408 > | 1,672 > - [60490] javafx.scene.Node[98113] @ > 0x29cc8810 | 392,464 | 392,464 > - dirtyNodes javafx.scene.Scene @ > 0x27f65d00 | 376 | 396,728 > |- this$0 javafx.scene.Scene$ScenePeerListener @ > 0x28003d60 | 16 | 16 > | - sceneListener com.sun.javafx.tk.quantum.ViewScene @ > 0x27ffb710 | 64 | 168 > | |- scene com.sun.javafx.tk.quantum.PrismPen @ > 0x27ffc7f0 | 48 | 2,344 > | | - pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 Native > Stack | 72 | 480 > | |- scene com.sun.javafx.tk.quantum.GlassViewEventHandler @ > 0x27ffc820| 48 | 408 > | |- scene com.sun.javafx.tk.quantum.WindowStage @ > 0x27f694e8 | 88 | 184 > | - Total: 3 entries | | > |- this$0 javafx.scene.Scene$ScenePulseListener @ > 0x27f6a300 | 16 | 16 > |- oldScene, value javafx.scene.Node$4 @ > 0x31121ca8 | 48 | 48 > - Total: 3 entries | | > ---------------------------------------------------------------------------------------------------------------- > > > What is this dirtyNodes collection and when are nodes placed in it? > > Tom > From tbee at tbee.org Tue Nov 6 04:40:20 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Nov 2012 13:40:20 +0100 Subject: out of memory In-Reply-To: <50990442.4010106@oracle.com> References: <5098F0BE.6040207@tbee.org> <50990442.4010106@oracle.com> Message-ID: <50990534.2080605@tbee.org> I figured as much, so these nodes still are part of the scene. They are not "to be removed", correct? Tom On 2012-11-06 13:36, Kevin Rushforth wrote: > The dirty nodes collection is a list of nodes in a scene that have had their state modified. It is processed and cleared as part of the node synchronization step each pulse. > > -- Kevin > > > Tom Eugelink wrote: >> A user of MigPane reported that he ran into a out of memory exception. >> >> http://migcalendar.com/forums/viewtopic.php?f=8&t=3916&p=8717#p8717 >> >> I've created a memory dump of this and using the memory analyser tool I only see that it is being held by weak references and the scene node. >> >> Class Name | Shallow Heap | Retained Heap >> ---------------------------------------------------------------------------------------------------------------- >> javafx.scene.control.Button @ 0x319ba2f8 | 408 | 1,672 >> - [60490] javafx.scene.Node[98113] @ 0x29cc8810 | 392,464 | 392,464 >> - dirtyNodes javafx.scene.Scene @ 0x27f65d00 | 376 | 396,728 >> |- this$0 javafx.scene.Scene$ScenePeerListener @ 0x28003d60 | 16 | 16 >> | - sceneListener com.sun.javafx.tk.quantum.ViewScene @ 0x27ffb710 | 64 | 168 >> | |- scene com.sun.javafx.tk.quantum.PrismPen @ 0x27ffc7f0 | 48 | 2,344 >> | | - pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 Native Stack | 72 | 480 >> | |- scene com.sun.javafx.tk.quantum.GlassViewEventHandler @ 0x27ffc820| 48 | 408 >> | |- scene com.sun.javafx.tk.quantum.WindowStage @ 0x27f694e8 | 88 | 184 >> | - Total: 3 entries | | >> |- this$0 javafx.scene.Scene$ScenePulseListener @ 0x27f6a300 | 16 | 16 >> |- oldScene, value javafx.scene.Node$4 @ 0x31121ca8 | 48 | 48 >> - Total: 3 entries | | >> ---------------------------------------------------------------------------------------------------------------- >> >> What is this dirtyNodes collection and when are nodes placed in it? >> >> Tom >> From kevin.rushforth at oracle.com Tue Nov 6 04:56:00 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Nov 2012 04:56:00 -0800 Subject: out of memory In-Reply-To: <50990534.2080605@tbee.org> References: <5098F0BE.6040207@tbee.org> <50990442.4010106@oracle.com> <50990534.2080605@tbee.org> Message-ID: <509908E0.4020300@oracle.com> Correct. One short-lived exception to that would be if a node was modified and then removed from the scene in the same frame. In this case it would exist in the dirty nodes list until the next synchronization pulse. -- Kevin Tom Eugelink wrote: > I figured as much, so these nodes still are part of the scene. They > are not "to be removed", correct? > > Tom > > > > On 2012-11-06 13:36, Kevin Rushforth wrote: >> The dirty nodes collection is a list of nodes in a scene that have >> had their state modified. It is processed and cleared as part of the >> node synchronization step each pulse. >> >> -- Kevin >> >> >> Tom Eugelink wrote: >>> A user of MigPane reported that he ran into a out of memory exception. >>> >>> http://migcalendar.com/forums/viewtopic.php?f=8&t=3916&p=8717#p8717 >>> >>> I've created a memory dump of this and using the memory analyser >>> tool I only see that it is being held by weak references and the >>> scene node. >>> >>> Class Name | Shallow Heap | Retained Heap >>> ---------------------------------------------------------------------------------------------------------------- >>> >>> javafx.scene.control.Button @ >>> 0x319ba2f8 | 408 | >>> 1,672 >>> - [60490] javafx.scene.Node[98113] @ >>> 0x29cc8810 | 392,464 | 392,464 >>> - dirtyNodes javafx.scene.Scene @ >>> 0x27f65d00 | 376 | 396,728 >>> |- this$0 javafx.scene.Scene$ScenePeerListener @ >>> 0x28003d60 | 16 | 16 >>> | - sceneListener com.sun.javafx.tk.quantum.ViewScene @ >>> 0x27ffb710 | 64 | 168 >>> | |- scene com.sun.javafx.tk.quantum.PrismPen @ >>> 0x27ffc7f0 | 48 | 2,344 >>> | | - pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 >>> Native Stack | 72 | 480 >>> | |- scene com.sun.javafx.tk.quantum.GlassViewEventHandler >>> @ 0x27ffc820| 48 | 408 >>> | |- scene com.sun.javafx.tk.quantum.WindowStage @ >>> 0x27f694e8 | 88 | 184 >>> | - Total: 3 entries | | >>> |- this$0 javafx.scene.Scene$ScenePulseListener @ >>> 0x27f6a300 | 16 | 16 >>> |- oldScene, value javafx.scene.Node$4 @ >>> 0x31121ca8 | 48 | 48 >>> - Total: 3 entries | | >>> ---------------------------------------------------------------------------------------------------------------- >>> >>> >>> What is this dirtyNodes collection and when are nodes placed in it? >>> >>> Tom >>> > From hang.vo at oracle.com Tue Nov 6 06:34:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 14:34:13 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121106143417.E4DE2477B5@hg.openjdk.java.net> Changeset: 9900811ad27b Author: Martin Sladecek Date: 2012-11-06 15:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9900811ad27b RT-23448 ParallelTransition/SequentialTransition: Change of rate during the animation play not working ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 944a3d7a6b33 Author: Martin Sladecek Date: 2012-11-06 15:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/944a3d7a6b33 merge From richard.bair at oracle.com Tue Nov 6 06:48:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 06:48:39 -0800 Subject: JavaFX and the Missing Interfaces In-Reply-To: <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> Message-ID: <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). Cheers Richard On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: > There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. > > Randahl > > > > > On Nov 5, 2012, at 21:41 , Mark Fortner wrote: > >> I guess the benefit of doing it this way is that it would make it easier to >> swap out implementations, and do unit testing/mocking. The downside if the >> API is changing frequently then every release is liable to break something. >> But that's why people have continuous integration servers. :-) >> >> Mark >> >> Cheers, >> >> Mark >> >> >> >> >> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >> >>>> Maybe somebody can show how this would work in more concrete terms? I >>>> don't even see how it would be practical at all. >>>> >>> >>> As in how it would be used by end developers and to what benefit, or as in >>> how to make it workable in the current JFX codebase? >>> >>> >>> >>>> Richard >>>> >>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>> >>>>> +1 >>>>> >>>>> I think we've had this conversation before. Maybe something to do with >>>> interfaces being too brittle where if you add a method anyone >>> implementing >>>> it will now be missing a method, whereas with a base class they can add a >>>> stub method? >>>>> >>>>> Other frameworks use interfaces extensively though (eg Spring, >>>> java.util.Collections), generally with positive outcomes. >>>>> >>>>> >>>>> >>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>> wrote: >>>>> >>>>>> I have been struggling with a number of problems stemming from the way >>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>> extension points in the class hierarchy. >>>>>> >>>>>> It takes some thorough explaining with code examples, so instead of >>>> just an unformatted e-mail I posted a more readable explanation of the >>>> problem on-line: >>>>>> Please read >>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>> >>>>>> I hope we could have a constructive discussion on this matter on this >>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>> best >>>> possible basis for solving the design problem. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Randahl >>>> >>>> >>> > From hang.vo at oracle.com Tue Nov 6 07:19:04 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 15:19:04 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121106151908.CEE69477B7@hg.openjdk.java.net> Changeset: b36815546648 Author: Martin Sladecek Date: 2012-11-06 16:11 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b36815546648 RT-25942 Incorrect behavior of Stage.resizableProperty().set() ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/test/unit/javafx/stage/StageTest.java Changeset: e13317e2a91f Author: Martin Sladecek Date: 2012-11-06 16:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e13317e2a91f merge From steve.x.northover at oracle.com Tue Nov 6 08:05:04 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 06 Nov 2012 11:05:04 -0500 Subject: Contribution to OpenJFX In-Reply-To: <20121106034434.GB14271@redhat.com> References: <20121106034434.GB14271@redhat.com> Message-ID: <50993530.9090102@oracle.com> Welcome Deepack, We are working hard to get our code open sourced and make the project more open. At the same time, we are also hard at work fixing problems and implementing new features so resources are split. Please bear with us as we work through the transition phase. In the meantime, the OpenJFX site (http://openjdk.java.net/projects/openjfx/) is somewhat out of date. The wiki https://wikis.oracle.com/display/OpenJDK/OpenJFX contains up to date build instructions and some design discussions about upcoming features in JFX. Once again ... welcome! Steve On 05/11/2012 10:44 PM, Deepak Bhole wrote: > Hi Everyone, > > My name is Deepak Bhole and I manage the OpenJDK group at Red Hat. > > It is very exciting to see OpenJFX get ever closer to a full drop! > > JavaFX technology holds a lot of promise and developing it in an open-source > manner only makes it more so. We (Red Hat) would like to contribute to this > project just like we contribute to OpenJDK. > > We would like to start by working with developers here to fix build, > integration, etc. issues. Most of this work will also benefit other Linux > distros, as we will be working on ensuring proper integration with Linux > installations in general. Our subsequent areas of contribution will be defined > by bugs and enhancement requests filed by users/the community as adoption > increases. > > We look forward to working with everyone as more code becomes available! > > Cheers, > Deepak From joshua at marinacci.org Tue Nov 6 08:22:57 2012 From: joshua at marinacci.org (Joshua Marinacci) Date: Tue, 6 Nov 2012 08:22:57 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <-6363722359811691682@unknownmsgid> Is the Windows Store restricted to only Metro apps written in WinRT or can desktop mode apps be included as well? -J Most likely sent from Planet Earth On Nov 5, 2012, at 3:29 PM, Scott Palmer wrote: On Mon, Nov 5, 2012 at 5:32 PM, John Smith wrote: > > Is this what the new Windows Store uses as well? > > No, Windows Store does not use MSI, it uses appx files and Open Packaging > Conventions. > > There is no installer, updater or uninstaller for the package, just some > metadata which a store client can use to install, update or uninstall a > component. > appx is just like a zip file with a manifest, similar to a jar file. > > Those interested, can see here for info: > http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspxApp packages and deployment (Windows Store apps) > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspxApp packager (MakeAppx.exe) - kind of the Windows Store equivalent of > javafxpackager.exe > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspxPackaging, deployment, and query of Windows Store apps > > Ah good, they basically copied Apple again. (I worry when they try to "innovate".) :-) So Windows now uses nearly the same format as Mac - an "embraced and extended" flavour the OS X "Application Bundle". It seems they are on track to keep their pace of remaining ten years behind the competition, but at least they are moving in the right direction. Okay, poking fun at Microsoft aside, this looks good as far as cross-platform creation of the .appx package is concerned. But's it's Windows 8 only, right? Scott From richard.bair at oracle.com Tue Nov 6 08:13:44 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 08:13:44 -0800 Subject: Open Sourcing: decora-compiler Message-ID: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> Hi, I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. Cheers Richard From richard.bair at oracle.com Tue Nov 6 08:38:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 08:38:15 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <173930CB-5CB0-48B3-B29D-19B439ABAD0C@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793A882@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <8D4267EB-9277-4D03-A856-586261BC01FE@oracle.com> > So (finally) understanding that my use case is a secondary one, I'm really > interested to know more about this Compact profile stuff for Java 8. I'm > assuming the Minimal Hotspot and compact profile will all run on a standard > desktop, i.e. there's nothing about it that will make it "embedded" > specific? I'm not sure. I've had a couple meetings about jrecreate but I'm not clear on exactly the boundary between it and javafxpackager, for example. javafxpackager (in Java 8) will allow for subsetting jfxrt.jar along some half-dozen to dozen modules (media, web, base, graphics, swing, swt, controls at a minimum). I know that jrecreate is being done by the embedded team rather than the SE team, so I'm not sure it will ship with standard SE. However for all intents on purposes I don't see why not. JavaSE Embedded is basically just a different variant of HotSpot for ARM and smaller-footprint devices (I'm sure there's more to it, but most of the platform is just standard SE). I will send an email to Bob and see if he can visit our mailing list with more information :-) > I'd love to know more about the "FX Embedded" project. Is this an actual > different implementation or just the FX code bundled up in a way that it > can be included as a JAR? It doesn't seem to be on any of the 3 compact > profiles so I am assuming there's a different approach for actually > including it - i.e. it's not a JRE command line thing like the rest of it? > Will we be able to run FX Embedded on the "compact JRE profile 1" on a > standard desktop or will it be specific to embedded hardware? If not will > be able to pull in FX regular and run it on profile 1 VMs? Can we leave out > things like charts and the web browser, etc, in order to make the JRE even > more lean (would it help?). javafxpackager will definitely allow for creating a subset of jfxrt.jar. The Embedded version of FX is basically just normal FX but with a different version of Glass on the bottom depending on the target. It is all being open sourced along with the rest of FX since it is just another Glass platform from our perspective. We've had to do some special shader work for embedded platforms like Raspberry PI, but I believe we're just folding those changes into the standard shaders so we have as little per-platform fragmentation as possible. > How can I get more info on this project, monitor it's progress and/or be > involved with early access, etc? Any and all links, tips, announcements and > resources would be of huge interest. Hopefully Bob will help clear up the scope of jrecreate. As for javafxpackager subsets, this will of course be done here. If jrecreate is part of SE, then it should all show up in the Java 8 builds (along with the right version of JavaFX 8 and javafxpackager). Another thing you should look at for making a smaller subset is ProGuard. Primarily it is an obfuscation tool, but if you don't have the jars using Pack200 (which is the case on embedded or iPad etc where CPU horsepower is not that plentiful) then obfuscation is generally a better way forward, and makes it harder for folks to decompile. > On a side note, I assume Oracle has noted the conversations on legal > problems with porting OpenJDK/OpenJFX to iOS? This compact JRE stuff opens > the door at a technical level to Android and iOS support but licencing > restrictions would still rule out iOS as I understand it. Yes, we have seen the discussion. Thanks! Richard From richard.bair at oracle.com Tue Nov 6 07:32:34 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 07:32:34 -0800 Subject: Contribution to OpenJFX In-Reply-To: <20121106034434.GB14271@redhat.com> References: <20121106034434.GB14271@redhat.com> Message-ID: <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> Hi Deepak, This is great news! I don't know if Mario / Roman or any other RedHat engineers working on this will be at Devoxx? I'm planning on spending most of Tuesday at the Devoxx Hackergarten working on upgrading the build. Also, we should have the javafx packager (which does the native application co-bundles) open sourced this week. Cheers! Richard On Nov 5, 2012, at 7:44 PM, Deepak Bhole wrote: > Hi Everyone, > > My name is Deepak Bhole and I manage the OpenJDK group at Red Hat. > > It is very exciting to see OpenJFX get ever closer to a full drop! > > JavaFX technology holds a lot of promise and developing it in an open-source > manner only makes it more so. We (Red Hat) would like to contribute to this > project just like we contribute to OpenJDK. > > We would like to start by working with developers here to fix build, > integration, etc. issues. Most of this work will also benefit other Linux > distros, as we will be working on ensuring proper integration with Linux > installations in general. Our subsequent areas of contribution will be defined > by bugs and enhancement requests filed by users/the community as adoption > increases. > > We look forward to working with everyone as more code becomes available! > > Cheers, > Deepak From richard.bair at oracle.com Tue Nov 6 07:39:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 07:39:15 -0800 Subject: API request: Adding WebEngine.userAgent In-Reply-To: <5098D49E.4030006@oracle.com> References: <5098D49E.4030006@oracle.com> Message-ID: <71FCFE7B-F4DF-4CAD-B00F-B1224A2BE322@oracle.com> > Vasiliy Baranov wrote: >> So, for WebEngine to send out the below system-dependent value, what >> should be the value of the WebEngine.userAgent property? null? That >> makes sense to me. It also makes sense for the WebEngine.userAgent >> property to default to null then. > > This is magic I'd like to avoid. Most apps would set this property at > most once and so would need no shortcut to the default value. > > So the value of the property would be the actual UA string at all times. > The default value would be different on different platforms -- that > seems fine to me. Application code would sometimes want to > conditionalize on os.name -- that seems fine too. I think that makes sense. We need to be sure to document that the UA string is different on different platforms. Ideally it would be easy to compute and parse? Richard From richard.bair at oracle.com Tue Nov 6 08:45:58 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 08:45:58 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: I agree that building app bundles from any platform for any other platform would be a huge win, as it would make it trivial for anybody to use. Some thoughts: - For DMG I thought it was basically an HFS formatted file? And I thought there were Java tools out there already for reading / writing to HFS. I doubt creating DMG's from any platform would be an insurmountable problem. - For .app, of course, this is pretty easy for us to do on any platform as it is just a specially named directory with various meta-data. - Sounds like appx isn't going to be too hard either - I am not sure about RPM and DEB, but I'd be shocked if those couldn't be produced from any arbitrary OS - WiX is probably going to be a bit of a pain in the neck. We can scope it down to make it less difficult, but writing a complete WiX parser / MSI producer is probably a big job and, I would guess, a moving target (if Microsoft is continuing to add features to it or support it, which I suspect is the case). - I don't have any knowledge on producing .exe files. Anybody? It seems to me that at least the Mac / Linux side of the problem should be fairly straightforward. Unless you have to sign your .app, in which case it might be a little more cumbersome. Also the giving of entitlements to a Mac application might be another problem area? On the windows side I have less experience with native windows installer technology so I'm not sure how practical it is to create exe files or .msi installers based on WiX? On Nov 5, 2012, at 3:22 PM, Daniel Zwolenski wrote: > Also very, very interesting. > > This format looks quite easy to work with and as far as I can see would allow for Windows apps to be built on other platforms (e.g. Linux). We should in theory just be able to include the JRE in the bundle and then call javaw.exe via the manifest. No native building necessary, just a sort of "zipping". > > I'm still digging but I can't see a way to pass command line params, so specifying "javaw.exe -jar myapp.jar" via the AppxManifest.xml might be problematic. Hopefully there is something there for this, but it wouldn't surprise me if MS didn't support this on purpose. > > An alternative might be to have a custom launcher.exe that reads a bundled app-profile file and then launches java.exe as a new process with the appropriate details, or a modified JRE that does the same thing but without starting a new process. Not sure if we'll run into the same legal restrictions as Mac store though with OpenJDK and GPL (probably) so might have to limit it to whatever can be done with the Oracle JRE. > > Ensemble in the Windows store maybe? I don't have a windows 8 machine yet though. > > Do we know if JFX will need/benefit-from any changes to work on Win8 or will the current Win implementation be the same used on Win8 going forward? > > > > > On Tue, Nov 6, 2012 at 9:32 AM, John Smith wrote: > > Is this what the new Windows Store uses as well? > > No, Windows Store does not use MSI, it uses appx files and Open Packaging Conventions. > > There is no installer, updater or uninstaller for the package, just some metadata which a store client can use to install, update or uninstall a component. > appx is just like a zip file with a manifest, similar to a jar file. > > Those interested, can see here for info: > http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspx App packages and deployment (Windows Store apps) > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspx App packager (MakeAppx.exe) - kind of the Windows Store equivalent of javafxpackager.exe > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspx Packaging, deployment, and query of Windows Store apps > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair > Sent: Monday, November 05, 2012 12:58 PM > To: Josh Marinacci > Cc: openjfx-dev at openjdk.java.net > Subject: Re: JFX build and deployment - squeaking wheel > > I'm not sure, to be honest. > > On Nov 3, 2012, at 11:08 AM, Josh Marinacci wrote: > > > Interesting. Is this what the new Windows Store uses as well? > > > > -- > > Josh Marinacci > > joshondesign.com > > > > On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote: > > > >> Right. MSI is sort of an official MicroSoft Installer format. The > >> .msi file is read by the built-in Windows installer APIs. Sort of > >> like how .pkg is handled natively by OS X, and .rpm and .deb are > >> handled natively by Linux distros. Exe installers could be anything, > >> they just aren't the same. though often they are special > >> bootstrappers tacked on to one or more MSI databases. MSI is a > >> table-based description of the stuff to install. (It isn't > >> particularly good mind you, it's just well supported by the Windows > >> OS.) > >> > >> Scott > >> > >> On 2012-11-03, at 12:10 PM, Joshua Marinacci wrote: > >> > >>> Ah. So an MSI is not just another installer format? It has special > >>> properties make it different than NSIS? > >>> > >>> Most likely sent from Planet Earth > >>> > >>> On Nov 3, 2012, at 6:45 AM, Richard Bair wrote: > >>> > >>>>> I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux. > >>>> > >>>> The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes. > >>>> > >>>> Richard > > > > From anthony.vanelverdinghe at gmail.com Tue Nov 6 09:36:32 2012 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Tue, 06 Nov 2012 18:36:32 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: Message-ID: <50994AA0.5040400@gmail.com> +1 Adding generics you 'd get: interface IControl { T getControl(); } Another option is to rewrite your method signatures from public Something fooBar(IControl control) {...} to public Something fooBar(T control) {...} So there are already solutions to the problem. In my opinion, interfaces like the ones proposed are neither necessary nor desired (as Richard already pointed out, they would unnecessarily clutter the API). Kind regards Anthony Op 5/11/2012 21:46, Pedro Duque Vieira schreef: > I've read your blog post. > > May I suggest doing: > > Interface IControl > { > Control getControlRepresentation(); > (...) > } > > This way you enforce every implementing class to have a Control > representation. And also as a plus you don't need to recur to casting when > you need to call methods from Control, because you can get a Control > representation via getControlRepresentation(). This is basically > composition instead of inheritance, which I think IMHO is better most of > the time. > > Also one more note, the methods of the API are final because of security > reasons. I guess Java is to blame for this. > > My 2cents, best regards, From phidias51 at gmail.com Tue Nov 6 09:41:47 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 6 Nov 2012 09:41:47 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Hi Richard, Maven already has mojos that package .app, .deb, and rpms: http://mojo.codehaus.org/osxappbundle-maven-plugin/ http://mojo.codehaus.org/deb-maven-plugin/ http://mojo.codehaus.org/rpm-maven-plugin/ Mark Cheers, Mark On Tue, Nov 6, 2012 at 8:45 AM, Richard Bair wrote: > I agree that building app bundles from any platform for any other platform > would be a huge win, as it would make it trivial for anybody to use. Some > thoughts: > > - For DMG I thought it was basically an HFS formatted file? And I > thought there were Java tools out there already for reading / writing to > HFS. I doubt creating DMG's from any platform would be an insurmountable > problem. > > - For .app, of course, this is pretty easy for us to do on any platform > as it is just a specially named directory with various meta-data. > > - Sounds like appx isn't going to be too hard either > > - I am not sure about RPM and DEB, but I'd be shocked if those couldn't > be produced from any arbitrary OS > > - WiX is probably going to be a bit of a pain in the neck. We can scope > it down to make it less difficult, but writing a complete WiX parser / MSI > producer is probably a big job and, I would guess, a moving target (if > Microsoft is continuing to add features to it or support it, which I > suspect is the case). > > - I don't have any knowledge on producing .exe files. Anybody? > > It seems to me that at least the Mac / Linux side of the problem should be > fairly straightforward. Unless you have to sign your .app, in which case it > might be a little more cumbersome. Also the giving of entitlements to a Mac > application might be another problem area? On the windows side I have less > experience with native windows installer technology so I'm not sure how > practical it is to create exe files or .msi installers based on WiX? > > On Nov 5, 2012, at 3:22 PM, Daniel Zwolenski wrote: > > > Also very, very interesting. > > > > This format looks quite easy to work with and as far as I can see would > allow for Windows apps to be built on other platforms (e.g. Linux). We > should in theory just be able to include the JRE in the bundle and then > call javaw.exe via the manifest. No native building necessary, just a sort > of "zipping". > > > > I'm still digging but I can't see a way to pass command line params, so > specifying "javaw.exe -jar myapp.jar" via the AppxManifest.xml might be > problematic. Hopefully there is something there for this, but it wouldn't > surprise me if MS didn't support this on purpose. > > > > An alternative might be to have a custom launcher.exe that reads a > bundled app-profile file and then launches java.exe as a new process with > the appropriate details, or a modified JRE that does the same thing but > without starting a new process. Not sure if we'll run into the same legal > restrictions as Mac store though with OpenJDK and GPL (probably) so might > have to limit it to whatever can be done with the Oracle JRE. > > > > Ensemble in the Windows store maybe? I don't have a windows 8 machine > yet though. > > > > Do we know if JFX will need/benefit-from any changes to work on Win8 or > will the current Win implementation be the same used on Win8 going forward? > > > > > > > > > > On Tue, Nov 6, 2012 at 9:32 AM, John Smith > wrote: > > > Is this what the new Windows Store uses as well? > > > > No, Windows Store does not use MSI, it uses appx files and Open > Packaging Conventions. > > > > There is no installer, updater or uninstaller for the package, just some > metadata which a store client can use to install, update or uninstall a > component. > > appx is just like a zip file with a manifest, similar to a jar file. > > > > Those interested, can see here for info: > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspxApp packages and deployment (Windows Store apps) > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspxApp packager (MakeAppx.exe) - kind of the Windows Store equivalent of > javafxpackager.exe > > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspxPackaging, deployment, and query of Windows Store apps > > > > -----Original Message----- > > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair > > Sent: Monday, November 05, 2012 12:58 PM > > To: Josh Marinacci > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: JFX build and deployment - squeaking wheel > > > > I'm not sure, to be honest. > > > > On Nov 3, 2012, at 11:08 AM, Josh Marinacci > wrote: > > > > > Interesting. Is this what the new Windows Store uses as well? > > > > > > -- > > > Josh Marinacci > > > joshondesign.com > > > > > > On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote: > > > > > >> Right. MSI is sort of an official MicroSoft Installer format. The > > >> .msi file is read by the built-in Windows installer APIs. Sort of > > >> like how .pkg is handled natively by OS X, and .rpm and .deb are > > >> handled natively by Linux distros. Exe installers could be anything, > > >> they just aren't the same. though often they are special > > >> bootstrappers tacked on to one or more MSI databases. MSI is a > > >> table-based description of the stuff to install. (It isn't > > >> particularly good mind you, it's just well supported by the Windows > > >> OS.) > > >> > > >> Scott > > >> > > >> On 2012-11-03, at 12:10 PM, Joshua Marinacci > wrote: > > >> > > >>> Ah. So an MSI is not just another installer format? It has special > > >>> properties make it different than NSIS? > > >>> > > >>> Most likely sent from Planet Earth > > >>> > > >>> On Nov 3, 2012, at 6:45 AM, Richard Bair > wrote: > > >>> > > >>>>> I just tried using the AppBundler (the other one from Java.net) to > create a Mac bundle with an embedded JRE and it worked pretty well. For > Windows is an MSI file a requirement or could some other installer system > work? I just found NSIS which can generate Windows installers from linux. > > >>>> > > >>>> The reason MSI is important is that for many large sites with IT > departments, they don't want to have to go around from machine to machine > manually installing software and, they don't trust users to be able to > download and install software themselves (either by policy or by some means > of enforcement). Giving the IT department an MSI allows them to remotely > push updates / software onto the correct users machines according to > whatever policies they've crafted in their business. Or remove the software > when the time comes. > > >>>> > > >>>> Richard > > > > > > > > > From hang.vo at oracle.com Tue Nov 6 09:49:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 17:49:37 +0000 Subject: hg: openjfx/8/graphics/rt: 9 new changesets Message-ID: <20121106174948.2BEBC477BC@hg.openjdk.java.net> Changeset: 8e85e840a981 Author: hudson Date: 2012-11-01 18:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8e85e840a981 Added tag 8.0-b63 for changeset 526513110eba ! .hgtags Changeset: d811a42d75ba Author: Paru Somashekar Date: 2012-10-18 12:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/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 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/graphics/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 Changeset: b0f305a2d89e Author: Paru Somashekar Date: 2012-10-25 15:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/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 Changeset: 29364c6d7434 Author: Paru Somashekar Date: 2012-10-26 16:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29364c6d7434 fix broken test failure for CategoryAxis. ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java Changeset: dbd6d178b5dd Author: leifs Date: 2012-10-29 12:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/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 Changeset: e901aef78ced Author: jgiles Date: 2012-10-31 01:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e901aef78ced Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 0f2f18efc353 Author: Paru Somashekar Date: 2012-11-05 22:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0f2f18efc353 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 365a3a5249c5 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-06 09:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/365a3a5249c5 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java From tom.schindl at bestsolution.at Tue Nov 6 10:05:38 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 06 Nov 2012 19:05:38 +0100 Subject: Open Sourcing: decora-compiler In-Reply-To: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> Message-ID: <50995172.1050203@bestsolution.at> That sounds interesting where will it endup? In which mercurial repo? Tom Am 06.11.12 17:13, schrieb Richard Bair: > Hi, > > I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. > > The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). > > decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. > > Cheers > 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 richard.bair at oracle.com Tue Nov 6 10:08:41 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 10:08:41 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: <50995172.1050203@bestsolution.at> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> Message-ID: It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: > That sounds interesting where will it endup? In which mercurial repo? > > Tom > > Am 06.11.12 17:13, schrieb Richard Bair: >> Hi, >> >> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >> >> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >> >> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >> >> Cheers >> 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 richard.bair at oracle.com Tue Nov 6 10:34:18 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Nov 2012 10:34:18 -0800 Subject: API review: Conversion methods in Binding API In-Reply-To: <5098C73E.9060802@oracle.com> References: <2979DA98-06DD-40C0-9685-57794B055883@oracle.com> <0BFCF167-7860-4F41-BC50-EA913883496D@oracle.com> <5098C73E.9060802@oracle.com> Message-ID: <1F99B381-BB7F-4A45-9ADE-2A338DBEEC11@oracle.com> Ha! Now we know what alias Michael is using in JIRA :-) Was there anything here that needed to be deprecated or these are all new methods? On Nov 6, 2012, at 12:15 AM, Martin Sladecek wrote: > One request just came last Friday: http://javafx-jira.kenai.com/browse/RT-25996 ;-) > > -Martin > > On 11/02/2012 09:54 PM, Richard Bair wrote: >> I haven't seen this as a request by developers yet, I tend to think we ought to keep this feature / tweak in our backlog and revisit if / when we see some demand from users? >> >> Richard >> >> On Sep 18, 2012, at 12:00 AM, Michael Heinrichs wrote: >> >>> Hi, >>> >>> there are sometimes situations, when a developer has a general typed value, but needs a specific type, e.g. a user may have an ObjectProperty but needs an ObservableIntegerValue. I want to add some conversion methods for these kind of cases. http://javafx-jira.kenai.com/browse/RT-19020 >>> >>> class BooleanExpression: >>> public static BooleanExpression booleanExpression(ObservableValue) >>> The current booleanExpression() method will be marked as deprecated and should be removed when we do an incompatible update of the JavaFX API. Same for the methods in DoubleExpression etc. >>> >>> class DoubleExpression: >>> public static DoubleExpression doubleExpression(ObservableValue) >>> >>> class FloatExpression: >>> public static FloatExpression floatExpression(ObservableValue) >>> >>> class IntegerExpression: >>> public static IntegerExpression integerExpression(ObservableValue) >>> >>> class LongExpression: >>> public static LongExpression longExpression(ObservableValue) >>> >>> class ObjectExpression: >>> public BooleanBinding asBoolean() >>> public DoubleBinding asDouble() >>> public FloatBinding asFloat() >>> public IntegerBinding asInteger() >>> public LongBinding asLong() >>> The bindings returned by these methods will return the default value, if the type of the wrapped Object does not match the expected. >>> >>> class Bindings: >>> public static BooleanExpression convertToBoolean(ObservableValue) >>> public static DoubleExpression convertToDouble(ObservableValue) >>> public static FloatExpression convertToFloat(ObservableValue) >>> public static IntegerExpression convertToInteger(ObservableValue) >>> public static LongExpression convertToLong(ObservableValue) >>> >>> Thanks, >>> Michael > From Joseph.Andresen at oracle.com Tue Nov 6 10:14:58 2012 From: Joseph.Andresen at oracle.com (Joe Andresen) Date: Tue, 06 Nov 2012 10:14:58 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: <50995172.1050203@bestsolution.at> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> Message-ID: <509953A2.1070005@oracle.com> Rich, You mean JSL as in Java Shader Language :P -Joe Tom Schindl wrote: > That sounds interesting where will it endup? In which mercurial repo? > > Tom > > Am 06.11.12 17:13, schrieb Richard Bair: > >> Hi, >> >> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >> >> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >> >> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >> >> Cheers >> Richard >> >> > > > From hang.vo at oracle.com Tue Nov 6 10:49:04 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 18:49:04 +0000 Subject: hg: openjfx/8/controls/rt: RT-138: Support component orientation in common UI controls Message-ID: <20121106184907.F0BB9477BD@hg.openjdk.java.net> Changeset: 36a55281a823 Author: leifs Date: 2012-11-06 10:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/36a55281a823 RT-138: Support component orientation in common UI controls ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java + javafx-ui-common/src/javafx/geometry/NodeOrientation.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CheckBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From tbee at tbee.org Tue Nov 6 10:49:17 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Nov 2012 19:49:17 +0100 Subject: out of memory In-Reply-To: <509908E0.4020300@oracle.com> References: <5098F0BE.6040207@tbee.org> <50990442.4010106@oracle.com> <50990534.2080605@tbee.org> <509908E0.4020300@oracle.com> Message-ID: <50995BAD.2090309@tbee.org> Ok, this is confusing; I've confirmed using lookup that the nodes are removed from the scene, however I end up with a dirtyNodes collection with over 23000 buttons and 15000 labels. Every 10 ms 30 buttons and 20 labels are added... So it actually takes quite some time for this to fill up and cause the out of memory exception. Tom On 2012-11-06 13:56, Kevin Rushforth wrote: > Correct. One short-lived exception to that would be if a node was modified and then removed from the scene in the same frame. In this case it would exist in the dirty nodes list until the next synchronization pulse. > > -- Kevin > > > Tom Eugelink wrote: >> I figured as much, so these nodes still are part of the scene. They are not "to be removed", correct? >> >> Tom >> >> >> >> On 2012-11-06 13:36, Kevin Rushforth wrote: >>> The dirty nodes collection is a list of nodes in a scene that have had their state modified. It is processed and cleared as part of the node synchronization step each pulse. >>> >>> -- Kevin >>> >>> >>> Tom Eugelink wrote: >>>> A user of MigPane reported that he ran into a out of memory exception. >>>> >>>> http://migcalendar.com/forums/viewtopic.php?f=8&t=3916&p=8717#p8717 >>>> >>>> I've created a memory dump of this and using the memory analyser tool I only see that it is being held by weak references and the scene node. >>>> >>>> Class Name | Shallow Heap | Retained Heap >>>> ---------------------------------------------------------------------------------------------------------------- >>>> javafx.scene.control.Button @ 0x319ba2f8 | 408 | 1,672 >>>> - [60490] javafx.scene.Node[98113] @ 0x29cc8810 | 392,464 | 392,464 >>>> - dirtyNodes javafx.scene.Scene @ 0x27f65d00 | 376 | 396,728 >>>> |- this$0 javafx.scene.Scene$ScenePeerListener @ 0x28003d60 | 16 | 16 >>>> | - sceneListener com.sun.javafx.tk.quantum.ViewScene @ 0x27ffb710 | 64 | 168 >>>> | |- scene com.sun.javafx.tk.quantum.PrismPen @ 0x27ffc7f0 | 48 | 2,344 >>>> | | - pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 Native Stack | 72 | 480 >>>> | |- scene com.sun.javafx.tk.quantum.GlassViewEventHandler @ 0x27ffc820| 48 | 408 >>>> | |- scene com.sun.javafx.tk.quantum.WindowStage @ 0x27f694e8 | 88 | 184 >>>> | - Total: 3 entries | | >>>> |- this$0 javafx.scene.Scene$ScenePulseListener @ 0x27f6a300 | 16 | 16 >>>> |- oldScene, value javafx.scene.Node$4 @ 0x31121ca8 | 48 | 48 >>>> - Total: 3 entries | | >>>> ---------------------------------------------------------------------------------------------------------------- >>>> >>>> What is this dirtyNodes collection and when are nodes placed in it? >>>> >>>> Tom >>>> >> From kevin.rushforth at oracle.com Tue Nov 6 11:04:53 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Nov 2012 11:04:53 -0800 Subject: out of memory In-Reply-To: <50995BAD.2090309@tbee.org> References: <5098F0BE.6040207@tbee.org> <50990442.4010106@oracle.com> <50990534.2080605@tbee.org> <509908E0.4020300@oracle.com> <50995BAD.2090309@tbee.org> Message-ID: <50995F55.9030904@oracle.com> Are frames being rendered during this time? If so, then you may have discovered a bug. If you have a test case you could file JIRA and attach it. -- Kevin Tom Eugelink wrote: > Ok, this is confusing; I've confirmed using lookup that the nodes are > removed from the scene, however I end up with a dirtyNodes collection > with over 23000 buttons and 15000 labels. > > Every 10 ms 30 buttons and 20 labels are added... So it actually takes > quite some time for this to fill up and cause the out of memory > exception. > > Tom > > > > On 2012-11-06 13:56, Kevin Rushforth wrote: >> Correct. One short-lived exception to that would be if a node was >> modified and then removed from the scene in the same frame. In this >> case it would exist in the dirty nodes list until the next >> synchronization pulse. >> >> -- Kevin >> >> >> Tom Eugelink wrote: >>> I figured as much, so these nodes still are part of the scene. They >>> are not "to be removed", correct? >>> >>> Tom >>> >>> >>> >>> On 2012-11-06 13:36, Kevin Rushforth wrote: >>>> The dirty nodes collection is a list of nodes in a scene that have >>>> had their state modified. It is processed and cleared as part of >>>> the node synchronization step each pulse. >>>> >>>> -- Kevin >>>> >>>> >>>> Tom Eugelink wrote: >>>>> A user of MigPane reported that he ran into a out of memory >>>>> exception. >>>>> >>>>> http://migcalendar.com/forums/viewtopic.php?f=8&t=3916&p=8717#p8717 >>>>> >>>>> I've created a memory dump of this and using the memory analyser >>>>> tool I only see that it is being held by weak references and the >>>>> scene node. >>>>> >>>>> Class Name | Shallow Heap | Retained Heap >>>>> ---------------------------------------------------------------------------------------------------------------- >>>>> >>>>> javafx.scene.control.Button @ >>>>> 0x319ba2f8 | 408 | >>>>> 1,672 >>>>> - [60490] javafx.scene.Node[98113] @ >>>>> 0x29cc8810 | 392,464 | 392,464 >>>>> - dirtyNodes javafx.scene.Scene @ >>>>> 0x27f65d00 | 376 | 396,728 >>>>> |- this$0 javafx.scene.Scene$ScenePeerListener @ >>>>> 0x28003d60 | 16 | 16 >>>>> | - sceneListener com.sun.javafx.tk.quantum.ViewScene @ >>>>> 0x27ffb710 | 64 | 168 >>>>> | |- scene com.sun.javafx.tk.quantum.PrismPen @ >>>>> 0x27ffc7f0 | 48 | 2,344 >>>>> | | - pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 >>>>> Native Stack | 72 | 480 >>>>> | |- scene >>>>> com.sun.javafx.tk.quantum.GlassViewEventHandler @ >>>>> 0x27ffc820| 48 | 408 >>>>> | |- scene com.sun.javafx.tk.quantum.WindowStage @ >>>>> 0x27f694e8 | 88 | 184 >>>>> | - Total: 3 entries | | >>>>> |- this$0 javafx.scene.Scene$ScenePulseListener @ >>>>> 0x27f6a300 | 16 | 16 >>>>> |- oldScene, value javafx.scene.Node$4 @ >>>>> 0x31121ca8 | 48 | 48 >>>>> - Total: 3 entries | | >>>>> ---------------------------------------------------------------------------------------------------------------- >>>>> >>>>> >>>>> What is this dirtyNodes collection and when are nodes placed in it? >>>>> >>>>> Tom >>>>> >>> > From Goddard at seznam.cz Tue Nov 6 11:53:47 2012 From: Goddard at seznam.cz (Jiri Prajzner) Date: Tue, 06 Nov 2012 20:53:47 +0100 (CET) Subject: Open Sourcing: decora-compiler References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509953A2.1070005@oracle.com> Message-ID: Hello, this is exciting! :) Regards, Jiri -- http://www.dredwerkz.cz +420 739 575 905 218 659 431 http://www.plurk.com/goddard ---------- P?vodn? zpr?va ---------- Od: Joe Andresen Datum: 6. 11. 2012 P?edm?t: Re: Open Sourcing: decora-compiler "Rich, You mean JSL as in Java Shader Language :P -Joe Tom Schindl wrote: > That sounds interesting where will it endup? In which mercurial repo? > > Tom > > Am 06.11.12 17:13, schrieb Richard Bair: > >> Hi, >> >> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >> >> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >> >> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >> >> Cheers >> Richard >> >> > > >" From tbee at tbee.org Tue Nov 6 12:31:14 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Nov 2012 21:31:14 +0100 Subject: out of memory In-Reply-To: <50995F55.9030904@oracle.com> References: <5098F0BE.6040207@tbee.org> <50990442.4010106@oracle.com> <50990534.2080605@tbee.org> <509908E0.4020300@oracle.com> <50995BAD.2090309@tbee.org> <50995F55.9030904@oracle.com> Message-ID: <50997392.1080607@tbee.org> Yes they are. I wish I could, but as soon as I drop MigPane and use FlowPane, the issue is gone. But I'm still not seeing a MigPane reference in the path to GC. Tom On 2012-11-06 20:04, Kevin Rushforth wrote: > Are frames being rendered during this time? If so, then you may have discovered a bug. If you have a test case you could file JIRA and attach it. > > -- Kevin From neugens at redhat.com Tue Nov 6 13:02:16 2012 From: neugens at redhat.com (Mario Torre) Date: Tue, 06 Nov 2012 22:02:16 +0100 Subject: Contribution to OpenJFX In-Reply-To: <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> Message-ID: <1352235736.4054.2.camel@pegasus> Il giorno mar, 06/11/2012 alle 07.32 -0800, Richard Bair ha scritto: > Hi Deepak, > > This is great news! I don't know if Mario / Roman or any other RedHat engineers working on this will be at Devoxx? I'm planning on spending most of Tuesday at the Devoxx Hackergarten working on upgrading the build. Also, we should have the javafx packager (which does the native application co-bundles) open sourced this week. > > Cheers! > Richard Hi Richard, Unfortunately we won't be at Devoxx but I've seen the discussion going on and is very welcomed news! I think the native packager is an interesting challenge to include in Linux distributions, indeed a very good starting point. Does it depend on other JavaFX code internally or is a standalone tool? Once we get back (we are in Toronto now) I'll write also some followup to sync about the actual status of the build refactoring (including the new build tool). Also, next week we should announce the official deadlines for the Fosdem call for papers, it would be greet if you would like submit a paper and join us there, too! Cheers, Mario From sven.reimers at gmail.com Tue Nov 6 13:39:17 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 6 Nov 2012 22:39:17 +0100 Subject: Assertion in FX8 (b63) Message-ID: Does this sound familiar to anyone? Shall I open a JIRA issue? Thanks Sven java.lang.AssertionError at javafx.scene.Node.impl_processCSS(Node.java:7486) at com.sun.javafx.scene.control.skin.TableColumnHeader.updateSortOrderDots(TableColumnHeader.java:477) at com.sun.javafx.scene.control.skin.TableColumnHeader.updateSortGrid(TableColumnHeader.java:454) at com.sun.javafx.scene.control.skin.TableColumnHeader.setSortPos(TableColumnHeader.java:384) at com.sun.javafx.scene.control.skin.TableColumnHeader.(TableColumnHeader.java:103) -- 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 david.grieve at oracle.com Tue Nov 6 14:07:11 2012 From: david.grieve at oracle.com (David Grieve) Date: Tue, 6 Nov 2012 17:07:11 -0500 Subject: Assertion in FX8 (b63) In-Reply-To: References: Message-ID: This assertion happens if the Node's scene is null. Here, since were coming from , the TableColumnHeader has not yet been added to scene. I think a JIRA issue should be filed. On Nov 6, 2012, at 4:39 PM, Sven Reimers wrote: > Does this sound familiar to anyone? Shall I open a JIRA issue? > > Thanks > > Sven > > java.lang.AssertionError > at javafx.scene.Node.impl_processCSS(Node.java:7486) > at > com.sun.javafx.scene.control.skin.TableColumnHeader.updateSortOrderDots(TableColumnHeader.java:477) > at > com.sun.javafx.scene.control.skin.TableColumnHeader.updateSortGrid(TableColumnHeader.java:454) > at > com.sun.javafx.scene.control.skin.TableColumnHeader.setSortPos(TableColumnHeader.java:384) > at > com.sun.javafx.scene.control.skin.TableColumnHeader.(TableColumnHeader.java:103) > > -- > 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 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 hang.vo at oracle.com Tue Nov 6 15:04:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 23:04:40 +0000 Subject: hg: openjfx/8/graphics/rt: Open source of decora-compiler Message-ID: <20121106230442.EECFA477CB@hg.openjdk.java.net> Changeset: f5e438202f2d Author: rbair Date: 2012-11-06 14:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f5e438202f2d Open source of decora-compiler + decora-compiler/.classpath + decora-compiler/.project + decora-compiler/build.xml + decora-compiler/nbproject/project.xml + decora-compiler/project.properties + decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g + decora-compiler/src/com/sun/scenario/effect/compiler/JSLC.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/ES2Backend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/GLSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/HLSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/SLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWCallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWTreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MECallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/METreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSECallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSETreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/BaseType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/BinaryOpType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/CoreSymbols.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/FuncImpl.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Function.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Param.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Precision.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Qualifier.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/SymbolTable.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Type.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/UnaryOpType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Variable.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ArrayAccessExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/BinaryExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/BreakStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/CallExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/CompoundStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ContinueStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DeclStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DiscardStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DoWhileStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Expr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ExprStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ExtDecl.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/FieldSelectExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ForStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/FuncDef.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/GlueBlock.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/LiteralExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ParenExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ProgramUnit.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ReturnStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/SelectStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Stmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Tree.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeMaker.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeVisitor.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/UnaryExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VarDecl.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VariableExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VectorCtorExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/WhileStmt.java + decora-compiler/test/com/sun/scenario/effect/compiler/SymbolTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/BoolTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/CommentTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/FloatTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/IdentifierTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/IntegerTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/LexerBase.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/LineCommentTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/TypeTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/WhitespaceTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/AddExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/AssignmentExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/EqualityExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/Expressions.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/ExternalDeclarationTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/FieldSelectTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/FullySpecifiedTypeTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/IterationStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/JumpStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/MultExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/ParserBase.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/PrimaryExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/RelationalExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/SelectionStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/UnaryExprTest.java From hang.vo at oracle.com Tue Nov 6 15:34:08 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Nov 2012 23:34:08 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-25899 & RT-21165 Message-ID: <20121106233411.0C66E477CC@hg.openjdk.java.net> Changeset: df9a24643d20 Author: Paru Somashekar Date: 2012-11-06 15:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/df9a24643d20 fix RT-25899 & RT-21165 ! javafx-ui-charts/src/javafx/scene/chart/BubbleChart.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java From John_Smith at symantec.com Tue Nov 6 15:53:52 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 6 Nov 2012 15:53:52 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <-6363722359811691682@unknownmsgid> References: <42A798B3-9C95-4952-853D-4BD28B05A4E0@oracle.com> <870A87F7-3ADD-4CE8-BA34-270A4ED88B93@oracle.com> <8202752180379267598@unknownmsgid> <1DCEAEBF-2D32-462C-864F-A06D6134E285@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160793AAA7@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <-6363722359811691682@unknownmsgid> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221607EB6447@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> ? Is the Windows Store restricted to only Metro apps written in WinRT or can desktop mode apps be included as well? You can submit both Metro "Modern UI" apps and traditional desktop mode apps to Windows Store. All apps submitted to the store are subject to certain submission requirements as detailed in: http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx There are special additional certification requirements for desktop mode apps: http://msdn.microsoft.com/en-us/library/windows/desktop/hh749939.aspx You can submit Windows 8 apps (i.e. x86/x64) in addition to Windows RT (ARM) apps to the windows store, see Fruit Ninja's Details tab for example: http://apps.microsoft.com/webpdp/en-us/app/fruit-ninja/eabfb4b0-cb66-471a-bcff-c48bbbb83ad4 Apps packaged like this can be installed outside of the Microsoft Windows Store using a process titled "side-loading": http://blogs.msdn.com/b/windowsstore/archive/2012/04/25/deploying-metro-style-apps-to-businesses.aspx Side-loading is primarily a way for enterprises to distribute apps to employees running Windows 8 x86, x64 or RT. ? Okay, poking fun at Microsoft aside, this looks good as far as cross-platform creation of the .appx package is concerned. But's it's Windows 8 only, right? Yep, yep, yep. From: Joshua Marinacci [mailto:joshua at marinacci.org] Sent: Tuesday, November 06, 2012 8:23 AM To: Scott Palmer Cc: John Smith; Richard Bair; openjfx-dev at openjdk.java.net Subject: Re: JFX build and deployment - squeaking wheel Is the Windows Store restricted to only Metro apps written in WinRT or can desktop mode apps be included as well? -J Most likely sent from Planet Earth On Nov 5, 2012, at 3:29 PM, Scott Palmer > wrote: On Mon, Nov 5, 2012 at 5:32 PM, John Smith > wrote: > Is this what the new Windows Store uses as well? No, Windows Store does not use MSI, it uses appx files and Open Packaging Conventions. There is no installer, updater or uninstaller for the package, just some metadata which a store client can use to install, update or uninstall a component. appx is just like a zip file with a manifest, similar to a jar file. Those interested, can see here for info: http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspx App packages and deployment (Windows Store apps) http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspx App packager (MakeAppx.exe) - kind of the Windows Store equivalent of javafxpackager.exe http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspx Packaging, deployment, and query of Windows Store apps Ah good, they basically copied Apple again. (I worry when they try to "innovate".) :-) So Windows now uses nearly the same format as Mac - an "embraced and extended" flavour the OS X "Application Bundle". It seems they are on track to keep their pace of remaining ten years behind the competition, but at least they are moving in the right direction. Okay, poking fun at Microsoft aside, this looks good as far as cross-platform creation of the .appx package is concerned. But's it's Windows 8 only, right? Scott From hang.vo at oracle.com Tue Nov 6 19:49:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Nov 2012 03:49:27 +0000 Subject: hg: openjfx/8/graphics/rt: RT-22493 WebView should use Toolkit for initialization Message-ID: <20121107034929.2AB6D477D7@hg.openjdk.java.net> Changeset: 7995eb685119 Author: peterz Date: 2012-11-07 07:33 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7995eb685119 RT-22493 WebView should use Toolkit for initialization ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubWebView.java From randahl at rockit.dk Wed Nov 7 03:02:12 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 7 Nov 2012 12:02:12 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> Message-ID: <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> Apologies Richard, I accidentally switched two words in my last mail which totally confused my point, so here is what I meant: We don't need Java 8 for this. With any version of Java you can create interfaces and helpful base classes which implement them, so people don't have to. What I would like to see is class Node ---- implements ----> interface SceneNode Since everyone always extend Node (directly or indirectly) you can evolve SceneNode with new methods without breaking anything, as long as the method is implemented by class Node, and thereby transitively by everyone else. I am aware that this is not important for JavaFX internally, but it is very important to me as a third party framework developer, because the SceneNode interface allows me to invent new kinds of nodes while still guaranteeing that they are in fact nodes, e.g. InternationalizedNode extends SceneNode { void somethingRelatedToI18n(); ... } Without the SceneNode interface, there is no way I can guarantee that an InternationalizedNode is indeed a real Node and not just a HashMap or a URL or what not. Today my framework works like this class SomeClass { public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { if(!(node instanceof Node)) throw TheNodeIsNotANodeException(); Node indeedANode = (Node) node; double width = node.getWidth(); } } If you added the SceneNode interface I could let InternationalizedNode extend the SceneNode interface and all of the code above could be replaced with class SomeClass { public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { double width = node.getWidth(); } } Cheers yourself Randahl On Nov 6, 2012, at 15:48 , Richard Bair wrote: > But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). > > Cheers > Richard > > On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: > >> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. >> >> Randahl >> >> >> >> >> On Nov 5, 2012, at 21:41 , Mark Fortner wrote: >> >>> I guess the benefit of doing it this way is that it would make it easier to >>> swap out implementations, and do unit testing/mocking. The downside if the >>> API is changing frequently then every release is liable to break something. >>> But that's why people have continuous integration servers. :-) >>> >>> Mark >>> >>> Cheers, >>> >>> Mark >>> >>> >>> >>> >>> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >>> >>>>> Maybe somebody can show how this would work in more concrete terms? I >>>>> don't even see how it would be practical at all. >>>>> >>>> >>>> As in how it would be used by end developers and to what benefit, or as in >>>> how to make it workable in the current JFX codebase? >>>> >>>> >>>> >>>>> Richard >>>>> >>>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> I think we've had this conversation before. Maybe something to do with >>>>> interfaces being too brittle where if you add a method anyone >>>> implementing >>>>> it will now be missing a method, whereas with a base class they can add a >>>>> stub method? >>>>>> >>>>>> Other frameworks use interfaces extensively though (eg Spring, >>>>> java.util.Collections), generally with positive outcomes. >>>>>> >>>>>> >>>>>> >>>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>>> wrote: >>>>>> >>>>>>> I have been struggling with a number of problems stemming from the way >>>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>>> extension points in the class hierarchy. >>>>>>> >>>>>>> It takes some thorough explaining with code examples, so instead of >>>>> just an unformatted e-mail I posted a more readable explanation of the >>>>> problem on-line: >>>>>>> Please read >>>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>>> >>>>>>> I hope we could have a constructive discussion on this matter on this >>>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>>> best >>>>> possible basis for solving the design problem. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Randahl >>>>> >>>>> >>>> >> > From randahl at rockit.dk Wed Nov 7 03:14:56 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 7 Nov 2012 12:14:56 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: <50994AA0.5040400@gmail.com> References: <50994AA0.5040400@gmail.com> Message-ID: <3B3B2FD2-3FAE-40E2-83CA-876D74E0CED1@rockit.dk> I think these are very nice suggestions. I had not thought about the idea. However, I would still prefer framework code like this public void doSomething(IControl control) { double width = control.getWidth(); } where IControl extends SceneNode, because it rids me from having to flood the whole framework with the T extends Control & IControl. It is an interesting work around. But a work around nonetheless. Randahl On Nov 6, 2012, at 18:36 , Anthony Vanelverdinghe wrote: > +1 > > Adding generics you 'd get: > interface IControl { > T getControl(); > } > > Another option is to rewrite your method signatures from > public Something fooBar(IControl control) {...} > to > public Something fooBar(T control) {...} > > So there are already solutions to the problem. In my opinion, interfaces like the ones proposed are neither necessary nor desired (as Richard already pointed out, they would unnecessarily clutter the API). > > Kind regards > Anthony > > Op 5/11/2012 21:46, Pedro Duque Vieira schreef: >> I've read your blog post. >> >> May I suggest doing: >> >> Interface IControl >> { >> Control getControlRepresentation(); >> (...) >> } >> >> This way you enforce every implementing class to have a Control >> representation. And also as a plus you don't need to recur to casting when >> you need to call methods from Control, because you can get a Control >> representation via getControlRepresentation(). This is basically >> composition instead of inheritance, which I think IMHO is better most of >> the time. >> >> Also one more note, the methods of the API are final because of security >> reasons. I guess Java is to blame for this. >> >> My 2cents, best regards, > From martin.sladecek at oracle.com Wed Nov 7 05:48:14 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Wed, 07 Nov 2012 14:48:14 +0100 Subject: API REVIEW: BaseObservableList In-Reply-To: <268F5B60-095B-43AF-AC27-CC47DEC73D9F@oracle.com> References: <4FEC12E3.3020708@oracle.com> <268F5B60-095B-43AF-AC27-CC47DEC73D9F@oracle.com> Message-ID: <509A669E.10304@oracle.com> Hi Richard, On 11/02/2012 06:49 PM, Richard Bair wrote: >> Following methods were part of IterableChangeBuilder in the original discussion. Now they will be part of BaseObservableList and can be used for creating a Change and firing it, so you don't need to create subclasses of ListChangeListener.Change yourself. >> >> protected final void nextUpdate(int pos) >> protected final void nextSet(int idx, E old) >> protected final void nextReplace(int from, int to, ArrayList removed) >> protected final void nextRemove(int idx, List removed) >> protected final void nextRemove(int idx, E removed) >> protected final void nextPermutation(int from, int to, int[] perm) >> protected final void nextAdd(int from, int to) >> protected final void endChange() >> protected final void beginChange() >> >> All next* methods need to be enclosed in beginChange() / endChange() pair. The calls can be also nested and after the outermost endChange() call, callListeners() will be called with the newly created Change. > It seems odd that these are on the base class itself. I don't remember the previous conversation so maybe I said something different before :-). Steve, I'm wondering what you think on this point? I don't think we discussed this before. The other option is to have this as part of ListChangeBuilder, which would be public (I planned to have it package private) and call the methods on the builder instead. So instead of { beginChange(); ... nextAdd(); ... endChange(); } we'd get getChangeBuilder().beginChange(); ... getChangeBuilder().nextAdd(); ... getChangeBuilder().endChange(); I have no strong opinion on this, the first one is more compact, but the second option keeps the change related methods together in a different class. -Martin From hang.vo at oracle.com Wed Nov 7 05:48:54 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Nov 2012 13:48:54 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26094 Event classes should have serialVersionUID Message-ID: <20121107134858.E860F477F1@hg.openjdk.java.net> Changeset: d3eeaeeb85bd Author: Martin Sladecek Date: 2012-11-07 14:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d3eeaeeb85bd RT-26094 Event classes should have serialVersionUID ! javafx-ui-common/src/com/sun/javafx/stage/FocusUngrabEvent.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/InputEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.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/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java ! javafx-ui-common/src/javafx/stage/WindowEvent.java From swpalmer at gmail.com Wed Nov 7 06:25:51 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 7 Nov 2012 09:25:51 -0500 Subject: JavaFX and the Missing Interfaces In-Reply-To: <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> Message-ID: On Wed, Nov 7, 2012 at 6:02 AM, Randahl Fink Isaksen wrote: > > class Node ---- implements ----> interface SceneNode > > Since everyone always extend Node (directly or indirectly) you can evolve > SceneNode with new methods without breaking anything, as long as the method > is implemented by class Node, and thereby transitively by everyone else. > Ahem... You wrote: InternationalizedNode extends SceneNode { void somethingRelatedToI18n(); ... } You have just gone against your own statement of "Since everyone always extend Node..." This has the original problem of causing your code to break if a new method is added to SceneNode. You would be tying your code to a particular version of JavaFX such that a user with a newer version won't be able to run your code. It works for maintaining consistency with internal classes of JavaFX, where the interface and the rest of the framework can be modified in lock-step with each other, but not for the use-case that you have described. If you don't inherit the SceneNode interface and just follow your own advice when implementing your InternationalizedNode you would have: class MyNode extends Node implements InternationalizedNode { void somethingRelatedToI18n() { ... } ... } Still guaranteeing that you have a real Node but without the need of the extra interface that just shoots you in the foot. Scott From tom.schindl at bestsolution.at Wed Nov 7 09:11:50 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 07 Nov 2012 18:11:50 +0100 Subject: Open Sourcing: decora-compiler In-Reply-To: References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> Message-ID: <509A9656.6060306@bestsolution.at> Hi, Ok - I cloned the graphic forest - to get my hands dirty on this are there any example DSL-Files, to do some monkey see monkey do? Tom Am 06.11.12 19:08, schrieb Richard Bair: > It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. > > On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: > >> That sounds interesting where will it endup? In which mercurial repo? >> >> Tom >> >> Am 06.11.12 17:13, schrieb Richard Bair: >>> Hi, >>> >>> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >>> >>> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >>> >>> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >>> >>> Cheers >>> 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 > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From Richard.Bair at oracle.com Wed Nov 7 07:51:10 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Wed, 7 Nov 2012 07:51:10 -0800 Subject: JavaFX and the Missing Interfaces In-Reply-To: <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> Message-ID: <1E3A640E-4847-4A0F-87A9-D336134FCA76@oracle.com> In my opinion the use case doesn't justify the additional complexity in API or guaranteed future API breakage. In particular, I am sure that the proposed solution would never past muster with the policies on compatibility with the JRE (it isn't enough to document that the only legitimate implementations of these interfaces are our own concrete node types). Java isn't know for its brevity, and since there is another way of enforcing your requirements, that is probably the best way to go. Thanks Richard On Nov 7, 2012, at 3:02 AM, Randahl Fink Isaksen wrote: > Apologies Richard, I accidentally switched two words in my last mail which totally confused my point, so here is what I meant: > > > We don't need Java 8 for this. With any version of Java you can create interfaces and helpful base classes which implement them, so people don't have to. What I would like to see is > > class Node ---- implements ----> interface SceneNode > > Since everyone always extend Node (directly or indirectly) you can evolve SceneNode with new methods without breaking anything, as long as the method is implemented by class Node, and thereby transitively by everyone else. > > I am aware that this is not important for JavaFX internally, but it is very important to me as a third party framework developer, because the SceneNode interface allows me to invent new kinds of nodes while still guaranteeing that they are in fact nodes, e.g. > > InternationalizedNode extends SceneNode { > void somethingRelatedToI18n(); > ... > } > > Without the SceneNode interface, there is no way I can guarantee that an InternationalizedNode is indeed a real Node and not just a HashMap or a URL or what not. > > Today my framework works like this > > class SomeClass { > public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { > if(!(node instanceof Node)) > throw TheNodeIsNotANodeException(); > Node indeedANode = (Node) node; > double width = node.getWidth(); > } > } > > If you added the SceneNode interface I could let InternationalizedNode extend the SceneNode interface and all of the code above could be replaced with > > class SomeClass { > public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { > double width = node.getWidth(); > } > } > > Cheers yourself > Randahl > > > On Nov 6, 2012, at 15:48 , Richard Bair wrote: > >> But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). >> >> Cheers >> Richard >> >> On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: >> >>> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. >>> >>> Randahl >>> >>> >>> >>> >>> On Nov 5, 2012, at 21:41 , Mark Fortner wrote: >>> >>>> I guess the benefit of doing it this way is that it would make it easier to >>>> swap out implementations, and do unit testing/mocking. The downside if the >>>> API is changing frequently then every release is liable to break something. >>>> But that's why people have continuous integration servers. :-) >>>> >>>> Mark >>>> >>>> Cheers, >>>> >>>> Mark >>>> >>>> >>>> >>>> >>>> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >>>> >>>>>> Maybe somebody can show how this would work in more concrete terms? I >>>>>> don't even see how it would be practical at all. >>>>>> >>>>> >>>>> As in how it would be used by end developers and to what benefit, or as in >>>>> how to make it workable in the current JFX codebase? >>>>> >>>>> >>>>> >>>>>> Richard >>>>>> >>>>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I think we've had this conversation before. Maybe something to do with >>>>>> interfaces being too brittle where if you add a method anyone >>>>> implementing >>>>>> it will now be missing a method, whereas with a base class they can add a >>>>>> stub method? >>>>>>> >>>>>>> Other frameworks use interfaces extensively though (eg Spring, >>>>>> java.util.Collections), generally with positive outcomes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>>>> wrote: >>>>>>> >>>>>>>> I have been struggling with a number of problems stemming from the way >>>>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>>>> extension points in the class hierarchy. >>>>>>>> >>>>>>>> It takes some thorough explaining with code examples, so instead of >>>>>> just an unformatted e-mail I posted a more readable explanation of the >>>>>> problem on-line: >>>>>>>> Please read >>>>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>>>> >>>>>>>> I hope we could have a constructive discussion on this matter on this >>>>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>>>> best >>>>>> possible basis for solving the design problem. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Randahl >>>>>> >>>>>> >>>>> >>> >> > From randahl at rockit.dk Wed Nov 7 09:23:53 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 7 Nov 2012 18:23:53 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: <1E3A640E-4847-4A0F-87A9-D336134FCA76@oracle.com> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> <1E3A640E-4847-4A0F-87A9-D336134FCA76@oracle.com> Message-ID: <12827B3B-D26A-4B64-9523-6F7BACC8314F@rockit.dk> Fair enough. Thanks for taking your time to review my suggestion. Randahl On Nov 7, 2012, at 16:51 , Richard Bair wrote: > In my opinion the use case doesn't justify the additional complexity in API or guaranteed future API breakage. In particular, I am sure that the proposed solution would never past muster with the policies on compatibility with the JRE (it isn't enough to document that the only legitimate implementations of these interfaces are our own concrete node types). Java isn't know for its brevity, and since there is another way of enforcing your requirements, that is probably the best way to go. > > Thanks > Richard > > On Nov 7, 2012, at 3:02 AM, Randahl Fink Isaksen wrote: > >> Apologies Richard, I accidentally switched two words in my last mail which totally confused my point, so here is what I meant: >> >> >> We don't need Java 8 for this. With any version of Java you can create interfaces and helpful base classes which implement them, so people don't have to. What I would like to see is >> >> class Node ---- implements ----> interface SceneNode >> >> Since everyone always extend Node (directly or indirectly) you can evolve SceneNode with new methods without breaking anything, as long as the method is implemented by class Node, and thereby transitively by everyone else. >> >> I am aware that this is not important for JavaFX internally, but it is very important to me as a third party framework developer, because the SceneNode interface allows me to invent new kinds of nodes while still guaranteeing that they are in fact nodes, e.g. >> >> InternationalizedNode extends SceneNode { >> void somethingRelatedToI18n(); >> ... >> } >> >> Without the SceneNode interface, there is no way I can guarantee that an InternationalizedNode is indeed a real Node and not just a HashMap or a URL or what not. >> >> Today my framework works like this >> >> class SomeClass { >> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >> if(!(node instanceof Node)) >> throw TheNodeIsNotANodeException(); >> Node indeedANode = (Node) node; >> double width = node.getWidth(); >> } >> } >> >> If you added the SceneNode interface I could let InternationalizedNode extend the SceneNode interface and all of the code above could be replaced with >> >> class SomeClass { >> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >> double width = node.getWidth(); >> } >> } >> >> Cheers yourself >> Randahl >> >> >> On Nov 6, 2012, at 15:48 , Richard Bair wrote: >> >>> But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). >>> >>> Cheers >>> Richard >>> >>> On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: >>> >>>> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. >>>> >>>> Randahl >>>> >>>> >>>> >>>> >>>> On Nov 5, 2012, at 21:41 , Mark Fortner wrote: >>>> >>>>> I guess the benefit of doing it this way is that it would make it easier to >>>>> swap out implementations, and do unit testing/mocking. The downside if the >>>>> API is changing frequently then every release is liable to break something. >>>>> But that's why people have continuous integration servers. :-) >>>>> >>>>> Mark >>>>> >>>>> Cheers, >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >>>>> >>>>>>> Maybe somebody can show how this would work in more concrete terms? I >>>>>>> don't even see how it would be practical at all. >>>>>>> >>>>>> >>>>>> As in how it would be used by end developers and to what benefit, or as in >>>>>> how to make it workable in the current JFX codebase? >>>>>> >>>>>> >>>>>> >>>>>>> Richard >>>>>>> >>>>>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> I think we've had this conversation before. Maybe something to do with >>>>>>> interfaces being too brittle where if you add a method anyone >>>>>> implementing >>>>>>> it will now be missing a method, whereas with a base class they can add a >>>>>>> stub method? >>>>>>>> >>>>>>>> Other frameworks use interfaces extensively though (eg Spring, >>>>>>> java.util.Collections), generally with positive outcomes. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>>>>> wrote: >>>>>>>> >>>>>>>>> I have been struggling with a number of problems stemming from the way >>>>>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>>>>> extension points in the class hierarchy. >>>>>>>>> >>>>>>>>> It takes some thorough explaining with code examples, so instead of >>>>>>> just an unformatted e-mail I posted a more readable explanation of the >>>>>>> problem on-line: >>>>>>>>> Please read >>>>>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>>>>> >>>>>>>>> I hope we could have a constructive discussion on this matter on this >>>>>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>>>>> best >>>>>>> possible basis for solving the design problem. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Randahl >>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From richard.bair at oracle.com Wed Nov 7 09:28:32 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 7 Nov 2012 09:28:32 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: <509A9656.6060306@bestsolution.at> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> Message-ID: Unfortunately not yet, they're in the parts that have yet to be open sourced. On Nov 7, 2012, at 9:11 AM, Tom Schindl wrote: > Hi, > > Ok - I cloned the graphic forest - to get my hands dirty on this are > there any example DSL-Files, to do some monkey see monkey do? > > Tom > > Am 06.11.12 19:08, schrieb Richard Bair: >> It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. >> >> On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: >> >>> That sounds interesting where will it endup? In which mercurial repo? >>> >>> Tom >>> >>> Am 06.11.12 17:13, schrieb Richard Bair: >>>> Hi, >>>> >>>> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >>>> >>>> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >>>> >>>> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >>>> >>>> Cheers >>>> 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 >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From Richard.Bair at oracle.com Wed Nov 7 09:29:24 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Wed, 7 Nov 2012 09:29:24 -0800 Subject: JavaFX and the Missing Interfaces In-Reply-To: <12827B3B-D26A-4B64-9523-6F7BACC8314F@rockit.dk> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> <1E3A640E-4847-4A0F-87A9-D336134FCA76@oracle.com> <12827B3B-D26A-4B64-9523-6F7BACC8314F@rockit.dk> Message-ID: I appreciate you asking it! On Nov 7, 2012, at 9:23 AM, Randahl Fink Isaksen wrote: > Fair enough. > > Thanks for taking your time to review my suggestion. > > Randahl > > > On Nov 7, 2012, at 16:51 , Richard Bair wrote: > >> In my opinion the use case doesn't justify the additional complexity in API or guaranteed future API breakage. In particular, I am sure that the proposed solution would never past muster with the policies on compatibility with the JRE (it isn't enough to document that the only legitimate implementations of these interfaces are our own concrete node types). Java isn't know for its brevity, and since there is another way of enforcing your requirements, that is probably the best way to go. >> >> Thanks >> Richard >> >> On Nov 7, 2012, at 3:02 AM, Randahl Fink Isaksen wrote: >> >>> Apologies Richard, I accidentally switched two words in my last mail which totally confused my point, so here is what I meant: >>> >>> >>> We don't need Java 8 for this. With any version of Java you can create interfaces and helpful base classes which implement them, so people don't have to. What I would like to see is >>> >>> class Node ---- implements ----> interface SceneNode >>> >>> Since everyone always extend Node (directly or indirectly) you can evolve SceneNode with new methods without breaking anything, as long as the method is implemented by class Node, and thereby transitively by everyone else. >>> >>> I am aware that this is not important for JavaFX internally, but it is very important to me as a third party framework developer, because the SceneNode interface allows me to invent new kinds of nodes while still guaranteeing that they are in fact nodes, e.g. >>> >>> InternationalizedNode extends SceneNode { >>> void somethingRelatedToI18n(); >>> ... >>> } >>> >>> Without the SceneNode interface, there is no way I can guarantee that an InternationalizedNode is indeed a real Node and not just a HashMap or a URL or what not. >>> >>> Today my framework works like this >>> >>> class SomeClass { >>> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >>> if(!(node instanceof Node)) >>> throw TheNodeIsNotANodeException(); >>> Node indeedANode = (Node) node; >>> double width = node.getWidth(); >>> } >>> } >>> >>> If you added the SceneNode interface I could let InternationalizedNode extend the SceneNode interface and all of the code above could be replaced with >>> >>> class SomeClass { >>> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >>> double width = node.getWidth(); >>> } >>> } >>> >>> Cheers yourself >>> Randahl >>> >>> >>> On Nov 6, 2012, at 15:48 , Richard Bair wrote: >>> >>>> But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). >>>> >>>> Cheers >>>> Richard >>>> >>>> On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: >>>> >>>>> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. >>>>> >>>>> Randahl >>>>> >>>>> >>>>> >>>>> >>>>> On Nov 5, 2012, at 21:41 , Mark Fortner wrote: >>>>> >>>>>> I guess the benefit of doing it this way is that it would make it easier to >>>>>> swap out implementations, and do unit testing/mocking. The downside if the >>>>>> API is changing frequently then every release is liable to break something. >>>>>> But that's why people have continuous integration servers. :-) >>>>>> >>>>>> Mark >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >>>>>> >>>>>>>> Maybe somebody can show how this would work in more concrete terms? I >>>>>>>> don't even see how it would be practical at all. >>>>>>>> >>>>>>> >>>>>>> As in how it would be used by end developers and to what benefit, or as in >>>>>>> how to make it workable in the current JFX codebase? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Richard >>>>>>>> >>>>>>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> I think we've had this conversation before. Maybe something to do with >>>>>>>> interfaces being too brittle where if you add a method anyone >>>>>>> implementing >>>>>>>> it will now be missing a method, whereas with a base class they can add a >>>>>>>> stub method? >>>>>>>>> >>>>>>>>> Other frameworks use interfaces extensively though (eg Spring, >>>>>>>> java.util.Collections), generally with positive outcomes. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I have been struggling with a number of problems stemming from the way >>>>>>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>>>>>> extension points in the class hierarchy. >>>>>>>>>> >>>>>>>>>> It takes some thorough explaining with code examples, so instead of >>>>>>>> just an unformatted e-mail I posted a more readable explanation of the >>>>>>>> problem on-line: >>>>>>>>>> Please read >>>>>>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>>>>>> >>>>>>>>>> I hope we could have a constructive discussion on this matter on this >>>>>>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>>>>>> best >>>>>>>> possible basis for solving the design problem. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Randahl >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From joseph.andresen at oracle.com Wed Nov 7 10:33:36 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Wed, 07 Nov 2012 10:33:36 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> Message-ID: <509AA980.90002@oracle.com> Just to avoid confusion here are some names. Decora - An effects framework used by JavaFX. decora-compiler - Name of the project we are open sourcing. JSL - Name of the shader language in the decora-compiler project (ie. Java Shader Language). JSL is implemented using ANTLR... the jsl.g file contains the rules. Also note that JSL is not a full implementation of a shader language (haven't had a dire need for it). We don't have support for some of the shader semantics like BINORMAL[n] and NORMAL[n] (the vertex shader specific ones). -Joe PS... DSL in Rich's email stood for "Domain Specific Language", not a typo... but it confused me :). On 11/6/2012 8:13 AM, Richard Bair wrote: > Hi, > > I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. > > The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). > > decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. > > Cheers > Richard From zonski at gmail.com Wed Nov 7 12:19:18 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 8 Nov 2012 07:19:18 +1100 Subject: JavaFX and the Missing Interfaces In-Reply-To: <12827B3B-D26A-4B64-9523-6F7BACC8314F@rockit.dk> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> <1E3A640E-4847-4A0F-87A9-D336134FCA76@oracle.com> <12827B3B-D26A-4B64-9523-6F7BACC8314F@rockit.dk> Message-ID: <3D611852-DA69-410E-BAF9-C87CDB01AC2E@gmail.com> Hi Randahl, I agree with your idea and would prefer if jfx followed your design. There's no doubts it would make for a much nicer code on the developers end in many situations (such as the example you gave). I think the big difference between JFX and a normal third party library that we're used to (ie that we bundle into our app as a jar) is that jfx is built in to the JRE. As such it has a lot more restrictions and caveats around it. Decisions around changing jfx are going to be as constrained as those to change the collections API, etc. Touch nothing, break nothing. Once something is in the JFX codebase I think we will be largely stuck with it (or at least it will be very hard/slow to change). It's different to a normal library like, say, Hibernate or Struts, where they can just say "version 3 has some incompatibilities with 2, sorry. Here's the steps to upgrade your code when you're ready". Applets are a great example, essentially dead but Richard is stuck supporting them for the next 10 years. Swing was the same and this was one reason why we saw so little improvements to Swing at the API level over the last 13 years. Jfx will likely have to be just as slow and cautious to evolve (Project Jigsaw may allow some loosening here, but it's hard to say). So in this context, while I totally agree with you, I think that unfortunately Richard has the right of it and being painfully over defensive in this area is a necessary evil, even at the cost of making a less elegant and versatile system to use. The class hierarchy restricts us as developers but gives Richard just a tiny bit of room to make changes/enhancements without breaking running code out there. It's the cost of being part of the JRE. Not sure if that helps you at all but I've had a lot of frustration around stuff like this with jfx and it took me a long while to get where Richard was coming from. Sometimes it's just good to hear that essentially your proposal was a good one with a lot of merit, etc, and it's just the unusual context that rules it out. For my money, in this case, your proposal is exactly that. On 08/11/2012, at 4:23 AM, Randahl Fink Isaksen wrote: > Fair enough. > > Thanks for taking your time to review my suggestion. > > Randahl > > > On Nov 7, 2012, at 16:51 , Richard Bair wrote: > >> In my opinion the use case doesn't justify the additional complexity in API or guaranteed future API breakage. In particular, I am sure that the proposed solution would never past muster with the policies on compatibility with the JRE (it isn't enough to document that the only legitimate implementations of these interfaces are our own concrete node types). Java isn't know for its brevity, and since there is another way of enforcing your requirements, that is probably the best way to go. >> >> Thanks >> Richard >> >> On Nov 7, 2012, at 3:02 AM, Randahl Fink Isaksen wrote: >> >>> Apologies Richard, I accidentally switched two words in my last mail which totally confused my point, so here is what I meant: >>> >>> >>> We don't need Java 8 for this. With any version of Java you can create interfaces and helpful base classes which implement them, so people don't have to. What I would like to see is >>> >>> class Node ---- implements ----> interface SceneNode >>> >>> Since everyone always extend Node (directly or indirectly) you can evolve SceneNode with new methods without breaking anything, as long as the method is implemented by class Node, and thereby transitively by everyone else. >>> >>> I am aware that this is not important for JavaFX internally, but it is very important to me as a third party framework developer, because the SceneNode interface allows me to invent new kinds of nodes while still guaranteeing that they are in fact nodes, e.g. >>> >>> InternationalizedNode extends SceneNode { >>> void somethingRelatedToI18n(); >>> ... >>> } >>> >>> Without the SceneNode interface, there is no way I can guarantee that an InternationalizedNode is indeed a real Node and not just a HashMap or a URL or what not. >>> >>> Today my framework works like this >>> >>> class SomeClass { >>> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >>> if(!(node instanceof Node)) >>> throw TheNodeIsNotANodeException(); >>> Node indeedANode = (Node) node; >>> double width = node.getWidth(); >>> } >>> } >>> >>> If you added the SceneNode interface I could let InternationalizedNode extend the SceneNode interface and all of the code above could be replaced with >>> >>> class SomeClass { >>> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >>> double width = node.getWidth(); >>> } >>> } >>> >>> Cheers yourself >>> Randahl >>> >>> >>> On Nov 6, 2012, at 15:48 , Richard Bair wrote: >>> >>>> But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). >>>> >>>> Cheers >>>> Richard >>>> >>>> On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: >>>> >>>>> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. >>>>> >>>>> Randahl >>>>> >>>>> >>>>> >>>>> >>>>> On Nov 5, 2012, at 21:41 , Mark Fortner wrote: >>>>> >>>>>> I guess the benefit of doing it this way is that it would make it easier to >>>>>> swap out implementations, and do unit testing/mocking. The downside if the >>>>>> API is changing frequently then every release is liable to break something. >>>>>> But that's why people have continuous integration servers. :-) >>>>>> >>>>>> Mark >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >>>>>> >>>>>>>> Maybe somebody can show how this would work in more concrete terms? I >>>>>>>> don't even see how it would be practical at all. >>>>>>>> >>>>>>> >>>>>>> As in how it would be used by end developers and to what benefit, or as in >>>>>>> how to make it workable in the current JFX codebase? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Richard >>>>>>>> >>>>>>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> I think we've had this conversation before. Maybe something to do with >>>>>>>> interfaces being too brittle where if you add a method anyone >>>>>>> implementing >>>>>>>> it will now be missing a method, whereas with a base class they can add a >>>>>>>> stub method? >>>>>>>>> >>>>>>>>> Other frameworks use interfaces extensively though (eg Spring, >>>>>>>> java.util.Collections), generally with positive outcomes. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I have been struggling with a number of problems stemming from the way >>>>>>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>>>>>> extension points in the class hierarchy. >>>>>>>>>> >>>>>>>>>> It takes some thorough explaining with code examples, so instead of >>>>>>>> just an unformatted e-mail I posted a more readable explanation of the >>>>>>>> problem on-line: >>>>>>>>>> Please read >>>>>>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>>>>>> >>>>>>>>>> I hope we could have a constructive discussion on this matter on this >>>>>>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>>>>>> best >>>>>>>> possible basis for solving the design problem. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Randahl >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From randahl at rockit.dk Wed Nov 7 13:27:53 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 7 Nov 2012 22:27:53 +0100 Subject: JavaFX and the Missing Interfaces In-Reply-To: <3D611852-DA69-410E-BAF9-C87CDB01AC2E@gmail.com> References: <1F392DF2-9300-415F-AC3C-D3EAFBC586CF@oracle.com> <4A060388-11CF-4501-A1E0-463B5986F3C4@rockit.dk> <04FBE534-A2BE-4AC6-B86C-BB74C8B8DAA8@oracle.com> <2D595D30-6709-45AA-903B-831F4CED7D08@rockit.dk> <1E3A640E-4847-4A0F-87A9-D336134FCA76@oracle.com> <12827B3B-D26A-4B64-9523-6F7BACC8314F@rockit.dk> <3D611852-DA69-410E-BAF9-C87CDB01AC2E@gmail.com> Message-ID: <13591C74-0C4C-4B1B-BCF5-90DEF20B83A6@rockit.dk> Thanks, Daniel. Well said. R. On Nov 7, 2012, at 21:19 , Daniel Zwolenski wrote: > Hi Randahl, > > I agree with your idea and would prefer if jfx followed your design. There's no doubts it would make for a much nicer code on the developers end in many situations (such as the example you gave). > > I think the big difference between JFX and a normal third party library that we're used to (ie that we bundle into our app as a jar) is that jfx is built in to the JRE. As such it has a lot more restrictions and caveats around it. Decisions around changing jfx are going to be as constrained as those to change the collections API, etc. Touch nothing, break nothing. > > Once something is in the JFX codebase I think we will be largely stuck with it (or at least it will be very hard/slow to change). It's different to a normal library like, say, Hibernate or Struts, where they can just say "version 3 has some incompatibilities with 2, sorry. Here's the steps to upgrade your code when you're ready". Applets are a great example, essentially dead but Richard is stuck supporting them for the next 10 years. > > Swing was the same and this was one reason why we saw so little improvements to Swing at the API level over the last 13 years. Jfx will likely have to be just as slow and cautious to evolve (Project Jigsaw may allow some loosening here, but it's hard to say). > > So in this context, while I totally agree with you, I think that unfortunately Richard has the right of it and being painfully over defensive in this area is a necessary evil, even at the cost of making a less elegant and versatile system to use. The class hierarchy restricts us as developers but gives Richard just a tiny bit of room to make changes/enhancements without breaking running code out there. It's the cost of being part of the JRE. > > Not sure if that helps you at all but I've had a lot of frustration around stuff like this with jfx and it took me a long while to get where Richard was coming from. Sometimes it's just good to hear that essentially your proposal was a good one with a lot of merit, etc, and it's just the unusual context that rules it out. For my money, in this case, your proposal is exactly that. > > > > > > On 08/11/2012, at 4:23 AM, Randahl Fink Isaksen wrote: > >> Fair enough. >> >> Thanks for taking your time to review my suggestion. >> >> Randahl >> >> >> On Nov 7, 2012, at 16:51 , Richard Bair wrote: >> >>> In my opinion the use case doesn't justify the additional complexity in API or guaranteed future API breakage. In particular, I am sure that the proposed solution would never past muster with the policies on compatibility with the JRE (it isn't enough to document that the only legitimate implementations of these interfaces are our own concrete node types). Java isn't know for its brevity, and since there is another way of enforcing your requirements, that is probably the best way to go. >>> >>> Thanks >>> Richard >>> >>> On Nov 7, 2012, at 3:02 AM, Randahl Fink Isaksen wrote: >>> >>>> Apologies Richard, I accidentally switched two words in my last mail which totally confused my point, so here is what I meant: >>>> >>>> >>>> We don't need Java 8 for this. With any version of Java you can create interfaces and helpful base classes which implement them, so people don't have to. What I would like to see is >>>> >>>> class Node ---- implements ----> interface SceneNode >>>> >>>> Since everyone always extend Node (directly or indirectly) you can evolve SceneNode with new methods without breaking anything, as long as the method is implemented by class Node, and thereby transitively by everyone else. >>>> >>>> I am aware that this is not important for JavaFX internally, but it is very important to me as a third party framework developer, because the SceneNode interface allows me to invent new kinds of nodes while still guaranteeing that they are in fact nodes, e.g. >>>> >>>> InternationalizedNode extends SceneNode { >>>> void somethingRelatedToI18n(); >>>> ... >>>> } >>>> >>>> Without the SceneNode interface, there is no way I can guarantee that an InternationalizedNode is indeed a real Node and not just a HashMap or a URL or what not. >>>> >>>> Today my framework works like this >>>> >>>> class SomeClass { >>>> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >>>> if(!(node instanceof Node)) >>>> throw TheNodeIsNotANodeException(); >>>> Node indeedANode = (Node) node; >>>> double width = node.getWidth(); >>>> } >>>> } >>>> >>>> If you added the SceneNode interface I could let InternationalizedNode extend the SceneNode interface and all of the code above could be replaced with >>>> >>>> class SomeClass { >>>> public void doSomethingWithAnInternationalizedNode(InternationalizedNode node) { >>>> double width = node.getWidth(); >>>> } >>>> } >>>> >>>> Cheers yourself >>>> Randahl >>>> >>>> >>>> On Nov 6, 2012, at 15:48 , Richard Bair wrote: >>>> >>>>> But that approach would only be feasible in Java 8. Default methods really only work well though if the new method requires no state or can be a no-op by default (because the default method is static). For other types of methods you may add, you will break compatibility. I don't see the advantage to having interfaces cluttering up the namespace if in reality nearly everybody is just going to extend from Node anyway (which they'd have to, because Parent returns Nodes not SceneNodes, and that couldn't be changed). >>>>> >>>>> Cheers >>>>> Richard >>>>> >>>>> On Nov 5, 2012, at 2:54 PM, Randahl Fink Isaksen wrote: >>>>> >>>>>> There is a solution to the problem of breaking compatibility when introducing new methods to an interface. That's what the default implementation is for. If you have class Node implement interface SceneNode, then it is my bet that virtually everyone will be extending Node when implementing SceneNode rather than starting from scratch. So you can add method x() to Node while adding an overridable default implementation of x() in SceneNode, and virtually no one will notice. You could even document that extending Node is a prerequisite fore ensured forwards compatibility for an application, and the burden would be off your shoulders. >>>>>> >>>>>> Randahl >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Nov 5, 2012, at 21:41 , Mark Fortner wrote: >>>>>> >>>>>>> I guess the benefit of doing it this way is that it would make it easier to >>>>>>> swap out implementations, and do unit testing/mocking. The downside if the >>>>>>> API is changing frequently then every release is liable to break something. >>>>>>> But that's why people have continuous integration servers. :-) >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 5, 2012 at 12:33 PM, Daniel Zwolenski wrote: >>>>>>> >>>>>>>>> Maybe somebody can show how this would work in more concrete terms? I >>>>>>>>> don't even see how it would be practical at all. >>>>>>>>> >>>>>>>> >>>>>>>> As in how it would be used by end developers and to what benefit, or as in >>>>>>>> how to make it workable in the current JFX codebase? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> On Nov 5, 2012, at 12:20 PM, Daniel Zwolenski wrote: >>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> I think we've had this conversation before. Maybe something to do with >>>>>>>>> interfaces being too brittle where if you add a method anyone >>>>>>>> implementing >>>>>>>>> it will now be missing a method, whereas with a base class they can add a >>>>>>>>> stub method? >>>>>>>>>> >>>>>>>>>> Other frameworks use interfaces extensively though (eg Spring, >>>>>>>>> java.util.Collections), generally with positive outcomes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06/11/2012, at 5:50 AM, Randahl Fink Isaksen >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I have been struggling with a number of problems stemming from the way >>>>>>>>> JavaFX is designed ? specifically the lack of interfaces for many of the >>>>>>>>> extension points in the class hierarchy. >>>>>>>>>>> >>>>>>>>>>> It takes some thorough explaining with code examples, so instead of >>>>>>>>> just an unformatted e-mail I posted a more readable explanation of the >>>>>>>>> problem on-line: >>>>>>>>>>> Please read >>>>>>>>> http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html >>>>>>>>>>> >>>>>>>>>>> I hope we could have a constructive discussion on this matter on this >>>>>>>>> list before I go ahead and file a Jira, so the Jira issue becomes the >>>>>>>> best >>>>>>>>> possible basis for solving the design problem. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Randahl >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From hang.vo at oracle.com Wed Nov 7 21:48:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Nov 2012 05:48:11 +0000 Subject: hg: openjfx/8/graphics/rt: [ECLIPSE ONLY] fixing classpath due changes in decora Message-ID: <20121108054815.EF2CB4783E@hg.openjdk.java.net> Changeset: 7e871632dfe4 Author: Felipe Heidrich Date: 2012-11-07 21:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7e871632dfe4 [ECLIPSE ONLY] fixing classpath due changes in decora ! .classpath From felipe.heidrich at oracle.com Wed Nov 7 22:21:22 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Wed, 7 Nov 2012 22:21:22 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: <509A9656.6060306@bestsolution.at> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> Message-ID: Hi Tom, Out of curiosity, Are you planning on adding JSL editor to e(fx)clipse ? I think that would be really cool. Provided that we already have the DSL grammar file for ANTR it should not be too much trouble to pass it to xText (i hope). Joe/Rich: would we be able to get Tom a couple of JSL example files to get him going ? Cheers Felipe On Nov 7, 2012, at 9:11 AM, Tom Schindl wrote: > Hi, > > Ok - I cloned the graphic forest - to get my hands dirty on this are > there any example DSL-Files, to do some monkey see monkey do? > > Tom > > Am 06.11.12 19:08, schrieb Richard Bair: >> It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. >> >> On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: >> >>> That sounds interesting where will it endup? In which mercurial repo? >>> >>> Tom >>> >>> Am 06.11.12 17:13, schrieb Richard Bair: >>>> Hi, >>>> >>>> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >>>> >>>> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >>>> >>>> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >>>> >>>> Cheers >>>> 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 >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Thu Nov 8 01:45:37 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Nov 2012 10:45:37 +0100 Subject: Open Sourcing: decora-compiler In-Reply-To: References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> Message-ID: <509B7F41.10205@bestsolution.at> [Resending because the first one is queued because I attached a screenshot] Hi, You got me I fact I don't only plan I've written one already yesterday - see http://tomsondev.bestsolution.at/2012/11/08/javafx-shader-language-jsl-or-writing-an-editor-for-a-language-you-dont-know/! It's a very dumb one yet but it could be improved, although I have to say this is very low priority in the complete e(fx)clipse project. Tom Am 08.11.12 07:21, schrieb Felipe Heidrich: > Hi Tom, > > > Out of curiosity, > > Are you planning on adding JSL editor to e(fx)clipse ? > > I think that would be really cool. Provided that we already have the DSL grammar file for ANTR it should not be too much trouble to pass it to xText (i hope). > > Joe/Rich: would we be able to get Tom a couple of JSL example files to get him going ? > > Cheers > Felipe > > > On Nov 7, 2012, at 9:11 AM, Tom Schindl wrote: > >> Hi, >> >> Ok - I cloned the graphic forest - to get my hands dirty on this are >> there any example DSL-Files, to do some monkey see monkey do? >> >> Tom >> >> Am 06.11.12 19:08, schrieb Richard Bair: >>> It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. >>> >>> On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: >>> >>>> That sounds interesting where will it endup? In which mercurial repo? >>>> >>>> Tom >>>> >>>> Am 06.11.12 17:13, schrieb Richard Bair: >>>>> Hi, >>>>> >>>>> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >>>>> >>>>> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >>>>> >>>>> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >>>>> >>>>> Cheers >>>>> 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 >>> >> >> >> -- >> 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 Goddard at seznam.cz Thu Nov 8 02:33:23 2012 From: Goddard at seznam.cz (Jiri Prajzner) Date: Thu, 08 Nov 2012 11:33:23 +0100 (CET) Subject: Open Sourcing: decora-compiler References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> <509B7F41.10205@bestsolution.at> Message-ID: Any chance NetBeans folks will catch up on this? :) Regards, Jiri -- http://www.dredwerkz.cz +420 739 575 905 218 659 431 http://www.plurk.com/goddard ---------- P?vodn? zpr?va ---------- Od: Tom Schindl Datum: 8. 11. 2012 P?edm?t: Re: Open Sourcing: decora-compiler "[Resending because the first one is queued because I attached a screenshot] Hi, You got me I fact I don't only plan I've written one already yesterday - see http://tomsondev.bestsolution.at/2012/11/08/javafx-shader-language-jsl-or- writing-an-editor-for-a-language-you-dont-know/ (http://tomsondev.bestsolution.at/2012/11/08/javafx-shader-language-jsl-or-writing-an-editor-for-a-language-you-dont-know/) ! It's a very dumb one yet but it could be improved, although I have to say this is very low priority in the complete e(fx)clipse project. Tom Am 08.11.12 07:21, schrieb Felipe Heidrich: > Hi Tom, > > > Out of curiosity, > > Are you planning on adding JSL editor to e(fx)clipse ? > > I think that would be really cool. Provided that we already have the DSL grammar file for ANTR it should not be too much trouble to pass it to xText (i hope). > > Joe/Rich: would we be able to get Tom a couple of JSL example files to get him going ? > > Cheers > Felipe > > > On Nov 7, 2012, at 9:11 AM, Tom Schindl wrote: > >> Hi, >> >> Ok - I cloned the graphic forest - to get my hands dirty on this are >> there any example DSL-Files, to do some monkey see monkey do? >> >> Tom >> >> Am 06.11.12 19:08, schrieb Richard Bair: >>> It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. >>> >>> On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: >>> >>>> That sounds interesting where will it endup? In which mercurial repo? >>>> >>>> Tom >>>> >>>> Am 06.11.12 17:13, schrieb Richard Bair: >>>>> Hi, >>>>> >>>>> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >>>>> >>>>> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >>>>> >>>>> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >>>>> >>>>> Cheers >>>>> 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(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(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(http://www.BestSolution.at) phone ++43 512 935834 " From pavel.safrata at oracle.com Thu Nov 8 03:42:59 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 08 Nov 2012 12:42:59 +0100 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> Message-ID: <509B9AC3.8030308@oracle.com> Hello, shame on me, I'm really sorry for getting here so late. I've just read through the proposal and I'd like to propose several changes before it starts to be used by apps. > DragEvent: > public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, Dragboard dragboard) > public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, TransferMode transferMode, EventType eventType) > I think we should not complicate the API with those two methods. They have no obvious usage for users and I think all existing internal usages can be removed by a simple refactoring. > MouseEvent: > public MouseEvent(EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger) I would drop this one, there is a similar one with one more argument: stillSincePress. This argument is not that special, we can use the other method instead. There are places in robot where we're not sure what to put there, but it doesn't really justify for having this duplicated method (it should rather be fixed there). > TouchEvent: > public boolean isDirect() // was impl_ because (according to a comment in code) there are no indirect events yet, but GestureEvent already has this public. I think we should not publish isDirect() and that we should remove the "direct" argument from constructors. Currently touch events are always direct. We are able to produce indirect touch events from TrackPad, but our API specifically states that we don't and won't deliver them. They are just prepared for the possibility that we add custom gesture recognizers in the future that may work with those indirect events, but it is not really certain we'll ever do that, and if we will, it is not certain if it will be allowed to feed custom events to them. So publishing this useless flag would be pretty confusing right now. Finally, to make TouchEvent constructor usable, we need also constructor for TouchPoint. Let me once more apologize for the late response. Thaks, Pavel > > > -Martin > > On 06/15/2012 11:44 PM, Richard Bair wrote: >>>>> As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated). >>>> And what do you think about impl_copy methods? Personally I think we should remove them completely and turn them to some internal utility methods. >>> My initial thought was a copy constructor. >>> >>>> Also, some events are not 100% immutable, as they are modified during the Scene processing through some impl_methods, like MouseEvent.impl_setClickParam. We'd either need to make some/all of the Event fields protected and do this modifications through subclasses or create some "accessor" in javafx.scene.input package for calling these methods from javafx.scene package. >>> Good question, I guess we can revisit these in context of the other impl_ method removal things we're working on. >>> >>> Richard From jasper.potts at oracle.com Thu Nov 8 05:35:29 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Thu, 8 Nov 2012 13:35:29 +0000 Subject: JavaFX and the Missing Interfaces In-Reply-To: References: Message-ID: This is a hard problem as interfaces have some nice properties but they have one huge problem when it comes to building a API that needs to grow over time. That is you can never add a new method to a interface without breaking backwards compatibility with every class that has implemented that interface. So if Node was a interface we could not add any new methods needed to implement 3D in FX 8 or any other new feature. The only way is to add Node2, .... NodeN interfaces which gets ugly and unmanageable very quickly. There is a partial solution in Java 8 with default methods but it only solves a limited set of problems and was not available when we designed the core JavaFX API. So when stuck between a rock and hard place with no perfect answer we had to weigh our options make a decision and live with it. Otherwise we would be stuck for ever debating the pros and cons of these fundamental design decisions. This is one of those cases and although there are times as a app developer it has annoyed me, I still think we made the right decision. It has never prevented me from doing anything I have just had to solve my app problem in a different way. Jasper Sent from my iPad On Nov 5, 2012, at 6:50 PM, Randahl Fink Isaksen wrote: > I have been struggling with a number of problems stemming from the way JavaFX is designed ? specifically the lack of interfaces for many of the extension points in the class hierarchy. > > It takes some thorough explaining with code examples, so instead of just an unformatted e-mail I posted a more readable explanation of the problem on-line: > Please read http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html > > I hope we could have a constructive discussion on this matter on this list before I go ahead and file a Jira, so the Jira issue becomes the best possible basis for solving the design problem. > > Thanks > > Randahl From felipe.heidrich at oracle.com Thu Nov 8 08:43:44 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Thu, 8 Nov 2012 08:43:44 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: <509B7F41.10205@bestsolution.at> References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> <509B7F41.10205@bestsolution.at> Message-ID: One hour to implement an editor ? Awesome! I've filed http://efxclipse.org/trac/ticket/225 to help track the progress in this one. Thanks ps.: in that initial work already includes content assist ? On Nov 8, 2012, at 1:45 AM, Tom Schindl wrote: > [Resending because the first one is queued because I attached a screenshot] > > Hi, > > You got me I fact I don't only plan I've written one already > yesterday - see > http://tomsondev.bestsolution.at/2012/11/08/javafx-shader-language-jsl-or-writing-an-editor-for-a-language-you-dont-know/! > > It's a very dumb one yet but it could be improved, although I have to > say this is very low priority in the complete e(fx)clipse project. > > Tom > > Am 08.11.12 07:21, schrieb Felipe Heidrich: >> Hi Tom, >> >> >> Out of curiosity, >> >> Are you planning on adding JSL editor to e(fx)clipse ? >> >> I think that would be really cool. Provided that we already have the DSL grammar file for ANTR it should not be too much trouble to pass it to xText (i hope). >> >> Joe/Rich: would we be able to get Tom a couple of JSL example files to get him going ? >> >> Cheers >> Felipe >> >> >> On Nov 7, 2012, at 9:11 AM, Tom Schindl wrote: >> >>> Hi, >>> >>> Ok - I cloned the graphic forest - to get my hands dirty on this are >>> there any example DSL-Files, to do some monkey see monkey do? >>> >>> Tom >>> >>> Am 06.11.12 19:08, schrieb Richard Bair: >>>> It will be in "rt". It will start out in the graphics forest but by next week it will have propagated through the rest of them. >>>> >>>> On Nov 6, 2012, at 10:05 AM, Tom Schindl wrote: >>>> >>>>> That sounds interesting where will it endup? In which mercurial repo? >>>>> >>>>> Tom >>>>> >>>>> Am 06.11.12 17:13, schrieb Richard Bair: >>>>>> Hi, >>>>>> >>>>>> I'm going to be open sourcing today another one of our projects called decora-compiler. We have our own DSL for shader languages called Decora. What we do is generate shaders for OpenGL and D3D from this language. We also generate Java code and SSE native code. For some shaders, we ended up generating them and then hand-tweaking them from there. >>>>>> >>>>>> The decora-compiler is used during the build process, but is not itself part of either the JDK or JRE, and so has mostly remained invisible to everybody. There is an "ME" based backend for JavaME which I don't think is even being used anymore, so there is stuff here we could remove to reduce the size of the project (and I will be filing a JIRA for this). >>>>>> >>>>>> decora-compiler isn't really that interesting in isolation, although at one time we had entertained the idea of popularizing it so that people could write their own shaders with JSL (the decora shader language), in which case the compiler would be part of the JDK such that you could create your own effects. Decora is predominantly used for the "effects" -- blur, box blur, etc. Although it is also used for prism shaders, we don't generate SSE or Java backends for those, and many of these have been tweaked by hand vs. simply generated. >>>>>> >>>>>> Cheers >>>>>> 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 >>>> >>> >>> >>> -- >>> 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 tom.schindl at bestsolution.at Thu Nov 8 11:32:11 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Nov 2012 20:32:11 +0100 Subject: Open Sourcing: decora-compiler In-Reply-To: References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> <509B7F41.10205@bestsolution.at> Message-ID: <509C08BB.8070407@bestsolution.at> Am 08.11.12 17:43, schrieb Felipe Heidrich: > > One hour to implement an editor ? Awesome! In fact i only had to paste the ANTLR-Grammer from JSL.g to my xtext-File and let the generator generate the editor. > > I've filed http://efxclipse.org/trac/ticket/225 to help track the progress in this one. > Good. Like stated this is low priority compared to the rest of e(fx)clipse sub-components, people joining and working on that are certainly welcome! A very low hanging fruite would be to attach the decora-compiler code to the editor and generate the source files in the background. > > Thanks > > ps.: in that initial work already includes content assist ? > No but we have an AST and at least syntactical error reporting and syntax highlighting. Next would be to work a bit on the grammer so that the AST is not getting so endlessly big (you see the enormous AST generated in the Outline View on the right) and add references in the grammer which makes scoping and content assist possible. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Thu Nov 8 11:48:25 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Nov 2012 19:48:25 +0000 Subject: hg: openjfx/8/controls/rt: 15 new changesets Message-ID: <20121108194847.95BC747861@hg.openjdk.java.net> Changeset: 4e51d2d9a6ff Author: Seeon Birger Date: 2012-10-24 19:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/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/controls/rt/rev/ed8fff136275 Merge Changeset: d908a2cb4614 Author: David Hill Date: 2012-10-31 09:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d908a2cb4614 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: a5b821631839 Author: Eva Krejcirova Date: 2012-11-01 15:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a5b821631839 RT-25931: Gradient.valueOf doesn't parse rgb(), hsl() color notation ! javafx-ui-common/src/com/sun/javafx/scene/paint/GradientUtils.java ! javafx-ui-common/test/unit/javafx/scene/paint/LinearGradientTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/RadialGradientTest.java Changeset: 04a583291281 Author: Martin Sladecek Date: 2012-11-05 11:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/04a583291281 RT-16011: Release Nodes when they are no longer part of the scenegraph. ! javafx-ui-common/src/javafx/scene/Node.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubNode.java Changeset: 70af26170488 Author: Martin Sladecek Date: 2012-11-05 11:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/70af26170488 merge Changeset: 9e5f8388c043 Author: Felipe Heidrich Date: 2012-11-05 10:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9e5f8388c043 COMMENT-ONLY (fixing internal comments) ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 9d03e07c0278 Author: Martin Sladecek Date: 2012-11-06 10:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9d03e07c0278 RT-9383 Add proper constructors & factory methods to event classes, remove impl ! javafx-ui-common/src/com/sun/javafx/scene/EnteredExitedHandler.java ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/InputEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodTextRun.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.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/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/TransferMode.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/stage/WindowEvent.java ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/InputMethodEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/InputMethodTextRunTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyCodeTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyCombinationTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/RotateEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ScrollEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/SwipeEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ZoomEventTest.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 9b6c86c2e88f Author: Martin Sladecek Date: 2012-11-06 10:50 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9b6c86c2e88f merge Changeset: 9900811ad27b Author: Martin Sladecek Date: 2012-11-06 15:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9900811ad27b RT-23448 ParallelTransition/SequentialTransition: Change of rate during the animation play not working ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 944a3d7a6b33 Author: Martin Sladecek Date: 2012-11-06 15:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/944a3d7a6b33 merge Changeset: b36815546648 Author: Martin Sladecek Date: 2012-11-06 16:11 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b36815546648 RT-25942 Incorrect behavior of Stage.resizableProperty().set() ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/test/unit/javafx/stage/StageTest.java Changeset: e13317e2a91f Author: Martin Sladecek Date: 2012-11-06 16:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e13317e2a91f merge Changeset: 365a3a5249c5 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-06 09:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/365a3a5249c5 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 744a754668fa Author: Paru Somashekar Date: 2012-11-08 19:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/744a754668fa Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java From joseph.andresen at oracle.com Thu Nov 8 12:32:36 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Thu, 8 Nov 2012 12:32:36 -0800 Subject: Open Sourcing: decora-compiler In-Reply-To: References: <206E342B-7E40-4D9C-B34E-E3430F822856@oracle.com> <50995172.1050203@bestsolution.at> <509A9656.6060306@bestsolution.at> <509B7F41.10205@bestsolution.at> Message-ID: They started playing around with it couple weeks ago... But it was a low priority. On Nov 8, 2012, at 2:33 AM, Jiri Prajzner wrote: > Any chance NetBeans folks will catch up on this? :) > > Regards, Jiri > > -- > http://www.dredwerkz.cz > +420 739 575 905 > 218 659 431 > http://www.plurk.com/goddard > > ---------- P?vodn? zpr?va ---------- > Od: Tom Schindl > Datum: 8. 11. 2012 > P?edm?t: Re: Open Sourcing: decora-compiler > "[Resending because the first one is queued because I attached a screenshot] > > Hi, > > You got me I fact I don't only plan I've written one already > yesterday - see > http://tomsondev.bestsolution.at/2012/11/08/javafx-shader-language-jsl-or- > writing-an-editor-for-a-language-you-dont-know/ > (http://tomsondev.bestsolution.at/2012/11/08/javafx-shader-language-jsl-or-writing-an-editor-for-a-language-you-dont-know/) > ! > > It's a very dumb one yet but it could be improved, although I have to > say this is very low priority in the complete e(fx)clipse project. > > Tom > > Am 08.11.12 07:21, schrieb Felipe Heidrich: >> Hi Tom, >> >> >> Out of curiosity, >> >> Are you planning on adding JSL editor to e(fx)clipse ? >> >> I think that would be really cool. Provided that we already have the DSL > grammar file for ANTR it should not be too much trouble to pass it to xText > (i hope). >> >> Joe/Rich: would we be able to get Tom a couple of JSL example files to get > him going ? >> >> Cheers >> Felipe >> >> >> On Nov 7, 2012, at 9:11 AM, Tom Schindl wrote: >> >>> Hi, >>> >>> Ok - I cloned the graphic forest - to get my hands dirty on this are >>> there any example DSL-Files, to do some monkey see monkey do? >>> >>> Tom >>> >>> Am 06.11.12 19:08, schrieb Richard Bair: >>>> It will be in "rt". It will start out in the graphics forest but by next > week it will have propagated through the rest of them. >>>> >>>> On Nov 6, 2012, at 10:05 AM, Tom Schindl > wrote: >>>> >>>>> That sounds interesting where will it endup? In which mercurial repo? >>>>> >>>>> Tom >>>>> >>>>> Am 06.11.12 17:13, schrieb Richard Bair: >>>>>> Hi, >>>>>> >>>>>> I'm going to be open sourcing today another one of our projects called > decora-compiler. We have our own DSL for shader languages called Decora. > What we do is generate shaders for OpenGL and D3D from this language. We > also generate Java code and SSE native code. For some shaders, we ended up > generating them and then hand-tweaking them from there. >>>>>> >>>>>> The decora-compiler is used during the build process, but is not > itself part of either the JDK or JRE, and so has mostly remained invisible > to everybody. There is an "ME" based backend for JavaME which I don't think > is even being used anymore, so there is stuff here we could remove to reduce > the size of the project (and I will be filing a JIRA for this). >>>>>> >>>>>> decora-compiler isn't really that interesting in isolation, although > at one time we had entertained the idea of popularizing it so that people > could write their own shaders with JSL (the decora shader language), in > which case the compiler would be part of the JDK such that you could create > your own effects. Decora is predominantly used for the "effects" -- blur, > box blur, etc. Although it is also used for prism shaders, we don't generate > SSE or Java backends for those, and many of these have been tweaked by hand > vs. simply generated. >>>>>> >>>>>> Cheers >>>>>> 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(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(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(http://www.BestSolution.at) phone ++43 512 935834 > " From bob.vandette at oracle.com Thu Nov 8 13:11:31 2012 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 8 Nov 2012 16:11:31 -0500 Subject: JFX build and deployment - squeaking wheel Message-ID: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> There have been some questions on this list about Jigsaw, compact profiles, embedded, minimal VMs and the JRE customization tool called jrecreate. Richard asked me to jump in to try to clear up any confusion. Here goes .... The Java Modularity Project (project Jigsaw) that was originally planned for JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) was expecting to use Jigsaw in order to provide smaller customizable Java runtimes for embedded devices. Lacking this new functionality, we decided to propose a simpler alternate plan that would enhance the JDK8 specification to allow the distribution of a small set of profiles that are subsets of the full Java runtime. These are called Compact Profiles. We have proposed three compact profiles. A talk and presentation that I gave at JavaOne describes these profiles. https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8ABE54064406AC304AD59/CON4538_Vandette.pdf The Java Enhancement Proposal (JEP) for this work is here: http://openjdk.java.net/jeps/161 The openjdk repository that implements our current prototype is located here: http://hg.openjdk.java.net/jdk8/profiles The mailing list that discusses the profiles is build-infra-dev at openjdk.java.net since the creation of the new profiles is done using the new configure based JDK build system. This repository allows you to do a build that generates the full JRE, JDK but in addition produces three additional image targets (compact1, compact2, and compact3). In order to achieve the smallest Java runtime for embedded (our goal is around 10MB), we have applied changes to Hotspot that allow us to build a small VM (2-3MB) with reduced functionality. The small VM (minimal) + compact1 profile goal we've set is around 10MB. We're at 11MB today. In addition to the profile bundles and the small VM, we have a reduced Embedded FX stack that we'll run on embedded devices such as the RaspberryPi. This FX Embedded stack is a compatible FX implementation without media and webkit support. The goal for this added stack is 6MB. The jrecreate tool that some of you have asked about is not a java stripping tool. It's main purpose is to assist the embedded developer in customizing Java runtimes. It allows the developer to select which profile, VM, debugging options, compression, security and FX options. It does not strip the full JRE to produce the compact profile. The jrecreate will be packaged with the three compact profile binaries. It simply copies these profiles and applies some additional massaging based on the selected options. We have already pushed the minimal VM changes to JDK8 hotspot and will be open sourcing the compact profile changes since they will be a standard feature of JDK8 (independent of embedded). The current profile changes in our project repository are only functional for Linux x86. We certainly recognize the value that small Java runtimes + reduced FX could have on Java applications published on Web App stores, but the current immediate plan is that the jrecreate tool is only going to be available with our embedded binary downloads since that's where it's needed most. I've had some discussions with our Netbeans team to see what it will take to make Netbeans profile aware. This might be a good way of taking advantage of profiles, reduced FX for producing smaller applications for distribution. I hope this help, Bob. From ozemale at ozemail.com.au Thu Nov 8 13:55:02 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 9 Nov 2012 08:55:02 +1100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> Message-ID: <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> So where does that leave JavaFX for mobiles and tablets? -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Bob Vandette Sent: Friday, 9 November 2012 08:12 To: openjfx-dev at openjdk.java.net Cc: John_Smith at symantec.com; zonski at gmai..com Subject: JFX build and deployment - squeaking wheel There have been some questions on this list about Jigsaw, compact profiles, embedded, minimal VMs and the JRE customization tool called jrecreate. Richard asked me to jump in to try to clear up any confusion. Here goes .... The Java Modularity Project (project Jigsaw) that was originally planned for JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) was expecting to use Jigsaw in order to provide smaller customizable Java runtimes for embedded devices. Lacking this new functionality, we decided to propose a simpler alternate plan that would enhance the JDK8 specification to allow the distribution of a small set of profiles that are subsets of the full Java runtime. These are called Compact Profiles. We have proposed three compact profiles. A talk and presentation that I gave at JavaOne describes these profiles. https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A BE54064406AC304AD59/CON4538_Vandette.pdf The Java Enhancement Proposal (JEP) for this work is here: http://openjdk.java.net/jeps/161 The openjdk repository that implements our current prototype is located here: http://hg.openjdk.java.net/jdk8/profiles The mailing list that discusses the profiles is build-infra-dev at openjdk.java.net since the creation of the new profiles is done using the new configure based JDK build system. This repository allows you to do a build that generates the full JRE, JDK but in addition produces three additional image targets (compact1, compact2, and compact3). In order to achieve the smallest Java runtime for embedded (our goal is around 10MB), we have applied changes to Hotspot that allow us to build a small VM (2-3MB) with reduced functionality. The small VM (minimal) + compact1 profile goal we've set is around 10MB. We're at 11MB today. In addition to the profile bundles and the small VM, we have a reduced Embedded FX stack that we'll run on embedded devices such as the RaspberryPi. This FX Embedded stack is a compatible FX implementation without media and webkit support. The goal for this added stack is 6MB. The jrecreate tool that some of you have asked about is not a java stripping tool. It's main purpose is to assist the embedded developer in customizing Java runtimes. It allows the developer to select which profile, VM, debugging options, compression, security and FX options. It does not strip the full JRE to produce the compact profile. The jrecreate will be packaged with the three compact profile binaries. It simply copies these profiles and applies some additional massaging based on the selected options. We have already pushed the minimal VM changes to JDK8 hotspot and will be open sourcing the compact profile changes since they will be a standard feature of JDK8 (independent of embedded). The current profile changes in our project repository are only functional for Linux x86. We certainly recognize the value that small Java runtimes + reduced FX could have on Java applications published on Web App stores, but the current immediate plan is that the jrecreate tool is only going to be available with our embedded binary downloads since that's where it's needed most. I've had some discussions with our Netbeans team to see what it will take to make Netbeans profile aware. This might be a good way of taking advantage of profiles, reduced FX for producing smaller applications for distribution. I hope this help, Bob. From steve.x.northover at oracle.com Thu Nov 8 14:35:01 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 08 Nov 2012 17:35:01 -0500 Subject: API REVIEW REQUEST: Public API for Node Orientation In-Reply-To: <5093EEBA.40108@oracle.com> References: <5086FE81.8000601@oracle.com> <508A8D13.6030808@oracle.com> <508ABD28.6080402@oracle.com> <508E6D58.3050301@oracle.com> <508E9E04.10209@oracle.com> <508FAEDB.90600@oracle.com> <5093EEBA.40108@oracle.com> Message-ID: <509C3395.1030805@oracle.com> I have entered JIRA for the API issues and add Pavel to them. Anyone who cares can track the API evolution there and of course, ask questions on this list. http://javafx-jira.kenai.com/browse/RT-26140 http://javafx-jira.kenai.com/browse/RT-26142 http://javafx-jira.kenai.com/browse/RT-26141 Steve On 02/11/2012 12:03 PM, steve.x.northover at oracle.com wrote: > Hi Pavel, > > In order to make more progress on the implementation, we have decided > to enter JIRA issues for your API suggestions and follow up there. > Leif will be entering the JIRA and posting the bug id's back to the > list so that anyone who is interested can follow along. > > Thanks for your input, > Steve > > On 30/10/2012 6:41 AM, Pavel Safrata wrote: >> 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 swpalmer at gmail.com Thu Nov 8 14:43:52 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 8 Nov 2012 17:43:52 -0500 Subject: BorderPane ignores managed property? Message-ID: <31DFB4B1-F610-4F30-8F3A-E4EBCA0CDDCF@gmail.com> I did a quick search in Jira but I didn't see this particular issue. It seems that in JavaFX 2.2 BorderPane ignores the managed property. I am rolling my own scroll pane because there is a horrible flickering bug in the standard ScrollPane when the content size changes and the scroll position isn't at 0 (bug report on the way soon). I have placed ScrollBars in the left and bottom panes of the BorderPane and bound their managed property to the visibility property. The problem is that when I hide the scroll bars they are still taking up the physical space in the BorderPane. I'm working around the problem by wrapping them in an HBox and VBox - which shrinks to zero size when the contained ScrollBar becomes unmanaged. Scott From zonski at gmail.com Thu Nov 8 16:16:42 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 9 Nov 2012 11:16:42 +1100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> Message-ID: Thanks for the information Bob. The focus for this work looks to be very much in the embedded space. For some of us, there is a strong motivation to see this in the desktop space and I'd be interested in seeing if/how we can achieve that, and what, if anything, there's anything I can do towards that. Should I be asking questions on this here in the JFX list or in the build-infra-dev list you mentioned - or is this something just not on the table and therefore not something anyone will want to discuss? Cheers, Dan On Fri, Nov 9, 2012 at 8:55 AM, John C. Turnbull wrote: > So where does that leave JavaFX for mobiles and tablets? > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Bob Vandette > Sent: Friday, 9 November 2012 08:12 > To: openjfx-dev at openjdk.java.net > Cc: John_Smith at symantec.com; zonski at gmai..com > Subject: JFX build and deployment - squeaking wheel > > There have been some questions on this list about Jigsaw, compact profiles, > embedded, minimal VMs > and the JRE customization tool called jrecreate. Richard asked me to jump > in to try to clear up any confusion. > > Here goes .... > > The Java Modularity Project (project Jigsaw) that was originally planned > for > JDK8 was deferred to JDK9. > The Java Embedded team (I'm the lead) was expecting to use Jigsaw in order > to provide smaller customizable Java runtimes for embedded devices. > Lacking > this new functionality, we decided to propose a simpler alternate plan that > would enhance the JDK8 specification to allow the distribution > of a small set of profiles that are subsets of the full Java runtime. > These are called Compact Profiles. > We have proposed three compact profiles. A talk and presentation that I > gave at JavaOne describes these profiles. > > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A > BE54064406AC304AD59/CON4538_Vandette.pdf > > The Java Enhancement Proposal (JEP) for this work is here: > > http://openjdk.java.net/jeps/161 > > The openjdk repository that implements our current prototype is located > here: > > http://hg.openjdk.java.net/jdk8/profiles > > The mailing list that discusses the profiles is > build-infra-dev at openjdk.java.net since the creation of the new profiles is > done using the new configure based JDK build system. > > This repository allows you to do a build that generates the full JRE, JDK > but in addition produces three additional image targets (compact1, > compact2, > and compact3). > > In order to achieve the smallest Java runtime for embedded (our goal is > around 10MB), we have applied changes to Hotspot that allow us to build a > small VM (2-3MB) with reduced functionality. The small VM (minimal) + > compact1 profile goal we've set is around 10MB. We're at 11MB today. > > In addition to the profile bundles and the small VM, we have a reduced > Embedded FX stack that we'll run on embedded devices such as the > RaspberryPi. This FX Embedded stack is a compatible FX implementation > without > media and webkit support. The goal for this added stack is 6MB. > > The jrecreate tool that some of you have asked about is not a java > stripping > tool. It's main purpose is to assist the embedded developer in customizing > Java runtimes. It allows the developer to select which profile, VM, > debugging options, compression, security and FX options. It does not strip > the full JRE to produce the compact profile. The jrecreate will be packaged > with the three compact profile binaries. It simply copies these profiles > and applies some additional massaging based on the selected options. > > We have already pushed the minimal VM changes to JDK8 hotspot and will be > open sourcing the compact profile changes since they will be a standard > feature of JDK8 (independent of embedded). The current profile changes in > our project repository are only functional for Linux x86. > > We certainly recognize the value that small Java runtimes + reduced FX > could > have on Java applications published on Web App stores, but the current > immediate plan is that the jrecreate tool is only going to be available > with > our > embedded binary downloads since that's where it's needed most. I've had > some discussions with our Netbeans team to > see what it will take to make Netbeans profile aware. This might be a good > way of taking advantage of profiles, reduced FX for producing smaller > applications for distribution. > > I hope this help, > Bob. > > > From richard.bair at oracle.com Thu Nov 8 15:58:24 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Nov 2012 15:58:24 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> Message-ID: <62F2443E-13F8-46F7-955D-BD1863D2EF0A@oracle.com> I know it is touching a raw nerve and I'm hoping to avoid 3 weeks of suffering as a result :-). We're steadily moving forward, but we don't have any official plans to communicate at this time. Thanks Richard On Nov 8, 2012, at 1:55 PM, "John C. Turnbull" wrote: > So where does that leave JavaFX for mobiles and tablets? > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Bob Vandette > Sent: Friday, 9 November 2012 08:12 > To: openjfx-dev at openjdk.java.net > Cc: John_Smith at symantec.com; zonski at gmai..com > Subject: JFX build and deployment - squeaking wheel > > There have been some questions on this list about Jigsaw, compact profiles, > embedded, minimal VMs > and the JRE customization tool called jrecreate. Richard asked me to jump > in to try to clear up any confusion. > > Here goes .... > > The Java Modularity Project (project Jigsaw) that was originally planned for > JDK8 was deferred to JDK9. > The Java Embedded team (I'm the lead) was expecting to use Jigsaw in order > to provide smaller customizable Java runtimes for embedded devices. Lacking > this new functionality, we decided to propose a simpler alternate plan that > would enhance the JDK8 specification to allow the distribution > of a small set of profiles that are subsets of the full Java runtime. > These are called Compact Profiles. > We have proposed three compact profiles. A talk and presentation that I > gave at JavaOne describes these profiles. > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A > BE54064406AC304AD59/CON4538_Vandette.pdf > > The Java Enhancement Proposal (JEP) for this work is here: > > http://openjdk.java.net/jeps/161 > > The openjdk repository that implements our current prototype is located > here: > > http://hg.openjdk.java.net/jdk8/profiles > > The mailing list that discusses the profiles is > build-infra-dev at openjdk.java.net since the creation of the new profiles is > done using the new configure based JDK build system. > > This repository allows you to do a build that generates the full JRE, JDK > but in addition produces three additional image targets (compact1, compact2, > and compact3). > > In order to achieve the smallest Java runtime for embedded (our goal is > around 10MB), we have applied changes to Hotspot that allow us to build a > small VM (2-3MB) with reduced functionality. The small VM (minimal) + > compact1 profile goal we've set is around 10MB. We're at 11MB today. > > In addition to the profile bundles and the small VM, we have a reduced > Embedded FX stack that we'll run on embedded devices such as the > RaspberryPi. This FX Embedded stack is a compatible FX implementation > without > media and webkit support. The goal for this added stack is 6MB. > > The jrecreate tool that some of you have asked about is not a java stripping > tool. It's main purpose is to assist the embedded developer in customizing > Java runtimes. It allows the developer to select which profile, VM, > debugging options, compression, security and FX options. It does not strip > the full JRE to produce the compact profile. The jrecreate will be packaged > with the three compact profile binaries. It simply copies these profiles > and applies some additional massaging based on the selected options. > > We have already pushed the minimal VM changes to JDK8 hotspot and will be > open sourcing the compact profile changes since they will be a standard > feature of JDK8 (independent of embedded). The current profile changes in > our project repository are only functional for Linux x86. > > We certainly recognize the value that small Java runtimes + reduced FX could > have on Java applications published on Web App stores, but the current > immediate plan is that the jrecreate tool is only going to be available with > our > embedded binary downloads since that's where it's needed most. I've had > some discussions with our Netbeans team to > see what it will take to make Netbeans profile aware. This might be a good > way of taking advantage of profiles, reduced FX for producing smaller > applications for distribution. > > I hope this help, > Bob. > > From richard.bair at oracle.com Thu Nov 8 16:00:20 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Nov 2012 16:00:20 -0800 Subject: BorderPane ignores managed property? In-Reply-To: <31DFB4B1-F610-4F30-8F3A-E4EBCA0CDDCF@gmail.com> References: <31DFB4B1-F610-4F30-8F3A-E4EBCA0CDDCF@gmail.com> Message-ID: <35F7461F-FDE9-443E-90C2-6F0C18C8C903@oracle.com> Yikes, that would be bad! Sounds like a JIRA is in order (and maybe a simple patch?! :-)). Thanks Richard On Nov 8, 2012, at 2:43 PM, Scott Palmer wrote: > I did a quick search in Jira but I didn't see this particular issue. It seems that in JavaFX 2.2 BorderPane ignores the managed property. I am rolling my own scroll pane because there is a horrible flickering bug in the standard ScrollPane when the content size changes and the scroll position isn't at 0 (bug report on the way soon). > > I have placed ScrollBars in the left and bottom panes of the BorderPane and bound their managed property to the visibility property. The problem is that when I hide the scroll bars they are still taking up the physical space in the BorderPane. > > I'm working around the problem by wrapping them in an HBox and VBox - which shrinks to zero size when the contained ScrollBar becomes unmanaged. > > Scott From richard.bair at oracle.com Thu Nov 8 18:54:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Nov 2012 18:54:31 -0800 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <62F2443E-13F8-46F7-955D-BD1863D2EF0A@oracle.com> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> <62F2443E-13F8-46F7-955D-BD1863D2EF0A@oracle.com> Message-ID: <9F33E3E0-FA91-48EE-B0F1-2F17BF4E1B9F@oracle.com> Ha! > we don't have any official plans to communicate at this time. That could be taken several ways!! :-) From ozemale at ozemail.com.au Thu Nov 8 19:06:57 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 9 Nov 2012 14:06:57 +1100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <9F33E3E0-FA91-48EE-B0F1-2F17BF4E1B9F@oracle.com> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <01bd01cdbdfb$b4e6adb0$1eb40910$@com.au> <62F2443E-13F8-46F7-955D-BD1863D2EF0A@oracle.com> <9F33E3E0-FA91-48EE-B0F1-2F17BF4E1B9F@oracle.com> Message-ID: <01cd01cdbe27$47fff090$d7ffd1b0$@com.au> I just get concerned when I read things like: "the current immediate plan is that the jrecreate tool is only going to be available with our embedded binary downloads" It seems Oracle thinks embedded Java is more important than mobiles and tablets. -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Friday, 9 November 2012 13:55 To: John C. Turnbull Cc: John_Smith at symantec.com; openjfx-dev at openjdk.java.net List Subject: Re: JFX build and deployment - squeaking wheel Ha! > we don't have any official plans to communicate at this time. That could be taken several ways!! :-) From hang.vo at oracle.com Thu Nov 8 20:45:55 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Nov 2012 04:45:55 +0000 Subject: hg: openjfx/8/master/rt: 22 new changesets Message-ID: <20121109044620.BE70C47879@hg.openjdk.java.net> Changeset: d811a42d75ba Author: Paru Somashekar Date: 2012-10-18 12:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/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 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/master/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 Changeset: b0f305a2d89e Author: Paru Somashekar Date: 2012-10-25 15:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/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 Changeset: 29364c6d7434 Author: Paru Somashekar Date: 2012-10-26 16:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/29364c6d7434 fix broken test failure for CategoryAxis. ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java Changeset: dbd6d178b5dd Author: leifs Date: 2012-10-29 12:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/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 Changeset: e901aef78ced Author: jgiles Date: 2012-10-31 01:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e901aef78ced Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 0f2f18efc353 Author: Paru Somashekar Date: 2012-11-05 22:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0f2f18efc353 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 4e51d2d9a6ff Author: Seeon Birger Date: 2012-10-24 19:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/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/master/rt/rev/ed8fff136275 Merge Changeset: d908a2cb4614 Author: David Hill Date: 2012-10-31 09:33 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d908a2cb4614 Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: a5b821631839 Author: Eva Krejcirova Date: 2012-11-01 15:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a5b821631839 RT-25931: Gradient.valueOf doesn't parse rgb(), hsl() color notation ! javafx-ui-common/src/com/sun/javafx/scene/paint/GradientUtils.java ! javafx-ui-common/test/unit/javafx/scene/paint/LinearGradientTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/RadialGradientTest.java Changeset: 04a583291281 Author: Martin Sladecek Date: 2012-11-05 11:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/04a583291281 RT-16011: Release Nodes when they are no longer part of the scenegraph. ! javafx-ui-common/src/javafx/scene/Node.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubNode.java Changeset: 70af26170488 Author: Martin Sladecek Date: 2012-11-05 11:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/70af26170488 merge Changeset: 9e5f8388c043 Author: Felipe Heidrich Date: 2012-11-05 10:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9e5f8388c043 COMMENT-ONLY (fixing internal comments) ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 9d03e07c0278 Author: Martin Sladecek Date: 2012-11-06 10:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9d03e07c0278 RT-9383 Add proper constructors & factory methods to event classes, remove impl ! javafx-ui-common/src/com/sun/javafx/scene/EnteredExitedHandler.java ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/InputEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodTextRun.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.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/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/TransferMode.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/stage/WindowEvent.java ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/InputMethodEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/InputMethodTextRunTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyCodeTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyCombinationTest.java ! javafx-ui-common/test/unit/javafx/scene/input/KeyEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/RotateEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ScrollEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/SwipeEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ZoomEventTest.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 9b6c86c2e88f Author: Martin Sladecek Date: 2012-11-06 10:50 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9b6c86c2e88f merge Changeset: 9900811ad27b Author: Martin Sladecek Date: 2012-11-06 15:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9900811ad27b RT-23448 ParallelTransition/SequentialTransition: Change of rate during the animation play not working ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 944a3d7a6b33 Author: Martin Sladecek Date: 2012-11-06 15:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/944a3d7a6b33 merge Changeset: b36815546648 Author: Martin Sladecek Date: 2012-11-06 16:11 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b36815546648 RT-25942 Incorrect behavior of Stage.resizableProperty().set() ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/test/unit/javafx/stage/StageTest.java Changeset: e13317e2a91f Author: Martin Sladecek Date: 2012-11-06 16:12 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e13317e2a91f merge Changeset: 365a3a5249c5 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-06 09:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/365a3a5249c5 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 54bb3abd41fe Author: hudson Date: 2012-11-08 20:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/54bb3abd41fe Added tag 8.0-b64 for changeset 365a3a5249c5 ! .hgtags From hang.vo at oracle.com Fri Nov 9 07:18:16 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Nov 2012 15:18:16 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121109151822.A68BC478AB@hg.openjdk.java.net> Changeset: fd48b9d9cb2b Author: David Grieve Date: 2012-11-09 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fd48b9d9cb2b RT-26165: Need to call impl_getAllParentStylesheets when updating stylesheets for a Parent. ! javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 9b926fb92fcf Author: David Grieve Date: 2012-11-09 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9b926fb92fcf RT-25607: When looking up a font style, consider the inline styles of parent nodes ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java From hang.vo at oracle.com Fri Nov 9 07:33:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Nov 2012 15:33:44 +0000 Subject: hg: openjfx/8/controls/rt: missed changes from last patch. Message-ID: <20121109153345.2C215478AC@hg.openjdk.java.net> Changeset: edf3703cb202 Author: David Grieve Date: 2012-11-09 10:17 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/edf3703cb202 missed changes from last patch. ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_UA.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java From swpalmer at gmail.com Fri Nov 9 13:35:10 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 9 Nov 2012 16:35:10 -0500 Subject: BorderPane ignores managed property? In-Reply-To: <35F7461F-FDE9-443E-90C2-6F0C18C8C903@oracle.com> References: <31DFB4B1-F610-4F30-8F3A-E4EBCA0CDDCF@gmail.com> <35F7461F-FDE9-443E-90C2-6F0C18C8C903@oracle.com> Message-ID: <988ECF34-765F-4F1E-AD10-B6F43CD9BF7C@gmail.com> NetBeans project for test case is attached to issue: http://javafx-jira.kenai.com/browse/RT-26168 Cheers, Scott On 2012-11-08, at 7:00 PM, Richard Bair wrote: > Yikes, that would be bad! Sounds like a JIRA is in order (and maybe a simple patch?! :-)). > > Thanks > Richard > > On Nov 8, 2012, at 2:43 PM, Scott Palmer wrote: > >> I did a quick search in Jira but I didn't see this particular issue. It seems that in JavaFX 2.2 BorderPane ignores the managed property. I am rolling my own scroll pane because there is a horrible flickering bug in the standard ScrollPane when the content size changes and the scroll position isn't at 0 (bug report on the way soon). >> >> I have placed ScrollBars in the left and bottom panes of the BorderPane and bound their managed property to the visibility property. The problem is that when I hide the scroll bars they are still taking up the physical space in the BorderPane. >> >> I'm working around the problem by wrapping them in an HBox and VBox - which shrinks to zero size when the contained ScrollBar becomes unmanaged. >> >> Scott > From fbrunnerlist at gmx.ch Fri Nov 9 15:01:11 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Sat, 10 Nov 2012 00:01:11 +0100 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> Message-ID: <1648550.UHvtHTjOA5@shire> Hi Bob, As I understand the profiles/ project Jigsaw in the context of JavaFX is it to makte it easier to port Java + JavaFX to other platforms especially by omitting AWT. So I understand that the following packages are omitted: javax.awt.* javax.swing.* (dependencies to AWT) javax.imagio.* (dependencies to AWT) But neither are any of the following packages mentioned: java.beans.* javax.accessibility javax.activation javax.activity javax.annotation javax.jws.* javax.print.* javax.sound.* org.omg.* Now, I understand that the java.beans.PropertyEditor related classes cause an issue because of the dependency to AWT, but the JEP 161 states that some packages have to be split up anyway (which will probably cause issues with OSGi based library, though). And Java Beans patterns (and e.g. PropertyChangeListener) are used at many places in applications and frameworks. I think there should be a profile (maybe Compact3?), which includes everything except AWT related classes to allow maximum reuse and portability of existing 3rd party libraries, which make the Java ecosystem so rich, so they can be used in JavaFX applications. And another question: The JEP 161 states: "If a package listed in a lower Profile in this table has subpackages then those subpackages are included in that Profile unless they are identified as members of some higher Profile. Thus the java.lang.reflect package, e.g., is in the Compact1 Profile, but java.lang.management is in the Compact3 Profile." But the profile Compact1 states explicitly both java.util and java.util.logging. What about the following packages? java.util.concurrent java.util.concurrent.atomic java.util.concurrent.locks java.util.jar java.util.regex java.util.spi java.util.zip I think it would be clearer if all subpackages were listed explicitly. - Florian Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette: > There have been some questions on this list about Jigsaw, compact profiles, > embedded, minimal VMs and the JRE customization tool called jrecreate. > Richard asked me to jump in to try to clear up any confusion. > > Here goes .... > > The Java Modularity Project (project Jigsaw) that was originally planned for > JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) was > expecting to use Jigsaw in order to provide smaller customizable Java > runtimes for embedded devices. Lacking this new functionality, we decided > to propose a simpler alternate plan that would enhance the JDK8 > specification to allow the distribution of a small set of profiles that are > subsets of the full Java runtime. These are called Compact Profiles. We > have proposed three compact profiles. A talk and presentation that I gave > at JavaOne describes these profiles. > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A > BE54064406AC304AD59/CON4538_Vandette.pdf > > The Java Enhancement Proposal (JEP) for this work is here: > > http://openjdk.java.net/jeps/161 > > The openjdk repository that implements our current prototype is located > here: > > http://hg.openjdk.java.net/jdk8/profiles > > The mailing list that discusses the profiles is > build-infra-dev at openjdk.java.net since the creation of the new profiles is > done using the new configure based JDK build system. > > This repository allows you to do a build that generates the full JRE, JDK > but in addition produces three additional image targets (compact1, > compact2, and compact3). > > In order to achieve the smallest Java runtime for embedded (our goal is > around 10MB), we have applied changes to Hotspot that allow us to build a > small VM (2-3MB) with reduced functionality. The small VM (minimal) + > compact1 profile goal we've set is around 10MB. We're at 11MB today. > > In addition to the profile bundles and the small VM, we have a reduced > Embedded FX stack that we'll run on embedded devices such as the > RaspberryPi. This FX Embedded stack is a compatible FX implementation > without media and webkit support. The goal for this added stack is 6MB. > > The jrecreate tool that some of you have asked about is not a java stripping > tool. It's main purpose is to assist the embedded developer in customizing > Java runtimes. It allows the developer to select which profile, VM, > debugging options, compression, security and FX options. It does not strip > the full JRE to produce the compact profile. The jrecreate will be packaged > with the three compact profile binaries. It simply copies these profiles > and applies some additional massaging based on the selected options. > > We have already pushed the minimal VM changes to JDK8 hotspot and will be > open sourcing the compact profile changes since they will be a standard > feature of JDK8 (independent of embedded). The current profile changes in > our project repository are only functional for Linux x86. > > We certainly recognize the value that small Java runtimes + reduced FX could > have on Java applications published on Web App stores, but the current > immediate plan is that the jrecreate tool is only going to be available > with our embedded binary downloads since that's where it's needed most. > I've had some discussions with our Netbeans team to see what it will take > to make Netbeans profile aware. This might be a good way of taking > advantage of profiles, reduced FX for producing smaller applications for > distribution. > > I hope this help, > Bob. From bob.vandette at oracle.com Fri Nov 9 15:34:20 2012 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 9 Nov 2012 18:34:20 -0500 Subject: Compact Profiles for the Java Runtime (was: JFX build and deployment - squeaking wheel) In-Reply-To: <6568713.h2jPD6x2RH@shire> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <6568713.h2jPD6x2RH@shire> Message-ID: <0960991D-B64E-4383-A89E-648604986F53@oracle.com> On Nov 9, 2012, at 5:55 PM, Florian Brunner wrote: > Hi Bob, > > As I understand the profiles/ project Jigsaw in the context of JavaFX is it to makte it easier to port Java + JavaFX to other platforms especially by omitting AWT. So I understand that the following packages are omitted: > > javax.awt.* > javax.swing.* (dependencies to AWT) > javax.imagio.* (dependencies to AWT) > > But neither are any of the following packages mentioned: > > java.beans.* > javax.accessibility > javax.activation > javax.activity > javax.annotation > javax.jws.* > javax.print.* > javax.sound.* > org.omg.* > > > Now, I understand that the java.beans.PropertyEditor related classes cause an issue because of the dependency to AWT, but the JEP 161 states that some packages have to be split up anyway (which will probably cause issues with OSGi based library, though). And Java Beans patterns (and e.g. PropertyChangeListener) are used at many places in applications and frameworks. We really want to avoid splitting packages because this will make it difficult to transition to Jigsaw in JDK9. The PropertyChangeListener classes are problematic. We currently have a small set of beans classes in compact1 that we'd like to remove. I've requested the fx team remove any dependency on these class in preparation for their possible removal. They have a few JIRA's filed to track this change. We have analyzed two different OSGi implementations and they don't appear to have any dependencies on these classes. Can you provide us with a list of some concrete applications that you believe require Java Beans? We could investigate the feasibility of pushing this package down to compact3 if there's enough demand and if it doesn't have any dependencies that we can't untangle. > > I think there should be a profile (maybe Compact3?), which includes everything except AWT related classes to allow maximum reuse and portability of existing 3rd party libraries, which make the Java ecosystem so rich, so they can be used in JavaFX applications. The compact3 profile is a very rich set of APIs. The only large group of SE APIs that are not found in this profile are: Desktop (AWT/SWING/Java2D), JAX-WS, and Corba. For embedded we felt that JAX-WS was too heavy weight and difficult to split up or subset. We've been working under the assumption that embedded devices will probably continue to use the smaller kSoap or move to JAX-RS for lighter weight RestFul web services. > > And another question: > > The JEP 161 states: > "If a package listed in a lower Profile in this table has subpackages then those subpackages are included in that Profile unless they are identified as members of some higher Profile. Thus the java.lang.reflect package, e.g., is in the Compact1 Profile, but java.lang.management is in the Compact3 Profile." > > But the profile Compact1 states explicitly both java.util and java.util.logging. > > What about the following packages? > > java.util.concurrent > java.util.concurrent.atomic > java.util.concurrent.locks > java.util.jar > java.util.regex > java.util.spi > java.util.zip We were attempting to keep the contents of the JEP to the minimum. These packages are covered by this statement "If a package listed in a lower Profile in this table has subpackages then those subpackages are included in that Profile ". Since they aren't explicitly mentioned in higher profiles, they are in compact1. Feel free to build your own set of linux 86 profiles where you can see exactly what we've proposed for each profile. You could also grab a copy of this repo and look at the jdk/make/profile-rtjar-includes.txt file that lists the packages included in each compact profile level. http://hg.openjdk.java.net/jdk8/profiles/jdk Thanks for the input, Bob. > > I think it would be clearer if all subpackages were listed explicitly. > > - Florian > > Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette: > > There have been some questions on this list about Jigsaw, compact profiles, > > embedded, minimal VMs and the JRE customization tool called jrecreate. > > Richard asked me to jump in to try to clear up any confusion. > > > > Here goes .... > > > > The Java Modularity Project (project Jigsaw) that was originally planned for > > JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) was > > expecting to use Jigsaw in order to provide smaller customizable Java > > runtimes for embedded devices. Lacking this new functionality, we decided > > to propose a simpler alternate plan that would enhance the JDK8 > > specification to allow the distribution of a small set of profiles that are > > subsets of the full Java runtime. These are called Compact Profiles. We > > have proposed three compact profiles. A talk and presentation that I gave > > at JavaOne describes these profiles. > > > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A > > BE54064406AC304AD59/CON4538_Vandette.pdf > > > > The Java Enhancement Proposal (JEP) for this work is here: > > > > http://openjdk.java.net/jeps/161 > > > > The openjdk repository that implements our current prototype is located > > here: > > > > http://hg.openjdk.java.net/jdk8/profiles > > > > The mailing list that discusses the profiles is > > build-infra-dev at openjdk.java.net since the creation of the new profiles is > > done using the new configure based JDK build system. > > > > This repository allows you to do a build that generates the full JRE, JDK > > but in addition produces three additional image targets (compact1, > > compact2, and compact3). > > > > In order to achieve the smallest Java runtime for embedded (our goal is > > around 10MB), we have applied changes to Hotspot that allow us to build a > > small VM (2-3MB) with reduced functionality. The small VM (minimal) + > > compact1 profile goal we've set is around 10MB. We're at 11MB today. > > > > In addition to the profile bundles and the small VM, we have a reduced > > Embedded FX stack that we'll run on embedded devices such as the > > RaspberryPi. This FX Embedded stack is a compatible FX implementation > > without media and webkit support. The goal for this added stack is 6MB. > > > > The jrecreate tool that some of you have asked about is not a java stripping > > tool. It's main purpose is to assist the embedded developer in customizing > > Java runtimes. It allows the developer to select which profile, VM, > > debugging options, compression, security and FX options. It does not strip > > the full JRE to produce the compact profile. The jrecreate will be packaged > > with the three compact profile binaries. It simply copies these profiles > > and applies some additional massaging based on the selected options. > > > > We have already pushed the minimal VM changes to JDK8 hotspot and will be > > open sourcing the compact profile changes since they will be a standard > > feature of JDK8 (independent of embedded). The current profile changes in > > our project repository are only functional for Linux x86. > > > > We certainly recognize the value that small Java runtimes + reduced FX could > > have on Java applications published on Web App stores, but the current > > immediate plan is that the jrecreate tool is only going to be available > > with our embedded binary downloads since that's where it's needed most. > > I've had some discussions with our Netbeans team to see what it will take > > to make Netbeans profile aware. This might be a good way of taking > > advantage of profiles, reduced FX for producing smaller applications for > > distribution. > > > > I hope this help, > > Bob. From zonski at gmail.com Fri Nov 9 15:54:49 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 10 Nov 2012 10:54:49 +1100 Subject: Compact Profiles for the Java Runtime (was: JFX build and deployment - squeaking wheel) In-Reply-To: <0960991D-B64E-4383-A89E-648604986F53@oracle.com> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <6568713.h2jPD6x2RH@shire> <0960991D-B64E-4383-A89E-648604986F53@oracle.com> Message-ID: <21E98345-77D5-42FF-A302-CBD5421D1A98@gmail.com> So we should use this forum to discuss requirements for compact JREs for desktop JFX? On 10/11/2012, at 10:34 AM, Bob Vandette wrote: > On Nov 9, 2012, at 5:55 PM, Florian Brunner wrote: > >> Hi Bob, >> >> As I understand the profiles/ project Jigsaw in the context of JavaFX is it to makte it easier to port Java + JavaFX to other platforms especially by omitting AWT. So I understand that the following packages are omitted: >> >> javax.awt.* >> javax.swing.* (dependencies to AWT) >> javax.imagio.* (dependencies to AWT) >> >> But neither are any of the following packages mentioned: >> >> java.beans.* >> javax.accessibility >> javax.activation >> javax.activity >> javax.annotation >> javax.jws.* >> javax.print.* >> javax.sound.* >> org.omg.* >> >> >> Now, I understand that the java.beans.PropertyEditor related classes cause an issue because of the dependency to AWT, but the JEP 161 states that some packages have to be split up anyway (which will probably cause issues with OSGi based library, though). And Java Beans patterns (and e.g. PropertyChangeListener) are used at many places in applications and frameworks. > > We really want to avoid splitting packages because this will make it difficult to transition to Jigsaw in JDK9. > > The PropertyChangeListener classes are problematic. We currently have a small set of beans classes in compact1 > that we'd like to remove. I've requested the fx team remove any dependency on these class in preparation for > their possible removal. They have a few JIRA's filed to track this change. > > We have analyzed two different OSGi implementations and they don't appear to have any dependencies on these > classes. > > Can you provide us with a list of some concrete applications that you believe require Java Beans? We could > investigate the feasibility of pushing this package down to compact3 if there's enough demand and if it doesn't > have any dependencies that we can't untangle. > > >> >> I think there should be a profile (maybe Compact3?), which includes everything except AWT related classes to allow maximum reuse and portability of existing 3rd party libraries, which make the Java ecosystem so rich, so they can be used in JavaFX applications. > > The compact3 profile is a very rich set of APIs. The only large group of SE APIs that are not found in this profile are: Desktop (AWT/SWING/Java2D), JAX-WS, and Corba. > > For embedded we felt that JAX-WS was too heavy weight and difficult to split up or subset. We've been working under the assumption > that embedded devices will probably continue to use the smaller kSoap or move to JAX-RS for lighter weight RestFul web services. > >> >> And another question: >> >> The JEP 161 states: >> "If a package listed in a lower Profile in this table has subpackages then those subpackages are included in that Profile unless they are identified as members of some higher Profile. Thus the java.lang.reflect package, e.g., is in the Compact1 Profile, but java.lang.management is in the Compact3 Profile." >> >> But the profile Compact1 states explicitly both java.util and java.util.logging. >> >> What about the following packages? >> >> java.util.concurrent >> java.util.concurrent.atomic >> java.util.concurrent.locks >> java.util.jar >> java.util.regex >> java.util.spi >> java.util.zip > > We were attempting to keep the contents of the JEP to the minimum. > > These packages are covered by this statement "If a package listed in a lower Profile in this table has subpackages then those subpackages are included in that Profile ". Since they aren't explicitly mentioned in higher profiles, they are in compact1. > > Feel free to build your own set of linux 86 profiles where you can see exactly what we've proposed for each profile. > > You could also grab a copy of this repo and look at the jdk/make/profile-rtjar-includes.txt file > that lists the packages included in each compact profile level. > > http://hg.openjdk.java.net/jdk8/profiles/jdk > > Thanks for the input, > Bob. > >> >> I think it would be clearer if all subpackages were listed explicitly. >> >> - Florian >> >> Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette: >>> There have been some questions on this list about Jigsaw, compact profiles, >>> embedded, minimal VMs and the JRE customization tool called jrecreate. >>> Richard asked me to jump in to try to clear up any confusion. >>> >>> Here goes .... >>> >>> The Java Modularity Project (project Jigsaw) that was originally planned for >>> JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) was >>> expecting to use Jigsaw in order to provide smaller customizable Java >>> runtimes for embedded devices. Lacking this new functionality, we decided >>> to propose a simpler alternate plan that would enhance the JDK8 >>> specification to allow the distribution of a small set of profiles that are >>> subsets of the full Java runtime. These are called Compact Profiles. We >>> have proposed three compact profiles. A talk and presentation that I gave >>> at JavaOne describes these profiles. >>> >>> https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A >>> BE54064406AC304AD59/CON4538_Vandette.pdf >>> >>> The Java Enhancement Proposal (JEP) for this work is here: >>> >>> http://openjdk.java.net/jeps/161 >>> >>> The openjdk repository that implements our current prototype is located >>> here: >>> >>> http://hg.openjdk.java.net/jdk8/profiles >>> >>> The mailing list that discusses the profiles is >>> build-infra-dev at openjdk.java.net since the creation of the new profiles is >>> done using the new configure based JDK build system. >>> >>> This repository allows you to do a build that generates the full JRE, JDK >>> but in addition produces three additional image targets (compact1, >>> compact2, and compact3). >>> >>> In order to achieve the smallest Java runtime for embedded (our goal is >>> around 10MB), we have applied changes to Hotspot that allow us to build a >>> small VM (2-3MB) with reduced functionality. The small VM (minimal) + >>> compact1 profile goal we've set is around 10MB. We're at 11MB today. >>> >>> In addition to the profile bundles and the small VM, we have a reduced >>> Embedded FX stack that we'll run on embedded devices such as the >>> RaspberryPi. This FX Embedded stack is a compatible FX implementation >>> without media and webkit support. The goal for this added stack is 6MB. >>> >>> The jrecreate tool that some of you have asked about is not a java stripping >>> tool. It's main purpose is to assist the embedded developer in customizing >>> Java runtimes. It allows the developer to select which profile, VM, >>> debugging options, compression, security and FX options. It does not strip >>> the full JRE to produce the compact profile. The jrecreate will be packaged >>> with the three compact profile binaries. It simply copies these profiles >>> and applies some additional massaging based on the selected options. >>> >>> We have already pushed the minimal VM changes to JDK8 hotspot and will be >>> open sourcing the compact profile changes since they will be a standard >>> feature of JDK8 (independent of embedded). The current profile changes in >>> our project repository are only functional for Linux x86. >>> >>> We certainly recognize the value that small Java runtimes + reduced FX could >>> have on Java applications published on Web App stores, but the current >>> immediate plan is that the jrecreate tool is only going to be available >>> with our embedded binary downloads since that's where it's needed most. >>> I've had some discussions with our Netbeans team to see what it will take >>> to make Netbeans profile aware. This might be a good way of taking >>> advantage of profiles, reduced FX for producing smaller applications for >>> distribution. >>> >>> I hope this help, >>> Bob. > From hang.vo at oracle.com Fri Nov 9 17:18:15 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 10 Nov 2012 01:18:15 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121110011822.278F8478BC@hg.openjdk.java.net> Changeset: 54bb3abd41fe Author: hudson Date: 2012-11-08 20:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/54bb3abd41fe Added tag 8.0-b64 for changeset 365a3a5249c5 ! .hgtags Changeset: ab55578e4692 Author: kcr Date: 2012-11-09 17:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab55578e4692 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Fri Nov 9 17:18:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 10 Nov 2012 01:18:00 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121110011805.D3FB1478BB@hg.openjdk.java.net> Changeset: 54bb3abd41fe Author: hudson Date: 2012-11-08 20:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/54bb3abd41fe Added tag 8.0-b64 for changeset 365a3a5249c5 ! .hgtags Changeset: 952f2115ae99 Author: Paru Somashekar Date: 2012-11-09 23:27 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/952f2115ae99 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Fri Nov 9 22:19:03 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 10 Nov 2012 06:19:03 +0000 Subject: hg: openjfx/8/graphics/rt: Merge Rich Text - RT-17392 (part1) including fixes for RT-20645, RT-24735, RT-24634, RT-24467, RT-24435, RT-24012, RT-23231, RT-16853, RT-14356 Message-ID: <20121110061906.62615478C5@hg.openjdk.java.net> Changeset: 09cbcb519b6d Author: Felipe Heidrich Date: 2012-11-09 22:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/09cbcb519b6d Merge Rich Text - RT-17392 (part1) including fixes for RT-20645, RT-24735, RT-24634, RT-24467, RT-24435, RT-24012, RT-23231, RT-16853, RT-14356 + javafx-ui-common/src/com/sun/javafx/scene/text/GlyphList.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLayoutFactory.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLine.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextSpan.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/test/unit/javafx/scene/text/Text_builder_Test.java ! javafx-ui-common/test/unit/javafx/scene/text/Text_onInvalidate_Test.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayoutFactory.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Fri Nov 9 23:03:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 10 Nov 2012 07:03:35 +0000 Subject: hg: openjfx/sandbox-8/controls/rt: 6 new changesets Message-ID: <20121110070343.943EB478C7@hg.openjdk.java.net> Changeset: ca998cecc583 Author: jgiles Date: 2012-11-01 15:45 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/ca998cecc583 TreeTableView.spanModel is now of type TreeItem, not T. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: a9150b2ac1b6 Author: jgiles Date: 2012-11-05 14:42 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/a9150b2ac1b6 Fix issue in TreeTableColumn where the TABLE_COLUMN_EDIT EventType is duplicated. ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: 38c4f09a7a14 Author: jgiles Date: 2012-11-05 14:42 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/38c4f09a7a14 Extract out DEFAULT_STYLE_CLASS in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 970ff829e69d Author: jgiles Date: 2012-11-05 14:45 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/970ff829e69d Make SpanModel a SAM interface (or whatever SAM is called these days). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/javafx/scene/control/SpanModel.java Changeset: beea6597d742 Author: jgiles Date: 2012-11-10 19:53 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/beea6597d742 Added early CSS to demonstrate cell spanning support in TreeTableView. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 33c215edd891 Author: jgiles Date: 2012-11-10 19:55 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/33c215edd891 Further progress on TreeTableView - now with further progress on selection and focus model integration (still much more to come wrt behaviors however) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java + javafx-ui-controls/src/javafx/scene/control/TableFocusModel.java + javafx-ui-controls/src/javafx/scene/control/TableSelectionModel.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java From danno.ferrin at shemnon.com Sat Nov 10 00:09:54 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Sat, 10 Nov 2012 01:09:54 -0700 Subject: JFX build and deployment - squeaking wheel In-Reply-To: <1648550.UHvtHTjOA5@shire> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <1648550.UHvtHTjOA5@shire> Message-ID: The compact profiles have their own copied jdk build at http://hg.openjdk.java.net/jdk8/profiles/jdk Here is the current (as of the mailing) list of included packages and classes http://hg.openjdk.java.net/jdk8/profiles/jdk/file/c9ca39ad52ee/makefiles/profile-rtjar-includes.txt Rather than going line by line in your list, I would recommend reading that file. There are some java.beans classes cherry picked for Profile 1, but most of the rest of the javax stuff you mentioned is profile 3/4 (with 4 being the full JDK). But java.util.whatever seems to all be in profile 1. On Fri, Nov 9, 2012 at 4:01 PM, Florian Brunner wrote: > Hi Bob, > > As I understand the profiles/ project Jigsaw in the context of JavaFX is > it to > makte it easier to port Java + JavaFX to other platforms especially by > omitting AWT. So I understand that the following packages are omitted: > > javax.awt.* > javax.swing.* (dependencies to AWT) > javax.imagio.* (dependencies to AWT) > > But neither are any of the following packages mentioned: > > java.beans.* > javax.accessibility > javax.activation > javax.activity > javax.annotation > javax.jws.* > javax.print.* > javax.sound.* > org.omg.* > > > Now, I understand that the java.beans.PropertyEditor related classes cause > an > issue because of the dependency to AWT, but the JEP 161 states that some > packages have to be split up anyway (which will probably cause issues with > OSGi based library, though). And Java Beans patterns (and e.g. > PropertyChangeListener) are used at many places in applications and > frameworks. > > I think there should be a profile (maybe Compact3?), which includes > everything > except AWT related classes to allow maximum reuse and portability of > existing > 3rd party libraries, which make the Java ecosystem so rich, so they can be > used in JavaFX applications. > > And another question: > > The JEP 161 states: > "If a package listed in a lower Profile in this table has subpackages then > those subpackages are included in that Profile unless they are identified > as > members of some higher Profile. Thus the java.lang.reflect package, e.g., > is in > the Compact1 Profile, but java.lang.management is in the Compact3 Profile." > > But the profile Compact1 states explicitly both java.util and > java.util.logging. > > What about the following packages? > > java.util.concurrent > java.util.concurrent.atomic > java.util.concurrent.locks > java.util.jar > java.util.regex > java.util.spi > java.util.zip > > I think it would be clearer if all subpackages were listed explicitly. > > - Florian > > Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette: > > There have been some questions on this list about Jigsaw, compact > profiles, > > embedded, minimal VMs and the JRE customization tool called jrecreate. > > Richard asked me to jump in to try to clear up any confusion. > > > > Here goes .... > > > > The Java Modularity Project (project Jigsaw) that was originally planned > for > > JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) was > > expecting to use Jigsaw in order to provide smaller customizable Java > > runtimes for embedded devices. Lacking this new functionality, we > decided > > to propose a simpler alternate plan that would enhance the JDK8 > > specification to allow the distribution of a small set of profiles that > are > > subsets of the full Java runtime. These are called Compact Profiles. We > > have proposed three compact profiles. A talk and presentation that I > gave > > at JavaOne describes these profiles. > > > > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8A > > BE54064406AC304AD59/CON4538_Vandette.pdf > > > > The Java Enhancement Proposal (JEP) for this work is here: > > > > http://openjdk.java.net/jeps/161 > > > > The openjdk repository that implements our current prototype is located > > here: > > > > http://hg.openjdk.java.net/jdk8/profiles > > > > The mailing list that discusses the profiles is > > build-infra-dev at openjdk.java.net since the creation of the new profiles > is > > done using the new configure based JDK build system. > > > > This repository allows you to do a build that generates the full JRE, JDK > > but in addition produces three additional image targets (compact1, > > compact2, and compact3). > > > > In order to achieve the smallest Java runtime for embedded (our goal is > > around 10MB), we have applied changes to Hotspot that allow us to build a > > small VM (2-3MB) with reduced functionality. The small VM (minimal) + > > compact1 profile goal we've set is around 10MB. We're at 11MB today. > > > > In addition to the profile bundles and the small VM, we have a reduced > > Embedded FX stack that we'll run on embedded devices such as the > > RaspberryPi. This FX Embedded stack is a compatible FX implementation > > without media and webkit support. The goal for this added stack is 6MB. > > > > The jrecreate tool that some of you have asked about is not a java > stripping > > tool. It's main purpose is to assist the embedded developer in > customizing > > Java runtimes. It allows the developer to select which profile, VM, > > debugging options, compression, security and FX options. It does not > strip > > the full JRE to produce the compact profile. The jrecreate will be > packaged > > with the three compact profile binaries. It simply copies these profiles > > and applies some additional massaging based on the selected options. > > > > We have already pushed the minimal VM changes to JDK8 hotspot and will be > > open sourcing the compact profile changes since they will be a standard > > feature of JDK8 (independent of embedded). The current profile changes > in > > our project repository are only functional for Linux x86. > > > > We certainly recognize the value that small Java runtimes + reduced FX > could > > have on Java applications published on Web App stores, but the current > > immediate plan is that the jrecreate tool is only going to be available > > with our embedded binary downloads since that's where it's needed most. > > I've had some discussions with our Netbeans team to see what it will take > > to make Netbeans profile aware. This might be a good way of taking > > advantage of profiles, reduced FX for producing smaller applications for > > distribution. > > > > I hope this help, > > Bob. > -- 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 Sat Nov 10 10:14:34 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 10 Nov 2012 13:14:34 -0500 Subject: BorderPane ignores managed property? In-Reply-To: <35F7461F-FDE9-443E-90C2-6F0C18C8C903@oracle.com> References: <31DFB4B1-F610-4F30-8F3A-E4EBCA0CDDCF@gmail.com> <35F7461F-FDE9-443E-90C2-6F0C18C8C903@oracle.com> Message-ID: <825C6E55-98D1-4203-A881-3B689E7D4CBC@gmail.com> For the record I believe this is the issue I need to workaround in ScrollPane http://javafx-jira.kenai.com/browse/RT-20698 That is the primary reason we have rolled our own ScrollPane equivalent. We allow dragging of some nodes that are in the content of the ScrollPane and this can cause the content to change size. When the ScrollPane is not positioned at 0 and the content shrinks - it flickers like mad. (It also appears that our version has improved performance, but we are not extending Control and doing it "the right way".) Scott On 2012-11-08, at 7:00 PM, Richard Bair wrote: > Yikes, that would be bad! Sounds like a JIRA is in order (and maybe a simple patch?! :-)). > > Thanks > Richard > > On Nov 8, 2012, at 2:43 PM, Scott Palmer wrote: > >> I did a quick search in Jira but I didn't see this particular issue. It seems that in JavaFX 2.2 BorderPane ignores the managed property. I am rolling my own scroll pane because there is a horrible flickering bug in the standard ScrollPane when the content size changes and the scroll position isn't at 0 (bug report on the way soon). >> >> I have placed ScrollBars in the left and bottom panes of the BorderPane and bound their managed property to the visibility property. The problem is that when I hide the scroll bars they are still taking up the physical space in the BorderPane. >> >> I'm working around the problem by wrapping them in an HBox and VBox - which shrinks to zero size when the contained ScrollBar becomes unmanaged. >> >> Scott > From zonski at gmail.com Sun Nov 11 03:52:12 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 11 Nov 2012 22:52:12 +1100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> Message-ID: Since I first posted this, I have: - pushed this Maven plugin into the central repository so you no longer need to reference my private repository for it. - added a "mvn jfx:fix-classpath" command which puts the jfxrt.jar on the bootclass path (by copying it into the ext directory as per the plan for Java 8) - added an example project that uses the plugin and that can be used as a template/kickstarter. All the details are on the GitHub project: https://github.com/zonski/javafx-maven-plugin I am considering adding things to this project. 1. Richard is there any more word on when the JFX build tools may be open sourced? 2. Danno are you still developing the Gradle plugin (what is it's website)? If so I think it would be good if we standardised on directories for certain things as there are concepts in this type of packaging that Maven hasn't really covered before AFAIK. e.g. where best to put templates for JNLP files and Applet HTML templates, etc. Also including native dependencies can be tough in Maven and a best practice for this would be good, etc. On Sat, Oct 27, 2012 at 2:26 AM, Richard Bair wrote: > 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 knut.arne.vedaa at broadpark.no Sun Nov 11 12:13:42 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Sun, 11 Nov 2012 21:13:42 +0100 Subject: JavaFX plugin for SBT Message-ID: <50A006F6.8010306@broadpark.no> While we're on the topic of build tool plugins, I'd like to mention that I've written a JavaFX plugin for SBT (Simple Build Tool for Scala). It can be used to build both Scala as well as pure-Java JavaFX applications. Minimal configuration, with Maven/Ivy-style dependency management. https://github.com/kavedaa/sbt-javafx It's made as a simple wrapper around the Ant tasks in ant-javafx.jar, which from my perspective works very well. It doesn't implement all possible packaging options yet, but is still functional. I'd be happy to collaborate on possible standarization of directories. Knut Arne Vedaa From zonski at gmail.com Sun Nov 11 20:32:14 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 12 Nov 2012 15:32:14 +1100 Subject: JavaFX plugin for SBT In-Reply-To: <50A006F6.8010306@broadpark.no> References: <50A006F6.8010306@broadpark.no> Message-ID: Looks good. Standardisation would be great wherever appropriate. I'm considering adding JNLP and Applet support to the Maven plugin. For these I think I would like to support: - Auto generation of a JNLP file based on the POM details (with optional templating system to customise it) - Auto generation of a HTML page based on the POM details which links to the JNLP file (with optional templating) - Auto generation of a HTML page based on the POM details for Applet (with optional templating) (I need to look into the existing JFX Packager tooling to see how much of this it does and how much would be new code but regardless this would be the goals) Assuming the Gradle and SBT tools are wanting to do something similar (?) then I guess we need some standard directories for the templates, maybe: src/main/webstart <-- contains jnlp template and html template for launching the jnlp src/main/applet <-- contains html template for launching the jnlp Thoughts? Do you guys use the 'target' directory as the output directory in Gradle or SBT? Do we need to standardise on output directories, or is this every man for himself? Currently I'm using target/javafx as the base of the output - unless there are objections I will look at putting each "bundle" under there, along the lines of: target/javafx/jar target/javafx/webstart target/javafx/applet target/javafx/installer target/javafx/installer/win/win-x86 target/javafx/installer/win/win-x64 Not sure whether the JFX packaging tools will let me actually do this without customisations - will see. Waiting on that open sourcing to happen before doing too much of the above though... From richard.bair at oracle.com Sun Nov 11 20:51:53 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Nov 2012 05:51:53 +0100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> Message-ID: <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> > 1. Richard is there any more word on when the JFX build tools may be open sourced? Scott is moving forward on this. He has made some progress last week in breaking out packager into a separate location from the plugin code and updating build scripts. From zonski at gmail.com Sun Nov 11 21:02:44 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 12 Nov 2012 16:02:44 +1100 Subject: JavaFX Maven Plugin In-Reply-To: <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> Message-ID: Good news. I know it's not in the Oracle style but is it at all possible to translate that into a ballpark estimate of time frame (i.e. if it's a few days away I'll wait, if it's a month or more away I'll keep going with the reflection based approach)? I'm also hoping that the actual native code behind the custom launchers (included in each native bundle) will be included in the Open Sourced code - if not straight away then at least soon after? On Mon, Nov 12, 2012 at 3:51 PM, Richard Bair wrote: > > > > 1. Richard is there any more word on when the JFX build tools may be > open sourced? > > Scott is moving forward on this. He has made some progress last week in > breaking out packager into a separate location from the plugin code and > updating build scripts. From richard.bair at oracle.com Sun Nov 11 23:55:42 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Nov 2012 08:55:42 +0100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> Message-ID: I'm getting an estimate from the manager / engineer, but I don't expect it to be more than a week or so. I believe this is the entire packager code. Richard On Nov 12, 2012, at 6:02 AM, Daniel Zwolenski wrote: > Good news. > > I know it's not in the Oracle style but is it at all possible to translate that into a ballpark estimate of time frame (i.e. if it's a few days away I'll wait, if it's a month or more away I'll keep going with the reflection based approach)? > > I'm also hoping that the actual native code behind the custom launchers (included in each native bundle) will be included in the Open Sourced code - if not straight away then at least soon after? > > > On Mon, Nov 12, 2012 at 3:51 PM, Richard Bair wrote: >> >> >> > 1. Richard is there any more word on when the JFX build tools may be open sourced? >> >> Scott is moving forward on this. He has made some progress last week in breaking out packager into a separate location from the plugin code and updating build scripts. > From zonski at gmail.com Mon Nov 12 00:19:17 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 12 Nov 2012 19:19:17 +1100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> Message-ID: Awesome, thanks. On 12/11/2012, at 6:55 PM, Richard Bair wrote: > I'm getting an estimate from the manager / engineer, but I don't expect it to be more than a week or so. I believe this is the entire packager code. > > Richard > > On Nov 12, 2012, at 6:02 AM, Daniel Zwolenski wrote: > >> Good news. >> >> I know it's not in the Oracle style but is it at all possible to translate that into a ballpark estimate of time frame (i.e. if it's a few days away I'll wait, if it's a month or more away I'll keep going with the reflection based approach)? >> >> I'm also hoping that the actual native code behind the custom launchers (included in each native bundle) will be included in the Open Sourced code - if not straight away then at least soon after? >> >> >> On Mon, Nov 12, 2012 at 3:51 PM, Richard Bair wrote: >> >> >> > 1. Richard is there any more word on when the JFX build tools may be open sourced? >> >> Scott is moving forward on this. He has made some progress last week in breaking out packager into a separate location from the plugin code and updating build scripts. >> From scott.kovatch at oracle.com Mon Nov 12 08:12:52 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 12 Nov 2012 08:12:52 -0800 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> Message-ID: <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> On Nov 11, 2012, at 9:02 PM, Daniel Zwolenski wrote: > Good news. > > I know it's not in the Oracle style but is it at all possible to translate > that into a ballpark estimate of time frame (i.e. if it's a few days away > I'll wait, if it's a month or more away I'll keep going with the reflection > based approach)? > > I'm also hoping that the actual native code behind the custom launchers > (included in each native bundle) will be included in the Open Sourced code > - if not straight away then at least soon after? Yes, all of the C/Objective-C for starting up the VM and running your application, as well as the ant task for assembling the app bundle is being open-sourced. The 'deploy' repository also has the DeployToolkit and Java launcher additions so your app works properly on older JREs. Now that JavaFX will be included with the JRE, the wrappers may no longer be necessary, but one step at a time. I have to check on something with the deploy team but we should be able to sort it out pretty quickly. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From lehmann at media-interactive.de Mon Nov 12 09:48:51 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 12 Nov 2012 18:48:51 +0100 Subject: 7u10 Message-ID: <50A13683.9080908@media-interactive.de> Hi, is there already a release date for 7u10? The FX roadmap mentions 7u6 only... Rgds Werner From kevin.rushforth at oracle.com Mon Nov 12 10:15:39 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Nov 2012 10:15:39 -0800 Subject: 7u10 In-Reply-To: <50A13683.9080908@media-interactive.de> References: <50A13683.9080908@media-interactive.de> Message-ID: <50A13CCB.7050500@oracle.com> JDK 7u10 + FX 2.2.4 will be released around the end of this year (I don't know if there is a published release date), and only contains critical fixes. EA builds are available at: http://jdk7.java.net/download.html The next 7 update release -- JDK 7u12 + FX 2.2.6 is planned for spring of 2013. -- Kevin Werner Lehmann wrote: > Hi, > > is there already a release date for 7u10? The FX roadmap mentions 7u6 > only... > > Rgds > Werner From hang.vo at oracle.com Mon Nov 12 11:48:42 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 12 Nov 2012 19:48:42 +0000 Subject: hg: openjfx/8/graphics/rt: com.sun.glass.taskbarApplication system property is renamed to glass.taskbarApplication Message-ID: <20121112194848.1A436478F3@hg.openjdk.java.net> Changeset: 194fe6a98a4a Author: Artem Ananiev Date: 2012-11-12 11:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/194fe6a98a4a com.sun.glass.taskbarApplication system property is renamed to glass.taskbarApplication ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java From danno.ferrin at shemnon.com Mon Nov 12 14:16:35 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 12 Nov 2012 15:16:35 -0700 Subject: JavaFX plugin for SBT In-Reply-To: References: <50A006F6.8010306@broadpark.no> Message-ID: On Sun, Nov 11, 2012 at 9:32 PM, Daniel Zwolenski wrote: > Looks good. Standardisation would be great wherever appropriate. > > I'm considering adding JNLP and Applet support to the Maven plugin. For > these I think I would like to support: > > - Auto generation of a JNLP file based on the POM details (with optional > templating system to customise it) > - Auto generation of a HTML page based on the POM details which links to > the JNLP file (with optional templating) > - Auto generation of a HTML page based on the POM details for Applet > (with optional templating) > There also needs to be a "use this file" support. Auto-generation is nice but sometimes there are random things that have to be put in for random reasons that the conventions don't support. > (I need to look into the existing JFX Packager tooling to see how much of > this it does and how much would be new code but regardless this would be > the goals) > The JNLP is auto generated based on what you pass into the ant task. > > Assuming the Gradle and SBT tools are wanting to do something similar (?) > then I guess we need some standard directories for the templates, maybe: > > src/main/webstart <-- contains jnlp template and html template for > launching the jnlp > src/main/applet <-- contains html template for launching the jnlp > > Thoughts? > Right now I have the gradle plugin set up for src/main/package/, mostly so I can point the jfx deployer at src/main. The ant task sniffs for package/ in the classpath, so that is why I did id that way. > > > Do you guys use the 'target' directory as the output directory in Gradle or > SBT? Do we need to standardise on output directories, or is this every man > for himself? > Gradle defaults to 'build' and has a different sub-structure from Maven. SBT uses 'target'. > Currently I'm using target/javafx as the base of the output - unless there > are objections I will look at putting each "bundle" under there, along the > lines of: > > target/javafx/jar > target/javafx/webstart > target/javafx/applet > target/javafx/installer > target/javafx/installer/win/win-x86 > target/javafx/installer/win/win-x64 > > Not sure whether the JFX packaging tools will let me actually do this > without customisations - will see. > > Waiting on that open sourcing to happen before doing too much of the above > though... > The Gradle plugin uses build/distributions/bundles/. The bundles part is from the jfx deploy tasks and the distributions part is a gradle thing. I don't like target/javafx. My main reason is that the random user who clones a github project and builds it locally shouldn't be reminded at every turn of the particular choice of GUI toolkit. I feel we should try to model off of what other plugins have done with regard to native deployments. For example, the Maven DMG plugin ( http://mojo.codehaus.org/osxappbundle-maven-plugin) uses src/main/app-resources for soruce data and drops the DMG directly into target/ My first set of patches off the distribution code will likely be code to allow us to change some of the hard coded input and output directories, so we can do src/main/app-resources/ and drop stuff info target/installers directly. And turn off JNLP unless asked for explicitly. -- 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 knut.arne.vedaa at broadpark.no Mon Nov 12 15:27:09 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Tue, 13 Nov 2012 00:27:09 +0100 Subject: JavaFX plugin for SBT In-Reply-To: References: <50A006F6.8010306@broadpark.no> Message-ID: <50A185CD.9020706@broadpark.no> What I do in the SBT plugin is that I generate a build.xml file that contains and task definitions, and pass on plugin-defined settings from the project's .sbt build file to these tasks, then run Ant on it. This means that I am at the mercy of the JavaFX packaging Ant tasks when it comes to what can be configured and what can not. It also means that the output will resemble quite closely the output from building in Netbeans. I'm gonna rely on this simple approach unless very specific needs arise that cannot be accomplished with it. SBT uses src/ for input and target/ for output (by default, can be customized). So src/main/scala will contain Scala sources, and src/main/java will contains Java sources, you could easily have src/main/javafx contain JavaFX specific stuff, src/main/native contain native .dll's etc. How I do it so far: * Input I'm not quite sure what you mean with "JNLP template". If you mean the options that can be passed to the task, these are configured in the .sbt build file. The name and location of a possible HTML template can also be configured, and is treated as relative to the project's base directory if it is a relative path. It could make sense to treat this as relative to src/main/html, src/main/template, src/main/javafx or something instead. * Output There are four types of output: a) Standalone jar app, which consists of a jar-file and an optional lib/ folder with library jars. b) JNLP app, which consists of a) PLUS a JNLP file. c) Applet, which consists of b) PLUS an HTML file. d) Native bundles. The task, given correct configuration, can spit out all of the above in a directory of your choosing. This behaviour is the same as when building from Netbeans. I'm not sure if much can be gained by trying to circumvent this. The standard SBT output directory is target/, or target/ if you're cross-building (which is the default). As of now I direct the packager to put its output in target/, where artifactname is configurable in SBT and defaults roughly to , e.g. if you set name to "my-app" and version to "1.0", you will (if you turn off cross-building) have a target/my-app-1.0/ directory with a my-app-1.0.jnlp file, a my-app-1.0.jar file, a HTML file and possibly a lib/ directory, and possibly some native bundles as well (haven't looked into this yet). Much of this could be a matter of taste though. (Is this thread relevant for the open-jfx list, or should we move it to private email?) Knut Arne From tom.schindl at bestsolution.at Mon Nov 12 15:46:08 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 13 Nov 2012 00:46:08 +0100 Subject: JavaFX plugin for SBT In-Reply-To: <50A185CD.9020706@broadpark.no> References: <50A006F6.8010306@broadpark.no> <50A185CD.9020706@broadpark.no> Message-ID: Von meinem iPhone gesendet Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa : > What I do in the SBT plugin is that I generate a build.xml file that contains and task definitions, and pass on plugin-defined settings from the project's .sbt build file to these tasks, then run Ant on it. This is the way e(fx)clipse works as well and it works without problems. Beside that we allow people to configure the generation in an extra XML-File. Tom From zonski at gmail.com Mon Nov 12 17:01:07 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 13 Nov 2012 12:01:07 +1100 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) Message-ID: > Is this thread relevant for the open-jfx list, or should we move it to private email? Seems relevant to me given that a lot of this relates back to the structure of the official JFX packaging tools, how they will be used and what features they should have built in. If anyone has any objections though, let us know and we'll take it off list. > What I do in the SBT plugin is that I generate a build.xml file that contains and task definitions, and pass on plugin-defined settings from the project's .sbt build file to these tasks, then run Ant on it. The Maven plugin calls directly onto the packaging tool code (which the ANT tasks call onto internally), cutting out the ANT middle man. > There also needs to be a "use this file" support. Auto-generation is nice but sometimes there are random things that have to be put in for random reasons that the conventions don't support. That's what I was meaning by "JNLP templating". My current thinking is to use Velocity to generate the JNLP template and pass in known replacement variables. If a custom template exists in the project (e.g. in src/main/webstart/jnlp-template.vm) then it will automagically use this. If none is supplied then it uses a built-in default one to produce a standard jnlp file. I'm intending to do something similar for generating a HTML file for Applet deployment, and also a HTML file to launch the JNLP. The idea being that the developer can just upload the HTML, JAR and JNLP to a server and it is ready for action. I wrote the first half of this code last night - hopefully will have it working sometime next week. Currently I am completely bypassing the JFX tool for JNLP and Applets as it is too limited. My first question is whether anyone else is interested in doing the same templating stuff in their build tools or whether you want to stick to just wrappering the more limited functionality of the JFX packaging tools? If no one else is interested, I'll just bundle this in my plugin code. If others want to do the same thing then I can section off this code as a Maven independent GitHub project or we could look at whether it's possible to move it into the base JFX tools (not sure that's such a great idea though). > The ant task sniffs for package/ in the classpath, so that is why I did id that way. Makes sense as a starting point. I'm hoping once we get the open source code we will be able to change the defaults a bit and make it more configurable. I'd rather us come up with good standards and change the tools to meet, rather than just doing what the ant tools do as I don't think they were built with cross-tool standards in mind. On a side note, I'd definitely like the 'bundle' part of the code to be more flexible so that we can turn on and off specific native installers via params passed in. i.e. I'd like to be able to explicitly call the method to build the MSI or the EXE not have to pass in a parameter of "ALL" or "IMAGE" which could mean anything on any platform, etc. > I don't like target/javafx. Fair call, I'm not especially wed to it > For example, the Maven DMG plugin ( http://mojo.codehaus.org/osxappbundle-maven-plugin) uses src/main/app-resources for soruce data and drops the DMG directly into target/ I like the simplicity of putting the natives directly in the target directory. We'd need a naming scheme though to differentiate between x86 and x64 MSI for example. Easy enough. With JNLP and Applet though the bundles are not a single file, it's HTML plus JNLP plus JAR (at a minimum). Does it make sense to bundle these straight in target? or a zip for applet another zip for webstart (or a combined zip with both)? or do sub directories make sense for these? In Maven land I might also have to think about what to do with JNLP and Applet if the packaging type is 'war' file. I might need to think about that one a bit more. > Much of this could be a matter of taste though. Definitely. Would be good if we can standardise it but if our tastes differ too much well then probably not worth going round in circles about it too much and just do what we think best. Keen to work out what the preferences are at least, and so far this has been a useful conversation for me. On Tue, Nov 13, 2012 at 10:46 AM, Tom Schindl wrote: > > > Von meinem iPhone gesendet > > Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa < > knut.arne.vedaa at broadpark.no>: > > > What I do in the SBT plugin is that I generate a build.xml file that > contains and task definitions, and pass on > plugin-defined settings from the project's .sbt build file to these tasks, > then run Ant on it. > > This is the way e(fx)clipse works as well and it works without problems. > Beside that we allow people to configure the generation in an extra > XML-File. > > Tom > From Claus.Luethje at osys.ch Mon Nov 12 23:29:44 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Tue, 13 Nov 2012 07:29:44 +0000 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) In-Reply-To: References: Message-ID: <34E79ADB-36D3-4161-9E99-4B53853861BF@osys.ch> I'm very interested in having Maven support for JavaFX. Having options to use templates will come in handy, I'm sure. We're not ready yet with our project to see if standard tooling is enough. As building and deploying is central for any application, I think this topic belongs on this list. Just my 0.02 ct Claus Am 13.11.2012 um 02:03 schrieb "Daniel Zwolenski" : >> Is this thread relevant for the open-jfx list, or should we move it to > private email? > > Seems relevant to me given that a lot of this relates back to the structure > of the official JFX packaging tools, how they will be used and what > features they should have built in. If anyone has any objections though, > let us know and we'll take it off list. > >> What I do in the SBT plugin is that I generate a build.xml file that > contains and task definitions, and pass on > plugin-defined settings from the project's .sbt build file to these tasks, > then run Ant on it. > > The Maven plugin calls directly onto the packaging tool code (which the ANT > tasks call onto internally), cutting out the ANT middle man. > >> There also needs to be a "use this file" support. Auto-generation is > nice but sometimes there are random things that have to be put in > for random reasons that the conventions don't support. > > That's what I was meaning by "JNLP templating". My current thinking is to > use Velocity to generate the JNLP template and pass in known replacement > variables. If a custom template exists in the project (e.g. in > src/main/webstart/jnlp-template.vm) then it will automagically use this. If > none is supplied then it uses a built-in default one to produce a standard > jnlp file. > > I'm intending to do something similar for generating a HTML file for Applet > deployment, and also a HTML file to launch the JNLP. The idea being that > the developer can just upload the HTML, JAR and JNLP to a server and it is > ready for action. > > I wrote the first half of this code last night - hopefully will have it > working sometime next week. Currently I am completely bypassing the JFX > tool for JNLP and Applets as it is too limited. > > My first question is whether anyone else is interested in doing the same > templating stuff in their build tools or whether you want to stick to just > wrappering the more limited functionality of the JFX packaging tools? > > If no one else is interested, I'll just bundle this in my plugin code. If > others want to do the same thing then I can section off this code as a > Maven independent GitHub project or we could look at whether it's possible > to move it into the base JFX tools (not sure that's such a great idea > though). > >> The ant task sniffs for package/ in the classpath, so that is > why I did id that way. > > Makes sense as a starting point. I'm hoping once we get the open source > code we will be able to change the defaults a bit and make it more > configurable. I'd rather us come up with good standards and change the > tools to meet, rather than just doing what the ant tools do as I don't > think they were built with cross-tool standards in mind. > > On a side note, I'd definitely like the 'bundle' part of the code to be > more flexible so that we can turn on and off specific native installers via > params passed in. i.e. I'd like to be able to explicitly call the method to > build the MSI or the EXE not have to pass in a parameter of "ALL" or > "IMAGE" which could mean anything on any platform, etc. > >> I don't like target/javafx. > > Fair call, I'm not especially wed to it > >> For example, the Maven DMG plugin ( > http://mojo.codehaus.org/osxappbundle-maven-plugin) > uses src/main/app-resources for soruce data and drops the DMG directly into > target/ > > I like the simplicity of putting the natives directly in the target > directory. We'd need a naming scheme though to differentiate between x86 > and x64 MSI for example. Easy enough. > > With JNLP and Applet though the bundles are not a single file, it's HTML > plus JNLP plus JAR (at a minimum). Does it make sense to bundle these > straight in target? or a zip for applet another zip for webstart (or a > combined zip with both)? or do sub directories make sense for these? > > In Maven land I might also have to think about what to do with JNLP and > Applet if the packaging type is 'war' file. I might need to think about > that one a bit more. > >> Much of this could be a matter of taste though. > > Definitely. Would be good if we can standardise it but if our tastes differ > too much well then probably not worth going round in circles about it too > much and just do what we think best. Keen to work out what the preferences > are at least, and so far this has been a useful conversation for me. > > > > > > > On Tue, Nov 13, 2012 at 10:46 AM, Tom Schindl > wrote: > >> >> >> Von meinem iPhone gesendet >> >> Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa < >> knut.arne.vedaa at broadpark.no>: >> >>> What I do in the SBT plugin is that I generate a build.xml file that >> contains and task definitions, and pass on >> plugin-defined settings from the project's .sbt build file to these tasks, >> then run Ant on it. >> >> This is the way e(fx)clipse works as well and it works without problems. >> Beside that we allow people to configure the generation in an extra >> XML-File. >> >> Tom >> From lehmann at media-interactive.de Tue Nov 13 03:08:01 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 13 Nov 2012 12:08:01 +0100 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) In-Reply-To: <34E79ADB-36D3-4161-9E99-4B53853861BF@osys.ch> References: <34E79ADB-36D3-4161-9E99-4B53853861BF@osys.ch> Message-ID: <50A22A11.109@media-interactive.de> Hi, let me hijack this thread to share a little detail I learned about the task the other day. For the manifest I needed to reference dependency jars from several different directories. Those jars are also used for compilation so I have an Ant resource collection for those already: ... ... ... Using Ant's pathconvert I can convert this into a string suitable for the manifest class-path attribute. Now, with the documentation indicates that I should use to list jars needed for the class-path (or, JavaFX-Class-Path is what it actually generates). Unfortunately, is not compatible with Ant's resources, and it cannot reference them, let alone offer the flexibility of pathconvert, e.g. to prefix each jar in the path. So my nice and existing and lengthy resource collection did not work and I'd have to repeat all that for . This is a problem for Maven as well, it seems: > http://myjavafx.blogspot.de/2012/08/building-signing-and-deploying-your.html This blog post showed that you can simply ignore and continue to provide the class-path yourself. It wouldn't have occurred to me :) So I can still do this: Whereas my.dist-classpath is provided by pathconvert (with a chainedmapper, flattenmapper, globmapper) and generated from myjars. Might be useful for somebody. Rgds Werner From zonski at gmail.com Tue Nov 13 04:42:23 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 13 Nov 2012 23:42:23 +1100 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) In-Reply-To: <50A22A11.109@media-interactive.de> References: <34E79ADB-36D3-4161-9E99-4B53853861BF@osys.ch> <50A22A11.109@media-interactive.de> Message-ID: Thanks for the tip Werner but the Maven post you referenced is using a work around by calling the ANT tasks from within Maven (roughly on par with calling a Make file from within ANT - i.e. a last resort). The Maven plugin I have built is intended to completely replace these sorts of work arounds so it won't need that trick you outlined. Hopefully no one should ever have to worry about resource stuff like that in Maven land. For anyone who is interested I moved my early/work-in-progress code for generating a JNLP from a velocity template to a separate GitHub project: https://github.com/zonski/javafx-deploy-lib At this stage it just generates a simple JNLP file based on a default template or a custom one and parameters that you pass in. There are no Maven dependencies or anything Maven specific to it. The idea being that this could be reused in Gradle, SBT, or even ANT if anyone wants to do that. I will be growing this over the next week or so and then making my Maven plugin call onto this (deriving the settings from the POM). Let me know if anyone is interested in working on this, as the level of doco, etc, that I go for will depend on whether it's just me using it or others as well. Obviously if anyone wants to chip in and contribute we'll all make a lot faster progress working on this common module together. If you've worked out how the packaging code works then you should have no trouble working out what's going on in this one too. Basically this is a direct alternative to calling onto the built-in JFX tools. I plan to extend this to generate HTML for webstart and applets - so the JFX tools will be totally bypassed in Maven land for Applets and JNLP. The more I dig into the official packaging tools the more I'm thinking it would be better just to recreate them as a true open source project without all the weird stuff and ant-focused design, not to mention Oracle red tape and very slow release cycle. JNLP and Applet are easily rebuilt, JAR shouldn't be much of an issue. Native would be a bigger job but that stuff really could do with a ground-up rebuild to make it clean, modular and customisable anyway. Maybe I'll get to this, maybe I won't. In these early stages I reserve the right to completely change the code that's in there as I work out what I need. I'll start putting up snapshot builds soon and only once its stable enough release it into the central repo. I went for the GPL licence so that it can be used in the same boat as the OpenJDK stuff but I don't really care. If anyone wants/needs an alternate licence, let me know. On Tue, Nov 13, 2012 at 10:08 PM, Werner Lehmann < lehmann at media-interactive.de> wrote: > Hi, > > let me hijack this thread to share a little detail I learned about the > task the other day. For the manifest I needed to reference > dependency jars from several different directories. Those jars are also > used for compilation so I have an Ant resource collection for those already: > > > > > ... > > > ... > > ... > > > Using Ant's pathconvert I can convert this into a string suitable for the > manifest class-path attribute. Now, with the documentation > indicates that I should use to list jars needed for the > class-path (or, JavaFX-Class-Path is what it actually generates). > > Unfortunately, is not compatible with Ant's resources, and > it cannot reference them, let alone offer the flexibility of pathconvert, > e.g. to prefix each jar in the path. So my nice and existing and lengthy > resource collection did not work and I'd have to repeat all that for > . > > This is a problem for Maven as well, it seems: > >> http://myjavafx.blogspot.de/**2012/08/building-signing-and-** >> deploying-your.html >> > > This blog post showed that you can simply ignore and > continue to provide the class-path yourself. It wouldn't have occurred to > me :) > > So I can still do this: > > > > > > > > > > > Whereas my.dist-classpath is provided by pathconvert (with a > chainedmapper, flattenmapper, globmapper) and generated from myjars. > > Might be useful for somebody. > > Rgds > Werner > > From hang.vo at oracle.com Tue Nov 13 05:48:55 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 13 Nov 2012 13:48:55 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26126 Popup menus stopped working Message-ID: <20121113134857.1849F47927@hg.openjdk.java.net> Changeset: 5ca1d6e4604d Author: Martin Sladecek Date: 2012-11-13 14:40 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5ca1d6e4604d RT-26126 Popup menus stopped working ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java From knut.arne.vedaa at broadpark.no Tue Nov 13 06:08:17 2012 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Tue, 13 Nov 2012 15:08:17 +0100 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) In-Reply-To: References: Message-ID: <50A25451.9000405@broadpark.no> On 13.11.2012 02:01, Daniel Zwolenski wrote: > I wrote the first half of this code last night - hopefully will have it > working sometime next week. Currently I am completely bypassing the JFX > tool for JNLP and Applets as it is too limited. Could you elaborate on what you find limited? I'm just curious. > My first question is whether anyone else is interested in doing the same > templating stuff in their build tools or whether you want to stick to > just wrappering the more limited functionality of the JFX packaging tools? As I said, I'll probably stick to the Ant-based approach unless or until there are specific things I find that I cannot do with it. Knut Arne From hang.vo at oracle.com Tue Nov 13 10:04:09 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 13 Nov 2012 18:04:09 +0000 Subject: hg: openjfx/8/graphics/rt: 10 new changesets Message-ID: <20121113180421.AFB1F47934@hg.openjdk.java.net> Changeset: 2eccad815147 Author: ptbrunet Date: 2012-11-05 22:00 -0600 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2eccad815147 clean up some logging ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleNode.java ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleStage.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleControl.java Changeset: 6a40a582b6fd Author: ptbrunet Date: 2012-11-05 22:01 -0600 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a40a582b6fd merged Changeset: 36a55281a823 Author: leifs Date: 2012-11-06 10:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/36a55281a823 RT-138: Support component orientation in common UI controls ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java + javafx-ui-common/src/javafx/geometry/NodeOrientation.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CheckBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: df9a24643d20 Author: Paru Somashekar Date: 2012-11-06 15:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/df9a24643d20 fix RT-25899 & RT-21165 ! javafx-ui-charts/src/javafx/scene/chart/BubbleChart.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 744a754668fa Author: Paru Somashekar Date: 2012-11-08 19:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/744a754668fa Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: fd48b9d9cb2b Author: David Grieve Date: 2012-11-09 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fd48b9d9cb2b RT-26165: Need to call impl_getAllParentStylesheets when updating stylesheets for a Parent. ! javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 9b926fb92fcf Author: David Grieve Date: 2012-11-09 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b926fb92fcf RT-25607: When looking up a font style, consider the inline styles of parent nodes ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: edf3703cb202 Author: David Grieve Date: 2012-11-09 10:17 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/edf3703cb202 missed changes from last patch. ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_UA.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: 952f2115ae99 Author: Paru Somashekar Date: 2012-11-09 23:27 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/952f2115ae99 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 38b5c364c630 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-13 09:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/38b5c364c630 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From paul at nosphere.org Wed Nov 14 02:23:25 2012 From: paul at nosphere.org (Paul Merlin) Date: Wed, 14 Nov 2012 11:23:25 +0100 Subject: JavaFX Maven Plugin In-Reply-To: <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> Message-ID: <50A3711D.3010506@nosphere.org> Gents, I had to use JavaFX and Maven in a university course and for a company project lately but the current plugin do not support maven enough for my needs so I wrote another javafx plugin that don't rely on reflection and has more maven features. Currently it does the following: - support many configurations properties - allow execution of JavaFX applications using exec-maven-plugin - package and attach JNLP/Applet distributions - package and attach images distributions - package and attach installers distributions As produced distributions are attached to the build the plugin can be used to roll releases using the maven mechanisms. All this was easier because it's not using reflection. The drawback here is that my plugin force you to add dependencies to javafx artifacts to your POM. https://github.com/eskatos/javafx-maven-plugin The README explain how to use the plugin. Daniel is aware of my work on this and we certainly will combine our efforts at some point (this should occur when the build tools are opensourced). For now developpers have the choice between the two approaches. BTW I have one question. JavaFX will be included in JavaSE classpath at some point (7uX, 8?). People building against Java versions published before this change will still have to explicitely depend on JavaFX to build their applications, don't they? Regards /Paul From zonski at gmail.com Wed Nov 14 04:44:49 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 14 Nov 2012 23:44:49 +1100 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) In-Reply-To: References: Message-ID: I have added more to the JNLP generation in https://github.com/zonski/javafx-deploy-lib It now uses Velocity to generate both a JNLP and a HTML file (linking to the JNLP) from settings passed into it. I have also done some work in integrating this into my Maven plugin: https://github.com/zonski/javafx-maven-plugin This work is all checked in and working in a rough form. I've not yet pushed it into any Maven repo though so at this stage you have to get the source out to do anything with it (I'll try to get at least snapshots up over the weekend). If you want to generate a webstart bundle, just add to your POM's plugin configuration. You can add settings if you want, but in general it will take info from the POM (such as name, vendor, organisation, etc). The jnlp and html files will be generated in "target/webstart" The generated JNLP and HTML look ok but the resulting app won't actually launch yet as they are missing some of the magic attributes now required by JFX. This is really just a case of updating the default template file to look like what comes out of the JFX packaging tools. Should be easy, hopefully over the weekend. Signing the jar is a separate problem though, probably won't sort that out this weekend. I like this templating approach a lot better than the JFX tools. With the JFX ones you get what comes out and don't get any real say in this. In this code you can provide a custom velocity template for both the JNLP and the HTML and you can completely design it how you want (and you have available to you all the settings/parameters used to generate the JNLP). Rolling the same strategy out for Applets should be easy, and down the track adding a template-based HTML file that helps users download the appropriate native installer for their system might also be a nice thing to have. In response to Knut, it's the static nature of the output of the JFX tools that I find limiting. This templating is one example, but also control over a lot of things like output directories, even fine grained security settings, etc is not currently supported by the JFX tools. The tools could obviously be extended to support them, but there are several limitations to this (e.g. can we use a third party library such as velocity?). My biggest worry though would be the very slow release cycle to the tools - as soon as it is open sourced we will be able to fix up a lot of the obvious holes but it could be months (or years) before these fixes make it into an official release. What's more we can never guarantee which version of the tools the user will have (are they using JDK1.7 or JDK1.8, etc?) so we cannot link to specific features. Having a separate open source project with stand alone build tools works better for me. Feel free to use them if you want, but calling straight onto the ant files is definitely a fine and simple option if that's what you prefer. On Tue, Nov 13, 2012 at 12:01 PM, Daniel Zwolenski wrote: > > Is this thread relevant for the open-jfx list, or should we move it to > private email? > > Seems relevant to me given that a lot of this relates back to the > structure of the official JFX packaging tools, how they will be used and > what features they should have built in. If anyone has any objections > though, let us know and we'll take it off list. > > > What I do in the SBT plugin is that I generate a build.xml file that > contains and task definitions, and pass on > plugin-defined settings from the project's .sbt build file to these tasks, > then run Ant on it. > > The Maven plugin calls directly onto the packaging tool code (which the > ANT tasks call onto internally), cutting out the ANT middle man. > > > There also needs to be a "use this file" support. Auto-generation is > nice but sometimes there are random things that have to be put in > for random reasons that the conventions don't support. > > That's what I was meaning by "JNLP templating". My current thinking is to > use Velocity to generate the JNLP template and pass in known replacement > variables. If a custom template exists in the project (e.g. in > src/main/webstart/jnlp-template.vm) then it will automagically use this. If > none is supplied then it uses a built-in default one to produce a standard > jnlp file. > > I'm intending to do something similar for generating a HTML file for > Applet deployment, and also a HTML file to launch the JNLP. The idea being > that the developer can just upload the HTML, JAR and JNLP to a server and > it is ready for action. > > I wrote the first half of this code last night - hopefully will have it > working sometime next week. Currently I am completely bypassing the JFX > tool for JNLP and Applets as it is too limited. > > My first question is whether anyone else is interested in doing the same > templating stuff in their build tools or whether you want to stick to just > wrappering the more limited functionality of the JFX packaging tools? > > If no one else is interested, I'll just bundle this in my plugin code. If > others want to do the same thing then I can section off this code as a > Maven independent GitHub project or we could look at whether it's possible > to move it into the base JFX tools (not sure that's such a great idea > though). > > > The ant task sniffs for package/ in the classpath, so that is > why I did id that way. > > Makes sense as a starting point. I'm hoping once we get the open source > code we will be able to change the defaults a bit and make it more > configurable. I'd rather us come up with good standards and change the > tools to meet, rather than just doing what the ant tools do as I don't > think they were built with cross-tool standards in mind. > > On a side note, I'd definitely like the 'bundle' part of the code to be > more flexible so that we can turn on and off specific native installers via > params passed in. i.e. I'd like to be able to explicitly call the method to > build the MSI or the EXE not have to pass in a parameter of "ALL" or > "IMAGE" which could mean anything on any platform, etc. > > > I don't like target/javafx. > > Fair call, I'm not especially wed to it > > > For example, the Maven DMG plugin ( > http://mojo.codehaus.org/osxappbundle-maven-plugin) > uses src/main/app-resources for soruce data and drops the DMG directly into > target/ > > I like the simplicity of putting the natives directly in the target > directory. We'd need a naming scheme though to differentiate between x86 > and x64 MSI for example. Easy enough. > > With JNLP and Applet though the bundles are not a single file, it's HTML > plus JNLP plus JAR (at a minimum). Does it make sense to bundle these > straight in target? or a zip for applet another zip for webstart (or a > combined zip with both)? or do sub directories make sense for these? > > In Maven land I might also have to think about what to do with JNLP and > Applet if the packaging type is 'war' file. I might need to think about > that one a bit more. > > > Much of this could be a matter of taste though. > > Definitely. Would be good if we can standardise it but if our tastes > differ too much well then probably not worth going round in circles about > it too much and just do what we think best. Keen to work out what the > preferences are at least, and so far this has been a useful conversation > for me. > > > > > > > On Tue, Nov 13, 2012 at 10:46 AM, Tom Schindl > wrote: > >> >> >> Von meinem iPhone gesendet >> >> Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa < >> knut.arne.vedaa at broadpark.no>: >> >> > What I do in the SBT plugin is that I generate a build.xml file that >> contains and task definitions, and pass on >> plugin-defined settings from the project's .sbt build file to these tasks, >> then run Ant on it. >> >> This is the way e(fx)clipse works as well and it works without problems. >> Beside that we allow people to configure the generation in an extra >> XML-File. >> >> Tom >> > > From zonski at gmail.com Wed Nov 14 05:09:30 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 15 Nov 2012 00:09:30 +1100 Subject: JavaFX Maven Plugin In-Reply-To: <50A3711D.3010506@nosphere.org> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> Message-ID: Hi Paul, Not sure if you came into the group before or after some of the more recent discussions. Probably worth having a flick through the recent archives on the topic of "JavaFX Packaging tools". As discussed somewhat before, the use of reflection was a work around the licencing issues. I'm legally not allowed to put the jar in a public Maven repo so instead I hacked up a solution that looked for the JAR in the JDK and used reflection to call onto it. Crude, but after a year of trying to get better Maven support going in JFX, this was my fallback. There's many ways to skin a cat, and your option is perfectly valid too - basically doing the same search into the JDK but instead of using reflection, installing it into the local repo (and thus avoiding licencing issues, assuming it's a private repo). One small drawback to this for me is that the developer still has to add dependencies to their POM, and as soon as Java 8 (or possibly 7u10) properly add JFX to the classpath those dependencies will need to be removed. In the hack I went for, the mess is hidden from the developer and the pain is all hidden inside my code - easier for the user, harder for me. In any case, I've started on a different tact to the reflection based one anyway. The more I've tried to use the built in JFX tasks, the more limiting I've found them. So now I'm in the process of writing an alternative toolset (https://github.com/zonski/javafx-deploy-lib). At this stage I'm just creating my own JNLP and Applet generators, but if it makes sense and I have the energy I may look at going all the way. Once the JFX tools are open sourced I don't believe there's anything stopping me from taking bits that I like directly out of there if I use the same licence (need to check up on this). So stuff like the signing I might take verbatim but stuff like the JNLP generation, I'll completely replace with something more powerful. Depending on motivation and time, I may also look at doing the native bundling in a different way and also adding Windows 8 Metro support. I'd really like to avoid developers having to download additional tools like WiX for standard builds. This could be a huge amount of work though, so need to look into it before aiming too high (and alternative might be to look at the Maven plugin downloading WiX magically). I've also shot off some questions to the guys building the compact JRE profiles and in theory there is nothing stopping us from getting these working for desktop as well. If we can make that happen then building in compact profile management into the build tool would be another great goal (and maybe even one day being able to build all the cross-platform installers on the one OS - pipe dream). All of this work would also be a necessary pre-cursor to mobile, which I'm still naively holding out hope that this will one day get sorted. A Maven plugin where you just add an extra and tag into it and magically get a distro ready for the app stores would be very nice. If you, or anyone, are interested in working collaboratively on this, I'd be keen for that. My goal is to have a super slick Maven tool that can build production-grade, release-ready JavaFX apps with absolute minimal fuss. If that same code can then be shared between Gradle and other build tools giving developers the full spectrum of choice that would be a good thing in my book. I feel like the deploy-lib is the way to go, rather than wrappering the JFX tools so if you're on board with that basic direction, then join on in. Cheers, Dan On Wed, Nov 14, 2012 at 9:23 PM, Paul Merlin wrote: > Gents, > > I had to use JavaFX and Maven in a university course and for a company > project lately but the current plugin do not support maven enough for my > needs so I wrote another javafx plugin that don't rely on reflection and > has more maven features. > > Currently it does the following: > - support many configurations properties > - allow execution of JavaFX applications using exec-maven-plugin > - package and attach JNLP/Applet distributions > - package and attach images distributions > - package and attach installers distributions > > As produced distributions are attached to the build the plugin can be used > to roll releases using the maven mechanisms. > > All this was easier because it's not using reflection. The drawback here > is that my plugin force you to add dependencies to javafx artifacts to your > POM. > > https://github.com/eskatos/**javafx-maven-plugin > > The README explain how to use the plugin. > > Daniel is aware of my work on this and we certainly will combine our > efforts at some point (this should occur when the build tools are > opensourced). For now developpers have the choice between the two > approaches. > > BTW I have one question. JavaFX will be included in JavaSE classpath at > some point (7uX, 8?). People building against Java versions published > before this change will still have to explicitely depend on JavaFX to build > their applications, don't they? > > Regards > > /Paul > > > From zonski at gmail.com Wed Nov 14 05:17:24 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 15 Nov 2012 00:17:24 +1100 Subject: Compact Profiles for Desktop Message-ID: If anyone is interested in the general direction of compact JRE profiles for desktop (i.e. the work the "embedded" team is doing to make smaller JREs), then see this conversation: http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-November/002335.html Currently the embedded team only have motivation and resources to make this work on linux. There doesn't seem to be any technical hurdles to supporting other OS's though, but someone from the community would need to do the work. I'm going to focus on the Maven tooling for a bit and then see how I go for motivation and time. This area of JRE build scripts, is not an area I'm too crash hot in so it's going to be slow going for me (step 1: install linux) with no guarantee of results. A fair few people said in earlier conversations regarding mobile support that they would happily put their hands up to do this port. Seems to me that this would be the logical first step (I'm assuming a 70MB JRE is not going to cut it for an iPhone app) - so if anyone wants to step up for this, the boots are ready to be put on. From paul at nosphere.org Wed Nov 14 05:46:47 2012 From: paul at nosphere.org (Paul Merlin) Date: Wed, 14 Nov 2012 14:46:47 +0100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> Message-ID: <50A3A0C7.1050704@nosphere.org> Dan, Daniel Zwolenski a ?crit : > Hi Paul, > > Not sure if you came into the group before or after some of the more > recent discussions. Probably worth having a flick through the recent > archives on the topic of "JavaFX Packaging tools". > > As discussed somewhat before, the use of reflection was a work around > the licencing issues. I'm legally not allowed to put the jar in a > public Maven repo so instead I hacked up a solution that looked for > the JAR in the JDK and used reflection to call onto it. Crude, but > after a year of trying to get better Maven support going in JFX, this > was my fallback. > > There's many ways to skin a cat, and your option is perfectly valid > too - basically doing the same search into the JDK but instead of > using reflection, installing it into the local repo (and thus avoiding > licencing issues, assuming it's a private repo). One small drawback to > this for me is that the developer still has to add dependencies to > their POM, and as soon as Java 8 (or possibly 7u10) properly add JFX > to the classpath those dependencies will need to be removed. In the > hack I went for, the mess is hidden from the developer and the pain is > all hidden inside my code - easier for the user, harder for me. Sure, I needed to hack a plugin that use the somewhat limited JavaFX build tools currently available but allowing to roll maven releases plus some other things. I choosed to not use reflection because I needed it working quickly and installing the artifact in the local repository made everything much easier. About the dependency to jfx-rt issue that should go away anytime soon. This dependency should be declared in the provided scope, meaning that even if people will be able to remove it, it should not prevent their project to build. My maven plugin works starting today but is not the panacea, indeed. > In any case, I've started on a different tact to the reflection based > one anyway. The more I've tried to use the built in JFX tasks, the > more limiting I've found them. So now I'm in the process of writing an > alternative toolset (https://github.com/zonski/javafx-deploy-lib). At > this stage I'm just creating my own JNLP and Applet generators, but if > it makes sense and I have the energy I may look at going all the way. > Once the JFX tools are open sourced I don't believe there's anything > stopping me from taking bits that I like directly out of there if I > use the same licence (need to check up on this). So stuff like the > signing I might take verbatim but stuff like the JNLP generation, I'll > completely replace with something more powerful. > > Depending on motivation and time, I may also look at doing the native > bundling in a different way and also adding Windows 8 Metro support. > I'd really like to avoid developers having to download additional > tools like WiX for standard builds. This could be a huge amount of > work though, so need to look into it before aiming too high (and > alternative might be to look at the Maven plugin downloading WiX > magically). Having this in separate projects make sense to me. Like you say below this would allow different build systems (ant, maven, gradle, sbt ...) to reuse this. I agree that it should help with the release cycle issue too. Downloading needed tools and instrumenting them can surely be done. WiX provide a zipped binary distribution without installer and it is command line driven so it should be pretty straight forward. Another example of what could be easily added is producing .deb packages for Debian based Linux distributions. > I've also shot off some questions to the guys building the compact JRE > profiles and in theory there is nothing stopping us from getting these > working for desktop as well. If we can make that happen then building > in compact profile management into the build tool would be another > great goal (and maybe even one day being able to build all the > cross-platform installers on the one OS - pipe dream). All of this > work would also be a necessary pre-cursor to mobile, which I'm still > naively holding out hope that this will one day get sorted. A Maven > plugin where you just add an extra and tag into it and > magically get a distro ready for the app stores would be very nice. > > If you, or anyone, are interested in working collaboratively on this, > I'd be keen for that. My goal is to have a super slick Maven tool that > can build production-grade, release-ready JavaFX apps with absolute > minimal fuss. If that same code can then be shared between Gradle and > other build tools giving developers the full spectrum of choice that > would be a good thing in my book. I feel like the deploy-lib is the > way to go, rather than wrappering the JFX tools so if you're on board > with that basic direction, then join on in. Seems to be the way to go and looks exciting. I'm in, waiting for the JavaFX build tools to be opensourced, then we'll see what's next. /Paul From tobi at ultramixer.com Wed Nov 14 09:57:38 2012 From: tobi at ultramixer.com (Tobi) Date: Wed, 14 Nov 2012 18:57:38 +0100 Subject: JavaFX: Stage and Unified Toolbars on Mac (apple.awt.brushMetalLook for JavaFX) In-Reply-To: <50A3C384.6030503@oracle.com> References: <50A3B551.7040707@oracle.com> <50A3C384.6030503@oracle.com> Message-ID: Hi, how can I make an JavaFX app with an unified toolbar like on Swing with "apple.awt.brushMetalLook" There was a discussion a few month ago here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-February/000776.html Any news about this feature? Best regards, Tobi From hang.vo at oracle.com Wed Nov 14 11:04:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 14 Nov 2012 19:04:24 +0000 Subject: hg: openjfx/8/graphics/rt: [ECLISPE_ONLY] removing old classpath & project files Message-ID: <20121114190427.6A14A47976@hg.openjdk.java.net> Changeset: 6948b1cc29c5 Author: Felipe Heidrich Date: 2012-11-14 10:54 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6948b1cc29c5 [ECLISPE_ONLY] removing old classpath & project files - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project From richard.bair at oracle.com Wed Nov 14 14:04:10 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 14 Nov 2012 23:04:10 +0100 Subject: Contribution to OpenJFX In-Reply-To: <1352235736.4054.2.camel@pegasus> References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> <1352235736.4054.2.camel@pegasus> Message-ID: On Nov 6, 2012, at 10:02 PM, Mario Torre wrote: > Il giorno mar, 06/11/2012 alle 07.32 -0800, Richard Bair ha scritto: >> Hi Deepak, >> >> This is great news! I don't know if Mario / Roman or any other RedHat engineers working on this will be at Devoxx? I'm planning on spending most of Tuesday at the Devoxx Hackergarten working on upgrading the build. Also, we should have the javafx packager (which does the native application co-bundles) open sourced this week. >> >> Cheers! >> Richard > > Hi Richard, > > Unfortunately we won't be at Devoxx but I've seen the discussion going > on and is very welcomed news! > > I think the native packager is an interesting challenge to include in > Linux distributions, indeed a very good starting point. > > Does it depend on other JavaFX code internally or is a standalone tool? I think it is standalone. Scott? > Once we get back (we are in Toronto now) I'll write also some followup > to sync about the actual status of the build refactoring (including the > new build tool). Cool. I met with Hans Docktor (Mr Gradle) on Tuesday and he was awesome help (thanks Hans!) in getting things farther along. I also met Xavier (not sure of last name) who is on Android build team and working on migrating standard android build tooling to Gradle (not for android itself, yet, but for people building android apps). They have pretty close to all the same build requirements we do so I think this is a great time to be trying to use Gradle. > Also, next week we should announce the official deadlines for the Fosdem > call for papers, it would be greet if you would like submit a paper and > join us there, too! There is a good chance I could be there, although it falls on my son's birthday which would be a royal shame to miss! Richard From hang.vo at oracle.com Wed Nov 14 14:18:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 14 Nov 2012 22:18:50 +0000 Subject: hg: openjfx/8/controls/rt: RT-26148 Add RTL support for Chart Message-ID: <20121114221855.D292947988@hg.openjdk.java.net> Changeset: 30a695b3c758 Author: Paru Somashekar Date: 2012-11-14 14:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/30a695b3c758 RT-26148 Add RTL support for Chart ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java From zonski at gmail.com Wed Nov 14 15:15:22 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 15 Nov 2012 10:15:22 +1100 Subject: Contribution to OpenJFX In-Reply-To: References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> <1352235736.4054.2.camel@pegasus> Message-ID: On Thu, Nov 15, 2012 at 9:04 AM, Richard Bair wrote: > > Once we get back (we are in Toronto now) I'll write also some followup > > to sync about the actual status of the build refactoring (including the > > new build tool). > > Cool. I met with Hans Docktor (Mr Gradle) on Tuesday and he was awesome > help (thanks Hans!) in getting things farther along. I also met Xavier (not > sure of last name) who is on Android build team and working on migrating > standard android build tooling to Gradle (not for android itself, yet, but > for people building android apps). They have pretty close to all the same > build requirements we do so I think this is a great time to be trying to > use Gradle. > Can you guys give us a quick overview of the "new build tool" and "build refactoring"? Is this the JFX build tools you are talking about, the JRE build or something else altogether? How does Gradle fit into the mix. I've just started a pretty big undertaking to make a build library and use this in a Maven plugin. It would be great to know in advance if this work is going to be superseded by anything you guys are doing and/or whether it is stuff that can be leveraged to save me time. Additionally I am trying (slowly) to work out how to build compact JRE profiles for desktop so would be good to know if any of this could overlap with that. Cheers, Dan From scott.kovatch at oracle.com Wed Nov 14 16:16:03 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 14 Nov 2012 16:16:03 -0800 Subject: Contribution to OpenJFX In-Reply-To: References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> <1352235736.4054.2.camel@pegasus> Message-ID: On Nov 14, 2012, at 2:04 PM, Richard Bair wrote: > > > On Nov 6, 2012, at 10:02 PM, Mario Torre wrote: > >> Il giorno mar, 06/11/2012 alle 07.32 -0800, Richard Bair ha scritto: >>> Hi Deepak, >>> >>> This is great news! I don't know if Mario / Roman or any other RedHat engineers working on this will be at Devoxx? I'm planning on spending most of Tuesday at the Devoxx Hackergarten working on upgrading the build. Also, we should have the javafx packager (which does the native application co-bundles) open sourced this week. >>> >>> Cheers! >>> Richard >> >> Hi Richard, >> >> Unfortunately we won't be at Devoxx but I've seen the discussion going >> on and is very welcomed news! >> >> I think the native packager is an interesting challenge to include in >> Linux distributions, indeed a very good starting point. >> >> Does it depend on other JavaFX code internally or is a standalone tool? > > I think it is standalone. Scott? The native packager has no dependency on JavaFX. It should be completely standalone. There is some code specifically for launching FX applications that handle not having an FX runtime. I haven't looked, but I would think they don't depend on FX. I'm working on open sourcing javafxpackager, but I got pulled back to look at a 7u10 regression. I'll have a better estimate once I get that taken care of. -- Scott K. From richard.bair at oracle.com Wed Nov 14 18:49:34 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 15 Nov 2012 03:49:34 +0100 Subject: Contribution to OpenJFX In-Reply-To: References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> <1352235736.4054.2.camel@pegasus> Message-ID: <5B2F607E-2E00-43DD-87F8-B3C606DCC734@oracle.com> On Nov 15, 2012, at 12:15 AM, Daniel Zwolenski wrote: > On Thu, Nov 15, 2012 at 9:04 AM, Richard Bair wrote: >> > Once we get back (we are in Toronto now) I'll write also some followup >> > to sync about the actual status of the build refactoring (including the >> > new build tool). >> >> Cool. I met with Hans Docktor (Mr Gradle) on Tuesday and he was awesome help (thanks Hans!) in getting things farther along. I also met Xavier (not sure of last name) who is on Android build team and working on migrating standard android build tooling to Gradle (not for android itself, yet, but for people building android apps). They have pretty close to all the same build requirements we do so I think this is a great time to be trying to use Gradle. > > Can you guys give us a quick overview of the "new build tool" and "build refactoring"? Is this the JFX build tools you are talking about, the JRE build or something else altogether? How does Gradle fit into the mix. This is for the building JavaFX itself (vs. the ant stuff we are using now). At least, that is what I was talking about but now that I re-read I'm not as certain what Mario meant. > I've just started a pretty big undertaking to make a build library and use this in a Maven plugin. It would be great to know in advance if this work is going to be superseded by anything you guys are doing and/or whether it is stuff that can be leveraged to save me time. > > Additionally I am trying (slowly) to work out how to build compact JRE profiles for desktop so would be good to know if any of this could overlap with that. I think this is orthogonal. I think the Gradle support Danno was working on is more related to what you are doing with Maven, right? Cheers Richard From zonski at gmail.com Wed Nov 14 20:51:25 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 15 Nov 2012 15:51:25 +1100 Subject: Contribution to OpenJFX In-Reply-To: <5B2F607E-2E00-43DD-87F8-B3C606DCC734@oracle.com> References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> <1352235736.4054.2.camel@pegasus> <5B2F607E-2E00-43DD-87F8-B3C606DCC734@oracle.com> Message-ID: Sounds like it's not related to the Maven stuff I am doing. I am basically rebuilding the JFX packaging tools (i.e. the code in ant-javafx.jar) as an open source project - adding flexibility and features for assembling JFX apps. If possible, it would be good to know in advanced if/when any work is happening or planned in the ant-javafx.jar code (other than open sourcing them). Does sound like this new build stuff might overlap with the compact JRE profile work but I'm a long way from understanding that to know yet. Thanks for the clarification. On Thu, Nov 15, 2012 at 1:49 PM, Richard Bair wrote: > > > On Nov 15, 2012, at 12:15 AM, Daniel Zwolenski wrote: > > On Thu, Nov 15, 2012 at 9:04 AM, Richard Bair wrote: > >> > Once we get back (we are in Toronto now) I'll write also some followup >> > to sync about the actual status of the build refactoring (including the >> > new build tool). >> >> Cool. I met with Hans Docktor (Mr Gradle) on Tuesday and he was awesome >> help (thanks Hans!) in getting things farther along. I also met Xavier (not >> sure of last name) who is on Android build team and working on migrating >> standard android build tooling to Gradle (not for android itself, yet, but >> for people building android apps). They have pretty close to all the same >> build requirements we do so I think this is a great time to be trying to >> use Gradle. >> > > Can you guys give us a quick overview of the "new build tool" and "build > refactoring"? Is this the JFX build tools you are talking about, the JRE > build or something else altogether? How does Gradle fit into the mix. > > > This is for the building JavaFX itself (vs. the ant stuff we are using > now). At least, that is what I was talking about but now that I re-read I'm > not as certain what Mario meant. > > I've just started a pretty big undertaking to make a build library and use > this in a Maven plugin. It would be great to know in advance if this work > is going to be superseded by anything you guys are doing and/or whether it > is stuff that can be leveraged to save me time. > > Additionally I am trying (slowly) to work out how to build compact JRE > profiles for desktop so would be good to know if any of this could overlap > with that. > > > I think this is orthogonal. I think the Gradle support Danno was working > on is more related to what you are doing with Maven, right? > > Cheers > Richard > From richard.bair at oracle.com Thu Nov 15 00:16:06 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 15 Nov 2012 09:16:06 +0100 Subject: Contribution to OpenJFX In-Reply-To: References: <20121106034434.GB14271@redhat.com> <23533168-1EB9-4DA0-8AEB-80F7F4F7A7F7@oracle.com> <1352235736.4054.2.camel@pegasus> <5B2F607E-2E00-43DD-87F8-B3C606DCC734@oracle.com> Message-ID: <3CDC1E79-715E-4A44-8D9F-B72707C393DF@oracle.com> > If possible, it would be good to know in advanced if/when any work is happening or planned in the ant-javafx.jar code (other than open sourcing them). Oh certainly, there is going to be work in this area for sure since app bundles are strategic. However we do not have any list of planned features or work. Scott will be working on this. Once the bits are open sourced I'm expecting a lively discussion to figure that all out. > Does sound like this new build stuff might overlap with the compact JRE profile work but I'm a long way from understanding that to know yet. I don't think it will. Richard From artem.ananiev at oracle.com Thu Nov 15 01:09:38 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 15 Nov 2012 13:09:38 +0400 Subject: JavaFX: Stage and Unified Toolbars on Mac (apple.awt.brushMetalLook for JavaFX) In-Reply-To: References: <50A3B551.7040707@oracle.com> <50A3C384.6030503@oracle.com> Message-ID: <50A4B152.2040601@oracle.com> Hi, Tobi, On 11/14/2012 9:57 PM, Tobi wrote: > Hi, > > how can I make an JavaFX app with an unified toolbar like on Swing > with "apple.awt.brushMetalLook" this functionality is currently not supported in JavaFX. Corresponding JIRA issue is http://javafx-jira.kenai.com/browse/RT-19834 It depends on another one, RT-19988, which you are already subscribed to. > There was a discussion a few month ago here: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-February/000776.html > > Any news about this feature? It's still targeted to 8, this is what I can say right now :) Thanks, Artem > Best regards, > Tobi From hang.vo at oracle.com Thu Nov 15 21:24:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 16 Nov 2012 05:24:06 +0000 Subject: hg: openjfx/8/master/rt: 19 new changesets Message-ID: <20121116052429.6A27C479CF@hg.openjdk.java.net> Changeset: 2eccad815147 Author: ptbrunet Date: 2012-11-05 22:00 -0600 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2eccad815147 clean up some logging ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleNode.java ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleStage.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleControl.java Changeset: 6a40a582b6fd Author: ptbrunet Date: 2012-11-05 22:01 -0600 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6a40a582b6fd merged Changeset: 36a55281a823 Author: leifs Date: 2012-11-06 10:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/36a55281a823 RT-138: Support component orientation in common UI controls ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java + javafx-ui-common/src/javafx/geometry/NodeOrientation.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CheckBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: df9a24643d20 Author: Paru Somashekar Date: 2012-11-06 15:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/df9a24643d20 fix RT-25899 & RT-21165 ! javafx-ui-charts/src/javafx/scene/chart/BubbleChart.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 744a754668fa Author: Paru Somashekar Date: 2012-11-08 19:28 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/744a754668fa Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: fd48b9d9cb2b Author: David Grieve Date: 2012-11-09 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fd48b9d9cb2b RT-26165: Need to call impl_getAllParentStylesheets when updating stylesheets for a Parent. ! javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 9b926fb92fcf Author: David Grieve Date: 2012-11-09 10:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9b926fb92fcf RT-25607: When looking up a font style, consider the inline styles of parent nodes ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: edf3703cb202 Author: David Grieve Date: 2012-11-09 10:17 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/edf3703cb202 missed changes from last patch. ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_UA.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: 952f2115ae99 Author: Paru Somashekar Date: 2012-11-09 23:27 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/952f2115ae99 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: f5e438202f2d Author: rbair Date: 2012-11-06 14:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f5e438202f2d Open source of decora-compiler + decora-compiler/.classpath + decora-compiler/.project + decora-compiler/build.xml + decora-compiler/nbproject/project.xml + decora-compiler/project.properties + decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g + decora-compiler/src/com/sun/scenario/effect/compiler/JSLC.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/ES2Backend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/GLSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/HLSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/SLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWCallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWTreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MECallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/METreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSECallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSETreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/BaseType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/BinaryOpType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/CoreSymbols.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/FuncImpl.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Function.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Param.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Precision.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Qualifier.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/SymbolTable.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Type.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/UnaryOpType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Variable.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ArrayAccessExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/BinaryExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/BreakStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/CallExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/CompoundStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ContinueStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DeclStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DiscardStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DoWhileStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Expr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ExprStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ExtDecl.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/FieldSelectExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ForStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/FuncDef.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/GlueBlock.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/LiteralExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ParenExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ProgramUnit.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ReturnStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/SelectStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Stmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Tree.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeMaker.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeVisitor.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/UnaryExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VarDecl.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VariableExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VectorCtorExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/WhileStmt.java + decora-compiler/test/com/sun/scenario/effect/compiler/SymbolTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/BoolTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/CommentTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/FloatTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/IdentifierTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/IntegerTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/LexerBase.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/LineCommentTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/TypeTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/WhitespaceTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/AddExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/AssignmentExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/EqualityExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/Expressions.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/ExternalDeclarationTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/FieldSelectTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/FullySpecifiedTypeTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/IterationStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/JumpStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/MultExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/ParserBase.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/PrimaryExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/RelationalExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/SelectionStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/UnaryExprTest.java Changeset: 7995eb685119 Author: peterz Date: 2012-11-07 07:33 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7995eb685119 RT-22493 WebView should use Toolkit for initialization ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubWebView.java Changeset: d3eeaeeb85bd Author: Martin Sladecek Date: 2012-11-07 14:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d3eeaeeb85bd RT-26094 Event classes should have serialVersionUID ! javafx-ui-common/src/com/sun/javafx/stage/FocusUngrabEvent.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/InputEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.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/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java ! javafx-ui-common/src/javafx/stage/WindowEvent.java Changeset: 7e871632dfe4 Author: Felipe Heidrich Date: 2012-11-07 21:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7e871632dfe4 [ECLIPSE ONLY] fixing classpath due changes in decora ! .classpath Changeset: ab55578e4692 Author: kcr Date: 2012-11-09 17:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ab55578e4692 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 09cbcb519b6d Author: Felipe Heidrich Date: 2012-11-09 22:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/09cbcb519b6d Merge Rich Text - RT-17392 (part1) including fixes for RT-20645, RT-24735, RT-24634, RT-24467, RT-24435, RT-24012, RT-23231, RT-16853, RT-14356 + javafx-ui-common/src/com/sun/javafx/scene/text/GlyphList.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLayoutFactory.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLine.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextSpan.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/test/unit/javafx/scene/text/Text_builder_Test.java ! javafx-ui-common/test/unit/javafx/scene/text/Text_onInvalidate_Test.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayoutFactory.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 194fe6a98a4a Author: Artem Ananiev Date: 2012-11-12 11:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/194fe6a98a4a com.sun.glass.taskbarApplication system property is renamed to glass.taskbarApplication ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java Changeset: 5ca1d6e4604d Author: Martin Sladecek Date: 2012-11-13 14:40 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5ca1d6e4604d RT-26126 Popup menus stopped working ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java Changeset: 38b5c364c630 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-13 09:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/38b5c364c630 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 5047d4016211 Author: hudson Date: 2012-11-15 21:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5047d4016211 Added tag 8.0-b65 for changeset 38b5c364c630 ! .hgtags From ozemale at ozemail.com.au Fri Nov 16 01:14:30 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 16 Nov 2012 20:14:30 +1100 Subject: JavaFX performance for complex visualisations Message-ID: <004f01cdc3da$c8fd1b10$5af75130$@com.au> I am under the impression that JavaFX 2.x can be used to develop reasonably complex and demanding visualisations including games, animations etc. and that JavaFX 8+ will enable such visualisations to be 3D. However, as of yet, I have not seen any such advanced visualisations anywhere. The animation samples in Ensemble are obviously very rudimentary (probably intentionally) and I have not been able to find anything that I would classify as complex, demanding or advanced anywhere on the internet. And this brings me to ask a few questions: 1. Do any such games, animations or visualisations exist yet? 2. If not, how does Oracle or anyone else actually know that JavaFX is capable of supporting such applications? 3. Do I have the wrong understanding that JavaFX is supposed to support such applications? 4. Is it possible that, for whatever reason, JavaFX is simply not capable of supporting such applications? My feeling that JavaFX can indeed support such applications is based on the fact that it is hardware accelerated and therefore it should be limited mostly by the capabilities of the graphics card and also because it is often talked about in this way. However, I have observed varying levels of performance that don't quite follow these principles such as JavaFX performing poorly with choppy/jittery animations and transitions on my most powerful machine with an NVIDIA GeForce GTX 690 (the current fastest graphics card in the world) but performing quite well on machines with much lower specifications. So I guess I am curious to know what kinds of testing and evaluations Oracle has undertaken to determine the performance characteristics of JavaFX and exactly what kinds of applications it is actually suitable for. For example, I am yet to see any JavaFX application with even the sophistication of a Flash electronic greeting card or banner ad and yet I assume JavaFX will be used for such purposes eventually. I'd appreciate comments from Oracle and anyone who has in fact developed more complex visualisations/animations/games with JavaFX that aren't publicly accessible. Thanks, -jct From zonski at gmail.com Fri Nov 16 02:15:35 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 16 Nov 2012 21:15:35 +1100 Subject: Generated JNLP and HTML files - mysterious values Message-ID: When the standard JFX packaging tool generates a JNLP file it includes: I don't understand why there is a windows specific URL in the JNLP file - isn't a JNLP file OS independent? Also, the generated HTML file to launch the JNLP has this: dtjava.launch( { url : 'hello-javafx-maven-example-1.0-SNAPSHOT.jnlp', jnlp_content : 'PD94bWwgdmVyc2lvbj0iMS4wIi...whole-lot-more-base64-style-data .... What's the 'jnlp_content' thing for? From the code it looks like a base64 encoding of the JNLP file. Why is this needed at all, and what's the url doing in this case? Any pointers appreciated. Basic JNLP bundling for the Maven plugin is done except for this stuff (and security/signing). From zonski at gmail.com Fri Nov 16 02:42:42 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 16 Nov 2012 21:42:42 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <004f01cdc3da$c8fd1b10$5af75130$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> Message-ID: I haven't done much that you'd consider "graphically complex" but I did build an app that had animations along the lines of an iPad application (i.e. swipe left of a screen, fade-in/out, animated "popups") which also did some pretty basic CAD-style stuff (a simple outline of a site map). Running on pretty decent PCs and laptops a year ago and also running on a Windows Tablet ( http://www.motioncomputing.com.au/products/tablet_pc_f5.asp). Performance was noticeably jittery and a tad slow - definitely not iPad speed/quality for example, closer to a JavaScript animation experience. My code could well have been optimised a bit but I wasn't exactly going for anything too hard core (and I did ask here and on the forums questions around writing performant scene/animation code but no response). Here's an example of the sort of screen: http://damiansimpkins.com/projects/downstream/corso_audit/06/checksheet.htm This would slide in from the right and slide out to the left, with various expansion and collapses and animated popups when you click buttons etc. You'd "feel" the delay when you clicked something and sometimes the animation would suddenly jump into action, doing nothing for a bit and then a fraction of a second later jumping to where it should be before completing the animation more smoothly. It wasn't unusable or anything but it certainly wasn't Apple-slick. This was on 2.0 and 2.1 from memory (about a year ago) and based on some emails through here I think some work may have been done on performance. Regrettably I've not had any other recent JFX projects to try it out on though (at which point I launch into another rant about build and deployment ;) ) . On Fri, Nov 16, 2012 at 8:14 PM, John C. Turnbull wrote: > I am under the impression that JavaFX 2.x can be used to develop reasonably > complex and demanding visualisations including games, animations etc. and > that JavaFX 8+ will enable such visualisations to be 3D. > > > > However, as of yet, I have not seen any such advanced visualisations > anywhere. The animation samples in Ensemble are obviously very rudimentary > (probably intentionally) and I have not been able to find anything that I > would classify as complex, demanding or advanced anywhere on the internet. > > > > And this brings me to ask a few questions: > > > > 1. Do any such games, animations or visualisations exist yet? > > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? > > 3. Do I have the wrong understanding that JavaFX is supposed to support > such > applications? > > 4. Is it possible that, for whatever reason, JavaFX is simply not capable > of > supporting such applications? > > > > My feeling that JavaFX can indeed support such applications is based on the > fact that it is hardware accelerated and therefore it should be limited > mostly by the capabilities of the graphics card and also because it is > often > talked about in this way. However, I have observed varying levels of > performance that don't quite follow these principles such as JavaFX > performing poorly with choppy/jittery animations and transitions on my most > powerful machine with an NVIDIA GeForce GTX 690 (the current fastest > graphics card in the world) but performing quite well on machines with much > lower specifications. > > > > So I guess I am curious to know what kinds of testing and evaluations > Oracle > has undertaken to determine the performance characteristics of JavaFX and > exactly what kinds of applications it is actually suitable for. For > example, I am yet to see any JavaFX application with even the > sophistication > of a Flash electronic greeting card or banner ad and yet I assume JavaFX > will be used for such purposes eventually. > > > > I'd appreciate comments from Oracle and anyone who has in fact developed > more complex visualisations/animations/games with JavaFX that aren't > publicly accessible. > > > > Thanks, > > > > -jct > > From mp at jugs.org Fri Nov 16 04:00:36 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 16 Nov 2012 13:00:36 +0100 Subject: JavaFX performance for complex visualisations In-Reply-To: <004f01cdc3da$c8fd1b10$5af75130$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> Message-ID: <50A62AE4.7030309@jugs.org> According to my experience JavaFX is currently not able to handle graphically intensive applications. One reason for this is that all drawing of path based primitives is done in software and not in hardware. That means that everything with the exception of single lines, circles and rectangles is not hardware accelerated. If you want to draw a simple filled triangle for example you have to use a polygon for that because there is no explicit triangle primitive. But a polygon is a path and thus is rendered in software and this software renderer is in many cases even 2-3 times slower than the one used in AWT. You can currently render 100_000 lines without problem but if you put them in a path you can only use less than 1000 if you want the same performance. I hope this will change with the upcoming 3D support where we will also get more hardware accelerated drawing primitives which will hopefully also be usable in 2D. Sometimes you can get around the above mentioned problems by clever caching but sometimes you just need the raw performance which currently is not available. LG, Michael Am 16.11.2012 10:14, schrieb John C. Turnbull: > I am under the impression that JavaFX 2.x can be used to develop reasonably > complex and demanding visualisations including games, animations etc. and > that JavaFX 8+ will enable such visualisations to be 3D. > > > > However, as of yet, I have not seen any such advanced visualisations > anywhere. The animation samples in Ensemble are obviously very rudimentary > (probably intentionally) and I have not been able to find anything that I > would classify as complex, demanding or advanced anywhere on the internet. > > > > And this brings me to ask a few questions: > > > > 1. Do any such games, animations or visualisations exist yet? > > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? > > 3. Do I have the wrong understanding that JavaFX is supposed to support such > applications? > > 4. Is it possible that, for whatever reason, JavaFX is simply not capable of > supporting such applications? > > > > My feeling that JavaFX can indeed support such applications is based on the > fact that it is hardware accelerated and therefore it should be limited > mostly by the capabilities of the graphics card and also because it is often > talked about in this way. However, I have observed varying levels of > performance that don't quite follow these principles such as JavaFX > performing poorly with choppy/jittery animations and transitions on my most > powerful machine with an NVIDIA GeForce GTX 690 (the current fastest > graphics card in the world) but performing quite well on machines with much > lower specifications. > > > > So I guess I am curious to know what kinds of testing and evaluations Oracle > has undertaken to determine the performance characteristics of JavaFX and > exactly what kinds of applications it is actually suitable for. For > example, I am yet to see any JavaFX application with even the sophistication > of a Flash electronic greeting card or banner ad and yet I assume JavaFX > will be used for such purposes eventually. > > > > I'd appreciate comments from Oracle and anyone who has in fact developed > more complex visualisations/animations/games with JavaFX that aren't > publicly accessible. > > > > Thanks, > > > > -jct > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From scott.kovatch at oracle.com Fri Nov 16 08:58:45 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 16 Nov 2012 08:58:45 -0800 Subject: Generated JNLP and HTML files - mysterious values In-Reply-To: References: Message-ID: <047DCCE5-DCE8-4215-BD56-70DA16A9A53C@oracle.com> On Nov 16, 2012, at 2:15 AM, Daniel Zwolenski wrote: > When the standard JFX packaging tool generates a JNLP file it includes: > > > > I don't understand why there is a windows specific URL in the JNLP file - > isn't a JNLP file OS independent? Not necessarily. You can put platform-specific resources in a JNLP based on the OS or architecture for things like native libraries that only apply to a given platform. In this case, that URL is there to install the Windows implementation of JavaFX if it isn't available. It's only very recently that JavaFX is being included with the JRE. Each platform has its own implementation of Glass, so we have to install the right one. > Also, the generated HTML file to launch the JNLP has this: > > dtjava.launch( { > url : 'hello-javafx-maven-example-1.0-SNAPSHOT.jnlp', > jnlp_content : > 'PD94bWwgdmVyc2lvbj0iMS4wIi...whole-lot-more-base64-style-data .... > > What's the 'jnlp_content' thing for? From the code it looks like a base64 > encoding of the JNLP file. Yes, that's basically what it is. This allows us to pass in the JNLP directly to Web Start without the overhead of another HTTP request. This is a feature of DeployToolkit, and it's documented in the main deployment guide. See section 7.3.2 and 7.3.3. -- Scott K. ------------------------ Scott Kovatch Oracle Pleasanton, CA From zonski at gmail.com Fri Nov 16 13:20:02 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 17 Nov 2012 08:20:02 +1100 Subject: Generated JNLP and HTML files - mysterious values In-Reply-To: <047DCCE5-DCE8-4215-BD56-70DA16A9A53C@oracle.com> References: <047DCCE5-DCE8-4215-BD56-70DA16A9A53C@oracle.com> Message-ID: Thanks Scott, I'm still a bit unclear though. On Sat, Nov 17, 2012 at 3:58 AM, Scott Kovatch wrote: > > On Nov 16, 2012, at 2:15 AM, Daniel Zwolenski wrote: > > > When the standard JFX packaging tool generates a JNLP file it includes: > > > > > > > > I don't understand why there is a windows specific URL in the JNLP file - > > isn't a JNLP file OS independent? > > Not necessarily. You can put platform-specific resources in a JNLP based > on the OS or architecture for things like native libraries that only apply > to a given platform. > > In this case, that URL is there to install the Windows implementation of > JavaFX if it isn't available. It's only very recently that JavaFX is being > included with the JRE. Each platform has its own implementation of Glass, > so we have to install the right one. > Sorry, I should have phrased the question differently: why is there a Windows specific URL here and not also a Linux, Mac, etc alternatives with an OS qualifier on them (as would normally be done with the third party native libraries in a jnlp). I'd expect either none or all, currently I see *only* windows (32bit). I'm assuming that the generated JNLP file is to launch the app on any OS, but this URL has me suspicious it is generating one biased to Windows just because I am building on Windows? Or is it just that Windows is special and the other OSs don't need this explicit declaration? I've attached the actual JNLP file that was generated by calling the ANT "fx:deploy" task with minimal settings. Will this file launch my app equally happily on Windows, Linux and Mac? This was built using jdk1.7.0_09_win_64bit. What happens if this explicit url to the JFX runtime is in the JNLP but the user has Java7 installed with FX already co-bundled - will it use the one already on the OS or try and download the referenced one? What happens if I leave the jfx version in but leave the URL off and the user doesn't have JFX installed, or has 1.6, etc? Is the attached JNLP the current perfect JNLP file for an app? If not it would be great if there was a reference example for a best-practices JNLP file. > > > Also, the generated HTML file to launch the JNLP has this: > > > > dtjava.launch( { > > url : 'hello-javafx-maven-example-1.0-SNAPSHOT.jnlp', > > jnlp_content : > > 'PD94bWwgdmVyc2lvbj0iMS4wIi...whole-lot-more-base64-style-data .... > > > > What's the 'jnlp_content' thing for? From the code it looks like a base64 > > encoding of the JNLP file. > > Yes, that's basically what it is. This allows us to pass in the JNLP > directly to Web Start without the overhead of another HTTP request. This is > a feature of DeployToolkit, and it's documented in the main deployment > guide. See section 7.3.2 and 7.3.3. > > > I had read that docco but the only thing it says is: "(optional) Content of the JNLP file in BASE64 encoding." What is the purpose/benefit of providing this content, how is it used and what benefit does it provide over not including it. The "url" parameter is not optional so I assume we can't choose to fully embed the content and not provide an actual JNLP file. Why and when would anyone want to include this blob of base64 data in their file? If it's included, is the URL parameter ignored? The JFX ant task seems to think it is a good idea to include it, as it includes it by default - what's the motivation behind doing this? Cheers for your help, Dan From scott.kovatch at oracle.com Fri Nov 16 14:22:45 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 16 Nov 2012 14:22:45 -0800 Subject: Generated JNLP and HTML files - mysterious values In-Reply-To: References: <047DCCE5-DCE8-4215-BD56-70DA16A9A53C@oracle.com> Message-ID: <042D52B2-8DE6-49DE-949B-DB4D643462AF@oracle.com> On Nov 16, 2012, at 1:20 PM, Daniel Zwolenski wrote: >> In this case, that URL is there to install the Windows implementation of JavaFX if it isn't available. It's only very recently that JavaFX is being included with the JRE. Each platform has its own implementation of Glass, so we have to install the right one. > > Sorry, I should have phrased the question differently: why is there a Windows specific URL here and not also a Linux, Mac, etc alternatives with an OS qualifier on them (as would normally be done with the third party native libraries in a jnlp). I'd expect either none or all, currently I see *only* windows (32bit). > > I'm assuming that the generated JNLP file is to launch the app on any OS, but this URL has me suspicious it is generating one biased to Windows just because I am building on Windows? Or is it just that Windows is special and the other OSs don't need this explicit declaration? Ah, good point. Windows is the only platform that has ever had a standalone installer for JavaFX, and until 7u6, the only platform that supported DeployToolkit as well. On Mac and Linux JavaFX has always been included with the JRE, so there's no standalone installer to download. You either have it or you don't. > This was built using jdk1.7.0_09_win_64bit. What happens if this explicit url to the JFX runtime is in the JNLP but the user has Java7 installed with FX already co-bundled - will it use the one already on the OS or try and download the referenced one? If you have FX already and it matches the version spec it should use the version you have. So, in the example you attached, if you don't have FX 2.2 or better Web Start will attempt to download the standalone JavaFX installer from the URL in the href. The main reason this was included, I think, is that you have 'j2se version="1.6+"', which never had JavaFX bundled with the JRE. I would expect that if you specified a product version of 1.7.0_09, or a platform version of 1.8+, this line wouldn't be included because those versions have FX 2.2+ already. I'm not 100% sure, though; I don't have the code handy. > What happens if I leave the jfx version in but leave the URL off and the user doesn't have JFX installed, or has 1.6, etc? If you leave it out and there's no FX available the app won't run. The user will see an alert. > Is the attached JNLP the current perfect JNLP file for an app? If not it would be great if there was a reference example for a best-practices JNLP file. I believe that was the idea behind javafxpackager. It should be the reference standard for JNLP, with the intent that you shouldn't ever need to hand-edit JNLP or the HTML that went around it. > > > I had read that docco but the only thing it says is: "(optional) Content of the JNLP file in BASE64 encoding." > > What is the purpose/benefit of providing this content, how is it used and what benefit does it provide over not including it. The "url" parameter is not optional so I assume we can't choose to fully embed the content and not provide an actual JNLP file. Why and when would anyone want to include this blob of base64 data in their file? If it's included, is the URL parameter ignored? > > The JFX ant task seems to think it is a good idea to include it, as it includes it by default - what's the motivation behind doing this? Take a look at section 5.9.2. http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABCJCHH The main reason is performance. It saves a network connection so you don't have to re-fetch the JNLP file. -- Scott K. ------------------------ Scott Kovatch Oracle Pleasanton, CA From zonski at gmail.com Fri Nov 16 22:22:00 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 17 Nov 2012 17:22:00 +1100 Subject: Generated JNLP and HTML files - mysterious values In-Reply-To: <042D52B2-8DE6-49DE-949B-DB4D643462AF@oracle.com> References: <047DCCE5-DCE8-4215-BD56-70DA16A9A53C@oracle.com> <042D52B2-8DE6-49DE-949B-DB4D643462AF@oracle.com> Message-ID: Thanks Scott, that cleared things up a lot. Some additional comments/musings: >From the code (1.7.0_09) it looks like the fallback URL for windows is hardcoded in regardless of what JRE version you provide. i.e. if I specify 1.7 from what I can see it won't stop the url from being added to the JNLP (PackagerLib.generateJnlp). Sounds like the URL would be harmless/ignored in this case though. The tool still looks to default to jrePlatform = "1.6+" and fxPlatform = "2.2+" even in the 1.7.0_09 version of the code. Might be better if it used the JRE version being built with or was hard coded to the latest, especially since 1.6 is a little special with the embedded JRE. I reckon it would be good to default people to not use 1.6 and they can explicitly change it if they want to use the older code. Doesn't JRE/plugin auto-updating mean that webstart and applet applications always have to run with the very latest Java release (for security reasons)? If so what's the purpose/impact of the versioning attributes in the JNLP file. I thought it wasn't actually possible to pin an app to a specific JRE version via the web-plugin deployment options? 'embedJnlp' defaults to true. The docco you linked to is not totally clear but to me it implies embedding would be "off" unless I set the embedjnlp attribute of the ANT task. Docco could be clearer or embedding could be off by default (very minor). What happens if that JNLP I sent is used on a 64bit windows machine running Java 1.6. The URL looks to be 32bit specific so would it download a 32bit version of JFX into a 64bit JVM? I'm wondering if this could potentially be linked to problems I've had before getting JNLP working with 64bit windows machines. I'm not fussed for me personally (that project is cactus, and anything else would be Java 7 minimum from here on in if I ever get the chance again) but just thought I'd mention it in case it's something you want to look at. On Sat, Nov 17, 2012 at 9:22 AM, Scott Kovatch wrote: > > On Nov 16, 2012, at 1:20 PM, Daniel Zwolenski wrote: > > >> In this case, that URL is there to install the Windows implementation > of JavaFX if it isn't available. It's only very recently that JavaFX is > being included with the JRE. Each platform has its own implementation of > Glass, so we have to install the right one. > > > > Sorry, I should have phrased the question differently: why is there a > Windows specific URL here and not also a Linux, Mac, etc alternatives with > an OS qualifier on them (as would normally be done with the third party > native libraries in a jnlp). I'd expect either none or all, currently I see > *only* windows (32bit). > > > > I'm assuming that the generated JNLP file is to launch the app on any > OS, but this URL has me suspicious it is generating one biased to Windows > just because I am building on Windows? Or is it just that Windows is > special and the other OSs don't need this explicit declaration? > > Ah, good point. Windows is the only platform that has ever had a > standalone installer for JavaFX, and until 7u6, the only platform that > supported DeployToolkit as well. > > On Mac and Linux JavaFX has always been included with the JRE, so there's > no standalone installer to download. You either have it or you don't. > > > This was built using jdk1.7.0_09_win_64bit. What happens if this > explicit url to the JFX runtime is in the JNLP but the user has Java7 > installed with FX already co-bundled - will it use the one already on the > OS or try and download the referenced one? > > If you have FX already and it matches the version spec it should use the > version you have. So, in the example you attached, if you don't have FX 2.2 > or better Web Start will attempt to download the standalone JavaFX > installer from the URL in the href. The main reason this was included, I > think, is that you have 'j2se version="1.6+"', which never had JavaFX > bundled with the JRE. > > I would expect that if you specified a product version of 1.7.0_09, or a > platform version of 1.8+, this line wouldn't be included because those > versions have FX 2.2+ already. I'm not 100% sure, though; I don't have the > code handy. > > > What happens if I leave the jfx version in but leave the URL off and the > user doesn't have JFX installed, or has 1.6, etc? > > If you leave it out and there's no FX available the app won't run. The > user will see an alert. > > > Is the attached JNLP the current perfect JNLP file for an app? If not it > would be great if there was a reference example for a best-practices JNLP > file. > > I believe that was the idea behind javafxpackager. It should be the > reference standard for JNLP, with the intent that you shouldn't ever need > to hand-edit JNLP or the HTML that went around it. > > > > > > > I had read that docco but the only thing it says is: "(optional) Content > of the JNLP file in BASE64 encoding." > > > > What is the purpose/benefit of providing this content, how is it used > and what benefit does it provide over not including it. The "url" parameter > is not optional so I assume we can't choose to fully embed the content and > not provide an actual JNLP file. Why and when would anyone want to include > this blob of base64 data in their file? If it's included, is the URL > parameter ignored? > > > > The JFX ant task seems to think it is a good idea to include it, as it > includes it by default - what's the motivation behind doing this? > > Take a look at section 5.9.2. > > http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABCJCHH > > The main reason is performance. It saves a network connection so you don't > have to re-fetch the JNLP file. > > -- Scott K. > > ------------------------ > Scott Kovatch > Oracle > Pleasanton, CA > > > From zonski at gmail.com Sun Nov 18 05:26:09 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 19 Nov 2012 00:26:09 +1100 Subject: JavaFX packaging tools (was Re: JavaFX plugin for SBT) In-Reply-To: References: Message-ID: Latest release of the Maven plugin has been pushed to central and includes JNLP generation and JAR signing (see https://github.com/zonski/javafx-maven-plugin). JAR signing is a straight call out to the JFX packaging tool. JNLP/HTML generation completely bypasses the JFX packaging tools and instead uses the code in the javafx-deploy-lib (https://github.com/zonski/javafx-deploy-lib), which uses Velocity templates to generate the files. We didn't really get any conclusions on default directories and file names for things like jnlp templates, keystores, icons, splash screens so I have picked some (mostly putting things under 'src/main/deploy'). Refer to the online doc for more information. Also I am currently putting the executable JAR file back directly into the 'target' directory with a -jfx suffix. The 'webstart' bundle is in it's own directory under target/webstart and includes a copy of the JAR, the JNLP file, the HTML file, and any icons, images, etc. Native bundles go under 'target/bundles' but this is mostly because the JFX tools don't allow me to customise this much more than this. I think I like Danno's suggestion of putting the distros directly under target (except webstart and applet which are special because they have multiple files in the bundle - I would be open to zipping them up into the target directory if we thought that was helpful?) It's still early enough to change these if people give a good alternative but a few more releases and I will be reluctant to change anything without strong reason to. Now's a good time to shout out if you have an opinion. On Wed, Nov 14, 2012 at 11:44 PM, Daniel Zwolenski wrote: > I have added more to the JNLP generation in > https://github.com/zonski/javafx-deploy-lib It now uses Velocity to > generate both a JNLP and a HTML file (linking to the JNLP) from settings > passed into it. > > I have also done some work in integrating this into my Maven plugin: > https://github.com/zonski/javafx-maven-plugin > > This work is all checked in and working in a rough form. I've not yet > pushed it into any Maven repo though so at this stage you have to get the > source out to do anything with it (I'll try to get at least snapshots up > over the weekend). > > If you want to generate a webstart bundle, just add to your > POM's plugin configuration. You can add settings if you want, but in > general it will take info from the POM (such as name, vendor, organisation, > etc). The jnlp and html files will be generated in "target/webstart" > > The generated JNLP and HTML look ok but the resulting app won't actually > launch yet as they are missing some of the magic attributes now required by > JFX. This is really just a case of updating the default template file to > look like what comes out of the JFX packaging tools. Should be easy, > hopefully over the weekend. Signing the jar is a separate problem though, > probably won't sort that out this weekend. > > I like this templating approach a lot better than the JFX tools. With the > JFX ones you get what comes out and don't get any real say in this. In this > code you can provide a custom velocity template for both the JNLP and the > HTML and you can completely design it how you want (and you have available > to you all the settings/parameters used to generate the JNLP). Rolling the > same strategy out for Applets should be easy, and down the track adding a > template-based HTML file that helps users download the appropriate native > installer for their system might also be a nice thing to have. > > In response to Knut, it's the static nature of the output of the JFX tools > that I find limiting. This templating is one example, but also control over > a lot of things like output directories, even fine grained security > settings, etc is not currently supported by the JFX tools. The tools could > obviously be extended to support them, but there are several limitations to > this (e.g. can we use a third party library such as velocity?). My biggest > worry though would be the very slow release cycle to the tools - as soon as > it is open sourced we will be able to fix up a lot of the obvious holes but > it could be months (or years) before these fixes make it into an official > release. What's more we can never guarantee which version of the tools the > user will have (are they using JDK1.7 or JDK1.8, etc?) so we cannot link to > specific features. Having a separate open source project with stand alone > build tools works better for me. > > Feel free to use them if you want, but calling straight onto the ant files > is definitely a fine and simple option if that's what you prefer. > > > > > On Tue, Nov 13, 2012 at 12:01 PM, Daniel Zwolenski wrote: > >> > Is this thread relevant for the open-jfx list, or should we move it to >> private email? >> >> Seems relevant to me given that a lot of this relates back to the >> structure of the official JFX packaging tools, how they will be used and >> what features they should have built in. If anyone has any objections >> though, let us know and we'll take it off list. >> >> > What I do in the SBT plugin is that I generate a build.xml file that >> contains and task definitions, and pass on >> plugin-defined settings from the project's .sbt build file to these tasks, >> then run Ant on it. >> >> The Maven plugin calls directly onto the packaging tool code (which the >> ANT tasks call onto internally), cutting out the ANT middle man. >> >> > There also needs to be a "use this file" support. Auto-generation is >> nice but sometimes there are random things that have to be put in >> for random reasons that the conventions don't support. >> >> That's what I was meaning by "JNLP templating". My current thinking is to >> use Velocity to generate the JNLP template and pass in known replacement >> variables. If a custom template exists in the project (e.g. in >> src/main/webstart/jnlp-template.vm) then it will automagically use this. If >> none is supplied then it uses a built-in default one to produce a standard >> jnlp file. >> >> I'm intending to do something similar for generating a HTML file for >> Applet deployment, and also a HTML file to launch the JNLP. The idea being >> that the developer can just upload the HTML, JAR and JNLP to a server and >> it is ready for action. >> >> I wrote the first half of this code last night - hopefully will have it >> working sometime next week. Currently I am completely bypassing the JFX >> tool for JNLP and Applets as it is too limited. >> >> My first question is whether anyone else is interested in doing the same >> templating stuff in their build tools or whether you want to stick to just >> wrappering the more limited functionality of the JFX packaging tools? >> >> If no one else is interested, I'll just bundle this in my plugin code. If >> others want to do the same thing then I can section off this code as a >> Maven independent GitHub project or we could look at whether it's possible >> to move it into the base JFX tools (not sure that's such a great idea >> though). >> >> > The ant task sniffs for package/ in the classpath, so that is >> why I did id that way. >> >> Makes sense as a starting point. I'm hoping once we get the open source >> code we will be able to change the defaults a bit and make it more >> configurable. I'd rather us come up with good standards and change the >> tools to meet, rather than just doing what the ant tools do as I don't >> think they were built with cross-tool standards in mind. >> >> On a side note, I'd definitely like the 'bundle' part of the code to be >> more flexible so that we can turn on and off specific native installers via >> params passed in. i.e. I'd like to be able to explicitly call the method to >> build the MSI or the EXE not have to pass in a parameter of "ALL" or >> "IMAGE" which could mean anything on any platform, etc. >> >> > I don't like target/javafx. >> >> Fair call, I'm not especially wed to it >> >> > For example, the Maven DMG plugin ( >> http://mojo.codehaus.org/osxappbundle-maven-plugin) >> uses src/main/app-resources for soruce data and drops the DMG directly into >> target/ >> >> I like the simplicity of putting the natives directly in the target >> directory. We'd need a naming scheme though to differentiate between x86 >> and x64 MSI for example. Easy enough. >> >> With JNLP and Applet though the bundles are not a single file, it's HTML >> plus JNLP plus JAR (at a minimum). Does it make sense to bundle these >> straight in target? or a zip for applet another zip for webstart (or a >> combined zip with both)? or do sub directories make sense for these? >> >> In Maven land I might also have to think about what to do with JNLP and >> Applet if the packaging type is 'war' file. I might need to think about >> that one a bit more. >> >> > Much of this could be a matter of taste though. >> >> Definitely. Would be good if we can standardise it but if our tastes >> differ too much well then probably not worth going round in circles about >> it too much and just do what we think best. Keen to work out what the >> preferences are at least, and so far this has been a useful conversation >> for me. >> >> >> >> >> >> >> On Tue, Nov 13, 2012 at 10:46 AM, Tom Schindl < >> tom.schindl at bestsolution.at> wrote: >> >>> >>> >>> Von meinem iPhone gesendet >>> >>> Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa < >>> knut.arne.vedaa at broadpark.no>: >>> >>> > What I do in the SBT plugin is that I generate a build.xml file that >>> contains and task definitions, and pass on >>> plugin-defined settings from the project's .sbt build file to these tasks, >>> then run Ant on it. >>> >>> This is the way e(fx)clipse works as well and it works without problems. >>> Beside that we allow people to configure the generation in an extra >>> XML-File. >>> >>> Tom >>> >> >> > From tbee at tbee.org Sun Nov 18 12:29:28 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 18 Nov 2012 21:29:28 +0100 Subject: out of memory In-Reply-To: <50997392.1080607@tbee.org> References: <5098F0BE.6040207@tbee.org> <50990442.4010106@oracle.com> <50990534.2080605@tbee.org> <509908E0.4020300@oracle.com> <50995BAD.2090309@tbee.org> <50995F55.9030904@oracle.com> <50997392.1080607@tbee.org> Message-ID: <50A94528.4070505@tbee.org> I'm revisiting the memory issue. If I unfold the whole graph to CG there is no MigPane involved, all I see is dirtyNodes in the Scene class and oldScene in the Node and Window class. So somehow the test combined with MigPane causes JavaFX to keep references. This is a complex situation. Class Name | Shallow Heap | Retained Heap ----------------------------------------------------------------------------------------------------------------------------------------------------- | | javafx.scene.control.Button @ 0x319c7b30 | 408 | 1,672 '- [60668] javafx.scene.Node[98113] @ 0x29cc8810 | 392,464 | 392,464 '- dirtyNodes javafx.scene.Scene @ 0x27f65d00 | 376 | 396,728 |- this$0 javafx.scene.Scene$ScenePeerListener @ 0x28003d60 | 16 | 16 | '- sceneListener com.sun.javafx.tk.quantum.ViewScene @ 0x27ffb710 | 64 | 168 | |- scene com.sun.javafx.tk.quantum.PrismPen @ 0x27ffc7f0 | 48 | 2,344 | | '- pen com.sun.glass.ui.win.WinView @ 0x27ff4e98 Native Stack | 72 | 480 | |- scene com.sun.javafx.tk.quantum.GlassViewEventHandler @ 0x27ffc820 | 48 | 408 | |- scene com.sun.javafx.tk.quantum.WindowStage @ 0x27f694e8 | 88 | 184 | |- [0] java.lang.Object[10] @ 0x27f32398 | 56 | 56 | | '- elementData java.util.ArrayList @ 0x27f02ca0 | 24 | 80 | | '- syncScenes com.sun.javafx.tk.quantum.PaintCollector @ 0x27ee0ae0 | 64 | 656 | '- Total: 4 entries | | |- oldScene, value javafx.scene.Node$4 @ 0x31121ca8 | 48 | 48 | '- scene org.tbee.javafx.scene.layout.test.MigPaneTest11$ListElement @ 0x3111dac0 | 432 | 4,680 | '- [0] java.lang.Object[10] @ 0x27f38dc0 | 56 | 56 | '- elementData java.util.ArrayList @ 0x27f06870 | 24 | 80 | '- backingList com.sun.javafx.collections.ObservableListWrapper @ 0x27ee38b8 | 32 | 400 | '- items org.tbee.javafx.scene.layout.test.MigPaneTest11 @ 0x27ee0300 | 16 | 16 | |- java.lang.Thread @ 0x27ee0518 JavaFX-Launcher Thread | 112 | 408 | |- this$0 org.tbee.javafx.scene.layout.test.MigPaneTest11$1 @ 0x27f6d558 | 16 | 16 | | '- this$1 org.tbee.javafx.scene.layout.test.MigPaneTest11$1$1 @ 0x283116e0 Thread-6 Thread| 112 | 200 | '- Total: 2 entries | | |- oldScene, value javafx.stage.Window$SceneModel @ 0x27f6a640 | 48 | 48 | '- scene javafx.stage.Stage @ 0x27f65ea8 | 144 | 992 | '- [0] java.lang.Object[10] @ 0x27f6e2b0 | 56 | 56 | '- elementData java.util.ArrayList @ 0x27f6bcd8 | 24 | 80 | '- backingList com.sun.javafx.collections.ObservableListWrapper @ 0x27f68690 | 32 | 112 | '- stages class javafx.stage.Stage @ 0x32ae1aa0 | 16 | 128 | '- [229] java.lang.Object[2560] @ 0x28341f50 | 10,256 | 29,389,400 | '- elementData java.util.Vector @ 0x27f02268 | 24 | 29,389,424 | '- classes sun.misc.Launcher$AppClassLoader @ 0x27ee0090 Native Stack | 72 | 29,414,968 '- Total: 3 entries | | ----------------------------------------------------------------------------------------------------------------------------------------------------- What is special in this test case (aside from the usage of MigPane) is that there is an instance level ObservableList which is registered as the items on ListView. On every iteration this list gets cleared and new nodes are added. If I replace the instance list with a local one, so instead of a clear I set new list in items on ListView, the problem is gone. So I have a workaround for this case, but I suspect scenario like this: list of items gets cleared, ListView reacts and somehow triggers a relayout, MigPane makes a change to the node, the node gets added to the dirty list (which is not weak BTW) in scene, and the node never gets removed. What confuses me is that the node is not part of dirtyNodesA or dirtyNodesB. I see that on each pulse the dirtyNodes are cleared. But the memory dumps says otherwise. This will take a lot more effort to uncover, but the dump indicates that the problem must be somewhere in the ListView / Scene combination. Tom On 2012-11-06 21:31, Tom Eugelink wrote: > Yes they are. > > I wish I could, but as soon as I drop MigPane and use FlowPane, the issue is gone. But I'm still not seeing a MigPane reference in the path to GC. > > Tom > > > On 2012-11-06 20:04, Kevin Rushforth wrote: >> Are frames being rendered during this time? If so, then you may have discovered a bug. If you have a test case you could file JIRA and attach it. >> >> -- Kevin > From fbrunnerlist at gmx.ch Sun Nov 18 16:05:28 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 19 Nov 2012 01:05:28 +0100 Subject: Compact Profiles for the Java Runtime (was: JFX build and deployment - squeaking wheel) In-Reply-To: <0960991D-B64E-4383-A89E-648604986F53@oracle.com> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <6568713.h2jPD6x2RH@shire> <0960991D-B64E-4383-A89E-648604986F53@oracle.com> Message-ID: <1898502.bGQlSukPCl@shire> Hi Bob, Thanks for your response. > We have analyzed two different OSGi implementations and they don't appear to > have any dependencies on these classes. I was more refering to the fact, that OSGi sometimes has issues when packages are split/ incomplete. > Can you provide us with a list of some concrete applications that you > believe require Java Beans? We could investigate the feasibility of > pushing this package down to compact3 if there's enough demand and if it > doesn't have any dependencies that we can't untangle. According to: http://docs.oracle.com/javase/7/docs/api/java/beans/package-use.html JavaBeans are used even by supported Compact1 profile packages such as: - java.util.jar - java.util.logging Often JavaBeans classes such as PropertyChangeListener, Introspector, BeanInfo, PropertyDescriptor etc. are used somewhere in the implementation and not necessarily in the API, so it's a bit hard find the dependencies, but a quick search showed at least: - Eclipse Link - Spring - Several Apache Projects - GlassFish Projects - robokind.org I'm sure the list can go on. Also my own framework, which I'm about to release, uses PropertyChangeListeners under the hood in the JavaFX-independent parts. And what about the other packages I've mentioned: > > javax.accessibility > > javax.activation > > javax.activity > > javax.annotation > > javax.print.* > > javax.sound.* Especially javax.annotation is also quite popular. Regards, Florian Am Freitag, 9. November 2012, 18.34:20 schrieb Bob Vandette: > On Nov 9, 2012, at 5:55 PM, Florian Brunner wrote: > > Hi Bob, > > > > As I understand the profiles/ project Jigsaw in the context of JavaFX is > > it to makte it easier to port Java + JavaFX to other platforms especially > > by omitting AWT. So I understand that the following packages are omitted: > > > > javax.awt.* > > javax.swing.* (dependencies to AWT) > > javax.imagio.* (dependencies to AWT) > > > > But neither are any of the following packages mentioned: > > java.beans.* > > javax.accessibility > > javax.activation > > javax.activity > > javax.annotation > > javax.jws.* > > javax.print.* > > javax.sound.* > > org.omg.* > > > > Now, I understand that the java.beans.PropertyEditor related classes cause > > an issue because of the dependency to AWT, but the JEP 161 states that > > some packages have to be split up anyway (which will probably cause > > issues with OSGi based library, though). And Java Beans patterns (and > > e.g. PropertyChangeListener) are used at many places in applications and > > frameworks. > We really want to avoid splitting packages because this will make it > difficult to transition to Jigsaw in JDK9. > > The PropertyChangeListener classes are problematic. We currently have a > small set of beans classes in compact1 that we'd like to remove. I've > requested the fx team remove any dependency on these class in preparation > for their possible removal. They have a few JIRA's filed to track this > change. > > We have analyzed two different OSGi implementations and they don't appear to > have any dependencies on these classes. > > Can you provide us with a list of some concrete applications that you > believe require Java Beans? We could investigate the feasibility of > pushing this package down to compact3 if there's enough demand and if it > doesn't have any dependencies that we can't untangle. > > > I think there should be a profile (maybe Compact3?), which includes > > everything except AWT related classes to allow maximum reuse and > > portability of existing 3rd party libraries, which make the Java > > ecosystem so rich, so they can be used in JavaFX applications. > The compact3 profile is a very rich set of APIs. The only large group of SE > APIs that are not found in this profile are: Desktop (AWT/SWING/Java2D), > JAX-WS, and Corba. > > For embedded we felt that JAX-WS was too heavy weight and difficult to split > up or subset. We've been working under the assumption that embedded > devices will probably continue to use the smaller kSoap or move to JAX-RS > for lighter weight RestFul web services. > > And another question: > > > > The JEP 161 states: > > "If a package listed in a lower Profile in this table has subpackages then > > those subpackages are included in that Profile unless they are identified > > as members of some higher Profile. Thus the java.lang.reflect package, > > e.g., is in the Compact1 Profile, but java.lang.management is in the > > Compact3 Profile." > > > > But the profile Compact1 states explicitly both java.util and > > java.util.logging. > > > > What about the following packages? > > > > java.util.concurrent > > java.util.concurrent.atomic > > java.util.concurrent.locks > > java.util.jar > > java.util.regex > > java.util.spi > > java.util.zip > > We were attempting to keep the contents of the JEP to the minimum. > > These packages are covered by this statement "If a package listed in a lower > Profile in this table has subpackages then those subpackages are included > in that Profile ". Since they aren't explicitly mentioned in higher > profiles, they are in compact1. > > Feel free to build your own set of linux 86 profiles where you can see > exactly what we've proposed for each profile. > > You could also grab a copy of this repo and look at the > jdk/make/profile-rtjar-includes.txt file that lists the packages included > in each compact profile level. > > http://hg.openjdk.java.net/jdk8/profiles/jdk > > Thanks for the input, > Bob. > > > I think it would be clearer if all subpackages were listed explicitly. > > > > - Florian > > > > Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette: > > > There have been some questions on this list about Jigsaw, compact > > > profiles, > > > embedded, minimal VMs and the JRE customization tool called jrecreate. > > > Richard asked me to jump in to try to clear up any confusion. > > > > > > Here goes .... > > > > > > The Java Modularity Project (project Jigsaw) that was originally planned > > > for JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) > > > was expecting to use Jigsaw in order to provide smaller customizable > > > Java runtimes for embedded devices. Lacking this new functionality, we > > > decided to propose a simpler alternate plan that would enhance the JDK8 > > > specification to allow the distribution of a small set of profiles that > > > are > > > subsets of the full Java runtime. These are called Compact Profiles. > > > We > > > have proposed three compact profiles. A talk and presentation that I > > > gave > > > at JavaOne describes these profiles. > > > > > > https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAE > > > AD8A BE54064406AC304AD59/CON4538_Vandette.pdf > > > > > > The Java Enhancement Proposal (JEP) for this work is here: > > > > > > http://openjdk.java.net/jeps/161 > > > > > > The openjdk repository that implements our current prototype is located > > > here: > > > > > > http://hg.openjdk.java.net/jdk8/profiles > > > > > > The mailing list that discusses the profiles is > > > build-infra-dev at openjdk.java.net since the creation of the new profiles > > > is > > > done using the new configure based JDK build system. > > > > > > This repository allows you to do a build that generates the full JRE, > > > JDK > > > but in addition produces three additional image targets (compact1, > > > compact2, and compact3). > > > > > > In order to achieve the smallest Java runtime for embedded (our goal is > > > around 10MB), we have applied changes to Hotspot that allow us to build > > > a > > > small VM (2-3MB) with reduced functionality. The small VM (minimal) + > > > compact1 profile goal we've set is around 10MB. We're at 11MB today. > > > > > > In addition to the profile bundles and the small VM, we have a reduced > > > Embedded FX stack that we'll run on embedded devices such as the > > > RaspberryPi. This FX Embedded stack is a compatible FX implementation > > > without media and webkit support. The goal for this added stack is > > > 6MB. > > > > > > The jrecreate tool that some of you have asked about is not a java > > > stripping tool. It's main purpose is to assist the embedded developer > > > in customizing Java runtimes. It allows the developer to select which > > > profile, VM, debugging options, compression, security and FX options. > > > It does not strip the full JRE to produce the compact profile. The > > > jrecreate will be packaged with the three compact profile binaries. It > > > simply copies these profiles and applies some additional massaging > > > based on the selected options. > > > > > > We have already pushed the minimal VM changes to JDK8 hotspot and will > > > be > > > open sourcing the compact profile changes since they will be a standard > > > feature of JDK8 (independent of embedded). The current profile changes > > > in > > > our project repository are only functional for Linux x86. > > > > > > We certainly recognize the value that small Java runtimes + reduced FX > > > could have on Java applications published on Web App stores, but the > > > current immediate plan is that the jrecreate tool is only going to be > > > available with our embedded binary downloads since that's where it's > > > needed most. I've had some discussions with our Netbeans team to see > > > what it will take to make Netbeans profile aware. This might be a good > > > way of taking advantage of profiles, reduced FX for producing smaller > > > applications for distribution. > > > > > > I hope this help, > > > Bob. From hang.vo at oracle.com Sun Nov 18 19:19:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 19 Nov 2012 03:19:22 +0000 Subject: hg: openjfx/8/controls/rt: RT-24233: Add NodeOrientation support to TextField. Message-ID: <20121119031928.4879C47A43@hg.openjdk.java.net> Changeset: 45835ed4cac5 Author: leifs Date: 2012-11-18 19:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/45835ed4cac5 RT-24233: Add NodeOrientation support to TextField. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java From hang.vo at oracle.com Mon Nov 19 00:34:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 19 Nov 2012 08:34:41 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26296 Ensemble: Pause Transition hangs Message-ID: <20121119083449.356C747A49@hg.openjdk.java.net> Changeset: 5c36a4a20edb Author: Martin Sladecek Date: 2012-11-19 09:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5c36a4a20edb RT-26296 Ensemble: Pause Transition hangs ! javafx-ui-common/src/javafx/animation/SequentialTransition.java From martin.sladecek at oracle.com Mon Nov 19 01:19:48 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 19 Nov 2012 10:19:48 +0100 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <509B9AC3.8030308@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> <509B9AC3.8030308@oracle.com> Message-ID: <50A9F9B4.70706@oracle.com> Richard, what do you think? The approved changes were pushed to the repository already, so it would be good to fix the issues Pavel found ASAP. And there's also one more thing that should be changed. In the original proposal, there are integer codes in the KeyEvent constructors, but the feature request to add them is still open ( http://javafx-jira.kenai.com/browse/RT-20448). Since KeyEvents currently operates with KeyCode enum only, these constructors should be removed and only the constructor with KeyCode should be left in the API. Thanks, -Martin On 11/08/2012 12:42 PM, Pavel Safrata wrote: > Hello, > shame on me, I'm really sorry for getting here so late. I've just read > through the proposal and I'd like to propose several changes before it > starts to be used by apps. > >> DragEvent: >> public DragEvent copyFor(Object source, EventTarget target, Object >> gestureSource, Object gestureTarget, Dragboard dragboard) >> public DragEvent copyFor(Object source, EventTarget target, Object >> gestureSource, Object gestureTarget, TransferMode transferMode, >> EventType eventType) >> > > I think we should not complicate the API with those two methods. They > have no obvious usage for users and I think all existing internal > usages can be removed by a simple refactoring. > >> MouseEvent: >> public MouseEvent(EventType eventType, double >> x, double y, double screenX, double screenY, MouseButton button,int >> clickCount, boolean shiftDown, boolean controlDown, boolean altDown, >> boolean metaDown, boolean primaryButtonDown, boolean >> middleButtonDown, boolean secondaryButtonDown, boolean synthesized, >> boolean popupTrigger) > > I would drop this one, there is a similar one with one more argument: > stillSincePress. This argument is not that special, we can use the > other method instead. There are places in robot where we're not sure > what to put there, but it doesn't really justify for having this > duplicated method (it should rather be fixed there). > >> TouchEvent: >> public boolean isDirect() // was impl_ because (according to a >> comment in code) there are no indirect events yet, but GestureEvent >> already has this public. > > I think we should not publish isDirect() and that we should remove the > "direct" argument from constructors. Currently touch events are always > direct. We are able to produce indirect touch events from TrackPad, > but our API specifically states that we don't and won't deliver them. > They are just prepared for the possibility that we add custom gesture > recognizers in the future that may work with those indirect events, > but it is not really certain we'll ever do that, and if we will, it is > not certain if it will be allowed to feed custom events to them. So > publishing this useless flag would be pretty confusing right now. > > Finally, to make TouchEvent constructor usable, we need also > constructor for TouchPoint. > > Let me once more apologize for the late response. > Thaks, > Pavel > >> >> >> -Martin >> >> On 06/15/2012 11:44 PM, Richard Bair wrote: >>>>>> As for the approach, I think you do the constructors with all >>>>>> params (since events are immutable you have no choice really -- >>>>>> static factory or constructor and I prefer in this case a >>>>>> constructor) + builder (auto generated). >>>>> And what do you think about impl_copy methods? Personally I think >>>>> we should remove them completely and turn them to some internal >>>>> utility methods. >>>> My initial thought was a copy constructor. >>>> >>>>> Also, some events are not 100% immutable, as they are modified >>>>> during the Scene processing through some impl_methods, like >>>>> MouseEvent.impl_setClickParam. We'd either need to make some/all >>>>> of the Event fields protected and do this modifications through >>>>> subclasses or create some "accessor" in javafx.scene.input package >>>>> for calling these methods from javafx.scene package. >>>> Good question, I guess we can revisit these in context of the other >>>> impl_ method removal things we're working on. >>>> >>>> Richard > From lehmann at media-interactive.de Mon Nov 19 01:52:44 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 19 Nov 2012 10:52:44 +0100 Subject: Generated JNLP and HTML files - mysterious values In-Reply-To: References: <047DCCE5-DCE8-4215-BD56-70DA16A9A53C@oracle.com> <042D52B2-8DE6-49DE-949B-DB4D643462AF@oracle.com> Message-ID: <50AA016C.3050801@media-interactive.de> I may know what happens (or I could be wrong). In any case, we have had repeatedly the case (on Win64) where webstart would want to install the FX runtime because it is missing, then downloads it, finds it is already installed, continues with running the original webstart application which then fails because FX is not installed (failed to load the Platform class). If that sentence was confusing, it is even more confusing to a user. Even if they are technically adapt. This particular case was probably caused by FX "2.1" instead of "2.2" in the JNLP, and by using Webstart from a different JRE than intended. But it happens easily. Too easily. I guess we will have to make an FAQ or something for our customers to fix problems with Webstart. And currently we "fix" that by poking around until it runs... Worries me. Rgds Werner On 17.11.2012 07:22, Daniel Zwolenski wrote: > What happens if that JNLP I sent is used on a 64bit windows machine running > Java 1.6. The URL looks to be 32bit specific so would it download a 32bit > version of JFX into a 64bit JVM? From steve.x.northover at oracle.com Mon Nov 19 07:52:58 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 19 Nov 2012 10:52:58 -0500 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <50A9F9B4.70706@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> <509B9AC3.8030308@oracle.com> <50A9F9B4.70706@oracle.com> Message-ID: <50AA55DA.9050702@oracle.com> Hi all, This sounds right. Can the integer codes in the constructors be used for anything today? Steve On 19/11/2012 4:19 AM, Martin Sladecek wrote: > Richard, what do you think? > > The approved changes were pushed to the repository already, so it > would be good to fix the issues Pavel found ASAP. > > And there's also one more thing that should be changed. In the > original proposal, there are integer codes in the KeyEvent > constructors, but the feature request to add them is still open ( > http://javafx-jira.kenai.com/browse/RT-20448). Since KeyEvents > currently operates with KeyCode enum only, these constructors should > be removed and only the constructor with KeyCode should be left in the > API. > > Thanks, > -Martin > > > On 11/08/2012 12:42 PM, Pavel Safrata wrote: >> Hello, >> shame on me, I'm really sorry for getting here so late. I've just >> read through the proposal and I'd like to propose several changes >> before it starts to be used by apps. >> >>> DragEvent: >>> public DragEvent copyFor(Object source, EventTarget target, Object >>> gestureSource, Object gestureTarget, Dragboard dragboard) >>> public DragEvent copyFor(Object source, EventTarget target, Object >>> gestureSource, Object gestureTarget, TransferMode transferMode, >>> EventType eventType) >>> >> >> I think we should not complicate the API with those two methods. They >> have no obvious usage for users and I think all existing internal >> usages can be removed by a simple refactoring. >> >>> MouseEvent: >>> public MouseEvent(EventType eventType, double >>> x, double y, double screenX, double screenY, MouseButton button,int >>> clickCount, boolean shiftDown, boolean controlDown, boolean altDown, >>> boolean metaDown, boolean primaryButtonDown, boolean >>> middleButtonDown, boolean secondaryButtonDown, boolean synthesized, >>> boolean popupTrigger) >> >> I would drop this one, there is a similar one with one more argument: >> stillSincePress. This argument is not that special, we can use the >> other method instead. There are places in robot where we're not sure >> what to put there, but it doesn't really justify for having this >> duplicated method (it should rather be fixed there). >> >>> TouchEvent: >>> public boolean isDirect() // was impl_ because (according to a >>> comment in code) there are no indirect events yet, but GestureEvent >>> already has this public. >> >> I think we should not publish isDirect() and that we should remove >> the "direct" argument from constructors. Currently touch events are >> always direct. We are able to produce indirect touch events from >> TrackPad, but our API specifically states that we don't and won't >> deliver them. They are just prepared for the possibility that we add >> custom gesture recognizers in the future that may work with those >> indirect events, but it is not really certain we'll ever do that, and >> if we will, it is not certain if it will be allowed to feed custom >> events to them. So publishing this useless flag would be pretty >> confusing right now. >> >> Finally, to make TouchEvent constructor usable, we need also >> constructor for TouchPoint. >> >> Let me once more apologize for the late response. >> Thaks, >> Pavel >> >>> >>> >>> -Martin >>> >>> On 06/15/2012 11:44 PM, Richard Bair wrote: >>>>>>> As for the approach, I think you do the constructors with all >>>>>>> params (since events are immutable you have no choice really -- >>>>>>> static factory or constructor and I prefer in this case a >>>>>>> constructor) + builder (auto generated). >>>>>> And what do you think about impl_copy methods? Personally I think >>>>>> we should remove them completely and turn them to some internal >>>>>> utility methods. >>>>> My initial thought was a copy constructor. >>>>> >>>>>> Also, some events are not 100% immutable, as they are modified >>>>>> during the Scene processing through some impl_methods, like >>>>>> MouseEvent.impl_setClickParam. We'd either need to make some/all >>>>>> of the Event fields protected and do this modifications through >>>>>> subclasses or create some "accessor" in javafx.scene.input >>>>>> package for calling these methods from javafx.scene package. >>>>> Good question, I guess we can revisit these in context of the >>>>> other impl_ method removal things we're working on. >>>>> >>>>> Richard >> > From pavel.safrata at oracle.com Mon Nov 19 08:25:25 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 19 Nov 2012 17:25:25 +0100 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <50AA55DA.9050702@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> <4FE2E232.8090405@oracle.com> <4DB2CFCA-F55B-4364-917C-274F31BAEFDA@oracle.com> <509B9AC3.8030308@oracle.com> <50A9F9B4.70706@oracle.com> <50AA55DA.9050702@oracle.com> Message-ID: <50AA5D75.60007@oracle.com> Hi Steve, the code maps the integer to KeyCode and does the same thing as the other constructor accepting the KeyCode directly. So the only use right now would be creating a KeyEvent based on some native event. However, I believe that if we want to support it, we should rather consider publishing the KeyCode method that does the mapping. That would be done in scope of the RT-20448, right now the raw code is (should be) completely hidden to users. Pavel On 19.11.2012 16:52, steve.x.northover at oracle.com wrote: > Hi all, > > This sounds right. Can the integer codes in the constructors be used > for anything today? > > Steve > > On 19/11/2012 4:19 AM, Martin Sladecek wrote: >> Richard, what do you think? >> >> The approved changes were pushed to the repository already, so it >> would be good to fix the issues Pavel found ASAP. >> >> And there's also one more thing that should be changed. In the >> original proposal, there are integer codes in the KeyEvent >> constructors, but the feature request to add them is still open ( >> http://javafx-jira.kenai.com/browse/RT-20448). Since KeyEvents >> currently operates with KeyCode enum only, these constructors should >> be removed and only the constructor with KeyCode should be left in >> the API. >> >> Thanks, >> -Martin >> >> >> On 11/08/2012 12:42 PM, Pavel Safrata wrote: >>> Hello, >>> shame on me, I'm really sorry for getting here so late. I've just >>> read through the proposal and I'd like to propose several changes >>> before it starts to be used by apps. >>> >>>> DragEvent: >>>> public DragEvent copyFor(Object source, EventTarget target, Object >>>> gestureSource, Object gestureTarget, Dragboard dragboard) >>>> public DragEvent copyFor(Object source, EventTarget target, Object >>>> gestureSource, Object gestureTarget, TransferMode transferMode, >>>> EventType eventType) >>>> >>> >>> I think we should not complicate the API with those two methods. >>> They have no obvious usage for users and I think all existing >>> internal usages can be removed by a simple refactoring. >>> >>>> MouseEvent: >>>> public MouseEvent(EventType eventType, double >>>> x, double y, double screenX, double screenY, MouseButton button,int >>>> clickCount, boolean shiftDown, boolean controlDown, boolean >>>> altDown, boolean metaDown, boolean primaryButtonDown, boolean >>>> middleButtonDown, boolean secondaryButtonDown, boolean synthesized, >>>> boolean popupTrigger) >>> >>> I would drop this one, there is a similar one with one more >>> argument: stillSincePress. This argument is not that special, we can >>> use the other method instead. There are places in robot where we're >>> not sure what to put there, but it doesn't really justify for having >>> this duplicated method (it should rather be fixed there). >>> >>>> TouchEvent: >>>> public boolean isDirect() // was impl_ because (according to a >>>> comment in code) there are no indirect events yet, but GestureEvent >>>> already has this public. >>> >>> I think we should not publish isDirect() and that we should remove >>> the "direct" argument from constructors. Currently touch events are >>> always direct. We are able to produce indirect touch events from >>> TrackPad, but our API specifically states that we don't and won't >>> deliver them. They are just prepared for the possibility that we add >>> custom gesture recognizers in the future that may work with those >>> indirect events, but it is not really certain we'll ever do that, >>> and if we will, it is not certain if it will be allowed to feed >>> custom events to them. So publishing this useless flag would be >>> pretty confusing right now. >>> >>> Finally, to make TouchEvent constructor usable, we need also >>> constructor for TouchPoint. >>> >>> Let me once more apologize for the late response. >>> Thaks, >>> Pavel >>> >>>> >>>> >>>> -Martin >>>> >>>> On 06/15/2012 11:44 PM, Richard Bair wrote: >>>>>>>> As for the approach, I think you do the constructors with all >>>>>>>> params (since events are immutable you have no choice really -- >>>>>>>> static factory or constructor and I prefer in this case a >>>>>>>> constructor) + builder (auto generated). >>>>>>> And what do you think about impl_copy methods? Personally I >>>>>>> think we should remove them completely and turn them to some >>>>>>> internal utility methods. >>>>>> My initial thought was a copy constructor. >>>>>> >>>>>>> Also, some events are not 100% immutable, as they are modified >>>>>>> during the Scene processing through some impl_methods, like >>>>>>> MouseEvent.impl_setClickParam. We'd either need to make some/all >>>>>>> of the Event fields protected and do this modifications through >>>>>>> subclasses or create some "accessor" in javafx.scene.input >>>>>>> package for calling these methods from javafx.scene package. >>>>>> Good question, I guess we can revisit these in context of the >>>>>> other impl_ method removal things we're working on. >>>>>> >>>>>> Richard >>> >> From hang.vo at oracle.com Mon Nov 19 14:33:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 19 Nov 2012 22:33:20 +0000 Subject: hg: openjfx/8/controls/rt: Fixed copyright and removed author Message-ID: <20121119223324.DC3B047A5E@hg.openjdk.java.net> Changeset: e45a7663b26d Author: raginip Date: 2012-11-19 14:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e45a7663b26d Fixed copyright and removed author ! 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-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 From randahl at rockit.dk Mon Nov 19 16:54:36 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 20 Nov 2012 01:54:36 +0100 Subject: Avoiding effect rotation? Message-ID: I noticed that if you rotate a beach ball with JavaFX, its drop shadow rotates along with it. For a beach ball at least, this is not natural. Let's say that the drop shadow is located below the ball at its right-hand side. Once you rotate the ball the location of the drop shadow starts circling the ball, which obviously never happens in real life. So, while I can see why rotatable effects might be useful in some cases, at least for a beach ball it looks odd. I would imagine that the most common case is that you do not want a drop shadow to rotate along with its object, but can anyone confirm that this is an intentional design decision, and / or if there is some work-around for this. Thanks Randahl From hang.vo at oracle.com Mon Nov 19 17:18:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 01:18:48 +0000 Subject: hg: openjfx/8/controls/rt: RT-26172: revert changes related to Parent having its own stylemanager Message-ID: <20121120011853.2B38D47A62@hg.openjdk.java.net> Changeset: ae5697996ff1 Author: David Grieve Date: 2012-11-19 20:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ae5697996ff1 RT-26172: revert changes related to Parent having its own stylemanager - javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java - javafx-ui-common/src/com/sun/javafx/css/SceneStyleManager.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/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java From swpalmer at gmail.com Mon Nov 19 17:46:49 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 19 Nov 2012 20:46:49 -0500 Subject: Avoiding effect rotation? In-Reply-To: References: Message-ID: On 2012-11-19, at 7:54 PM, Randahl Fink Isaksen wrote: > I noticed that if you rotate a beach ball with JavaFX, its drop shadow rotates along with it. For a beach ball at least, this is not natural. Let's say that the drop shadow is located below the ball at its right-hand side. Once you rotate the ball the location of the drop shadow starts circling the ball, which obviously never happens in real life. So, while I can see why rotatable effects might be useful in some cases, at least for a beach ball it looks odd. > > I would imagine that the most common case is that you do not want a drop shadow to rotate along with its object, but can anyone confirm that this is an intentional design decision, and / or if there is some work-around for this. I haven't tried it yet, but as a potential work-around I would place the rotated beach ball in a Group and then apply the shadow to the Group. Scott From hang.vo at oracle.com Tue Nov 20 05:33:38 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 13:33:38 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-25977: added missing KeyCombination.ModifierValue javadoc Message-ID: <20121120133344.39A9647A7B@hg.openjdk.java.net> Changeset: 0c13364d5766 Author: Lubomir Nerad Date: 2012-11-20 14:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0c13364d5766 Fix for RT-25977: added missing KeyCombination.ModifierValue javadoc ! javafx-ui-common/src/javafx/scene/input/KeyCombination.java From hang.vo at oracle.com Tue Nov 20 07:34:05 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 15:34:05 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-26241: made Screen class more robust Message-ID: <20121120153410.B410D47A83@hg.openjdk.java.net> Changeset: 591592a4ae64 Author: Lubomir Nerad Date: 2012-11-20 16:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/591592a4ae64 Fix for RT-26241: made Screen class more robust ! javafx-ui-common/src/javafx/stage/Screen.java + javafx-ui-common/test/unit/javafx/stage/ScreenTest.java From hang.vo at oracle.com Tue Nov 20 08:19:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 16:19:01 +0000 Subject: hg: openjfx/8/controls/rt: 12 new changesets Message-ID: <20121120161918.B009047A87@hg.openjdk.java.net> Changeset: 37cdc2382b25 Author: David Grieve Date: 2012-11-20 10:34 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/37cdc2382b25 unit test fixes and ignores ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleManagerTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java Changeset: f5e438202f2d Author: rbair Date: 2012-11-06 14:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f5e438202f2d Open source of decora-compiler + decora-compiler/.classpath + decora-compiler/.project + decora-compiler/build.xml + decora-compiler/nbproject/project.xml + decora-compiler/project.properties + decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g + decora-compiler/src/com/sun/scenario/effect/compiler/JSLC.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/ES2Backend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/GLSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/HLSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/SLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWCallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWTreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MECallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/METreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEBackend.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSECallScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEFuncImpls.java + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg + decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSETreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/BaseType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/BinaryOpType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/CoreSymbols.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/FuncImpl.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Function.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Param.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Precision.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Qualifier.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/SymbolTable.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Type.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/UnaryOpType.java + decora-compiler/src/com/sun/scenario/effect/compiler/model/Variable.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ArrayAccessExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/BinaryExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/BreakStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/CallExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/CompoundStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ContinueStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DeclStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DiscardStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/DoWhileStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Expr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ExprStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ExtDecl.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/FieldSelectExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ForStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/FuncDef.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/GlueBlock.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/LiteralExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ParenExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ProgramUnit.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/ReturnStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/SelectStmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Stmt.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/Tree.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeMaker.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeScanner.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/TreeVisitor.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/UnaryExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VarDecl.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VariableExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/VectorCtorExpr.java + decora-compiler/src/com/sun/scenario/effect/compiler/tree/WhileStmt.java + decora-compiler/test/com/sun/scenario/effect/compiler/SymbolTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/BoolTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/CommentTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/FloatTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/IdentifierTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/IntegerTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/LexerBase.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/LineCommentTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/TypeTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/lexer/WhitespaceTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/AddExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/AssignmentExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/EqualityExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/Expressions.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/ExternalDeclarationTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/FieldSelectTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/FullySpecifiedTypeTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/IterationStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/JumpStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/MultExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/ParserBase.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/PrimaryExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/RelationalExprTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/SelectionStatementTest.java + decora-compiler/test/com/sun/scenario/effect/compiler/parser/UnaryExprTest.java Changeset: 7995eb685119 Author: peterz Date: 2012-11-07 07:33 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7995eb685119 RT-22493 WebView should use Toolkit for initialization ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubWebView.java Changeset: d3eeaeeb85bd Author: Martin Sladecek Date: 2012-11-07 14:30 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d3eeaeeb85bd RT-26094 Event classes should have serialVersionUID ! javafx-ui-common/src/com/sun/javafx/stage/FocusUngrabEvent.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/InputEvent.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.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/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java ! javafx-ui-common/src/javafx/stage/WindowEvent.java Changeset: 7e871632dfe4 Author: Felipe Heidrich Date: 2012-11-07 21:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7e871632dfe4 [ECLIPSE ONLY] fixing classpath due changes in decora ! .classpath Changeset: ab55578e4692 Author: kcr Date: 2012-11-09 17:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ab55578e4692 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 09cbcb519b6d Author: Felipe Heidrich Date: 2012-11-09 22:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/09cbcb519b6d Merge Rich Text - RT-17392 (part1) including fixes for RT-20645, RT-24735, RT-24634, RT-24467, RT-24435, RT-24012, RT-23231, RT-16853, RT-14356 + javafx-ui-common/src/com/sun/javafx/scene/text/GlyphList.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLayoutFactory.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextLine.java + javafx-ui-common/src/com/sun/javafx/scene/text/TextSpan.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/test/unit/javafx/scene/text/Text_builder_Test.java ! javafx-ui-common/test/unit/javafx/scene/text/Text_onInvalidate_Test.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayoutFactory.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 194fe6a98a4a Author: Artem Ananiev Date: 2012-11-12 11:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/194fe6a98a4a com.sun.glass.taskbarApplication system property is renamed to glass.taskbarApplication ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java Changeset: 5ca1d6e4604d Author: Martin Sladecek Date: 2012-11-13 14:40 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5ca1d6e4604d RT-26126 Popup menus stopped working ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java Changeset: 38b5c364c630 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-13 09:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/38b5c364c630 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 5047d4016211 Author: hudson Date: 2012-11-15 21:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5047d4016211 Added tag 8.0-b65 for changeset 38b5c364c630 ! .hgtags Changeset: ca9d915db72f Author: David Grieve Date: 2012-11-20 11:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ca9d915db72f branch merge - javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java - javafx-ui-common/src/com/sun/javafx/css/SceneStyleManager.java ! javafx-ui-common/src/javafx/scene/Scene.java From hang.vo at oracle.com Tue Nov 20 09:03:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 17:03:34 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25618: ArcTo needs javadoc Message-ID: <20121120170336.316E747A8D@hg.openjdk.java.net> Changeset: 37c2ab46c51d Author: Eva Krejcirova Date: 2012-11-20 17:52 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/37c2ab46c51d RT-25618: ArcTo needs javadoc ! javafx-ui-common/src/javafx/scene/shape/ArcTo.java + javafx-ui-common/src/javafx/scene/shape/doc-files/arcto-flags.png + javafx-ui-common/src/javafx/scene/shape/doc-files/arcto.png From richard.bair at oracle.com Tue Nov 20 06:41:37 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 20 Nov 2012 15:41:37 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <4FFEDD3B.6030109@oracle.com> References: <4FFEDD3B.6030109@oracle.com> Message-ID: > *GridPaneBuilder* > addColumn(int columnIndex, Node... children) > addRow(int rowIndex, Node... children) > add(Node child, int columnIndex, int rowIndex) > add(Node child, int columnIndex, int rowIndex, int colspan, int rowspan) Do we use columnIndex, rowIndex elsewhere? Usually I've seen "row, col", but "x, y", so it could go either way, but we should be consistent with elsewhere in the platform. > *RegionBuilder* > maxSize(double width, double height) > minSize(double width, double height) > prefSize(double width, double height) > These will be inherited by all layout builders. > > A also propose to add following convenience methods which don't have direct counterpart in layout classes (the constraints can be specified only by static methods there) > Adding these would enable us to add child with constraint to layout without having to hold a reference to it. e.g > Hbox h = HBoxBuilder.create().add(CircleBuilder.create...build(), margin).build(); > instead of > Circle circle = CircleBuilder.create...build(); > Hbox h = HBoxBuilder.create().children(circle).build(); > Hbox.setMargin (circle, margin); > > The proposed methods are: > *AnchorPaneBuilder* > add(Node child, Double topAnchor, Double rightAnchor, Double bottomAnchor, Double leftAnchor) Can these be primitive doubles instead? > *BorderPaneBuilder* > add(Node child, Pos alignment) > add(Node child, Insets margin) > add(Node child, Pos alignment, Insets margin) > > *FlowPaneBuilder* > add(Node child, Insets margin) > > *GridPaneBuilder* > add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment) > add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment, Priority hgrow, Priority vgrow) > add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment, Priority hgrow, Priority vgrow, Insets margin) > > *HBoxBuilder* > add(Node child, Priority hgrow) > add(Node child, Insets margin) > add(Node child, Priority hgrow, Insets margin) > > *StackPaneBuilder* > add(Node child, Pos alignment) > add(Node child, Insets margin) > add(Node child, Pos alignment, Insets margin) > > *TilePaneBuilder* > add(Node child, Pos alignment) > add(Node child, Insets margin) > add(Node child, Pos alignment, Insets margin) > > *VBoxBuilder* > add(Node child, Priority vgrow) > add(Node child, Insets margin) > add(Node child, Priority vgrow, Insets margin) OK. Richard From richard.bair at oracle.com Tue Nov 20 06:46:03 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 20 Nov 2012 15:46:03 +0100 Subject: Extending builders: PathBuilder In-Reply-To: <4FFDAD1C.2010501@oracle.com> References: <4FFDAD1C.2010501@oracle.com> Message-ID: <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> > There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g. > > PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); > or > PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); > > There are several approaches for this : > > 1.) appending everything into one list so both of former examples return the same path. This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed? Richard From richard.bair at oracle.com Tue Nov 20 10:17:33 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 20 Nov 2012 19:17:33 +0100 Subject: Extending builders: StageBuilder In-Reply-To: <4FFD905B.9070009@oracle.com> References: <4FFD905B.9070009@oracle.com> Message-ID: <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> +1. Which issue should I put api-approved onto? Richard On Jul 11, 2012, at 4:40 PM, Eva Krejcirova wrote: > Hi All, > > this is the first of several emails about adding additional methods to existing builder classes, this time about StageBuilder class. > > First some background: there is an issue (RT-19260) with StageBuilder.style() method - it only passes the style to the constructor of Stage, which means that calling applyTo on the builder doesn't work. The style on Stage can be changed with initStyle, but the StageBuilder doesn't currently use it. With the new version of the builder, the builder will call initStyle in applyTo, so the applyTo will work. However, if called after Stage.show, it will throw an exception - the same way as the Stage.initStyle does. > > Together with this fix, I propose to add following methods to StageBuilder which also set properties via init... method: > > *modality* : > public StageBuilder modality(Modality modality) > - will set modality via initModality > > *owner* : > public StageBuilder owner(Window owner) > - will set owner via initOwner > > > They will behave similar to style() method - i.e. applyTo will throw an exception when called after Stage.show() and also throw an exception if called on a primary stage: > StageBuilder builder = StageBuilder.create().modality(Modality.WINDOW_MODAL); > Stage stage = builder.build(); // this is OK > stage.show(); > builder.modality(NONE).applyTo(stage); // this will throw an exception in applyTo > > What do you think? > > Thanks, > Eva From hang.vo at oracle.com Tue Nov 20 10:48:15 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 18:48:15 +0000 Subject: hg: openjfx/8/graphics/rt: 8 new changesets Message-ID: <20121120184825.762A047A93@hg.openjdk.java.net> Changeset: 5047d4016211 Author: hudson Date: 2012-11-15 21:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5047d4016211 Added tag 8.0-b65 for changeset 38b5c364c630 ! .hgtags Changeset: 30a695b3c758 Author: Paru Somashekar Date: 2012-11-14 14:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30a695b3c758 RT-26148 Add RTL support for Chart ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 45835ed4cac5 Author: leifs Date: 2012-11-18 19:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/45835ed4cac5 RT-24233: Add NodeOrientation support to TextField. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java Changeset: e45a7663b26d Author: raginip Date: 2012-11-19 14:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e45a7663b26d Fixed copyright and removed author ! 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-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 Changeset: ae5697996ff1 Author: David Grieve Date: 2012-11-19 20:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ae5697996ff1 RT-26172: revert changes related to Parent having its own stylemanager - javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java - javafx-ui-common/src/com/sun/javafx/css/SceneStyleManager.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/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 37cdc2382b25 Author: David Grieve Date: 2012-11-20 10:34 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/37cdc2382b25 unit test fixes and ignores ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleManagerTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java Changeset: ca9d915db72f Author: David Grieve Date: 2012-11-20 11:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ca9d915db72f branch merge - javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java - javafx-ui-common/src/com/sun/javafx/css/SceneStyleManager.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: f4ac2f436738 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-20 10:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4ac2f436738 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project From hang.vo at oracle.com Tue Nov 20 13:04:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 21:04:00 +0000 Subject: hg: openjfx/8/controls/rt: RT-26326: distance to look for font styles was zero if no shorthand was found. Message-ID: <20121120210404.46AD047A9E@hg.openjdk.java.net> Changeset: a7ce5f766cf4 Author: David Grieve Date: 2012-11-20 13:55 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a7ce5f766cf4 RT-26326: distance to look for font styles was zero if no shorthand was found. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java From james.graham at oracle.com Tue Nov 20 14:02:03 2012 From: james.graham at oracle.com (Jim Graham) Date: Tue, 20 Nov 2012 14:02:03 -0800 Subject: Avoiding effect rotation? In-Reply-To: References: Message-ID: <50ABFDDB.2030105@oracle.com> Yes, that is the intended solution/way of looking at the system. For better or worse we apply the transform to the effected node rather than applying the effect to the transformed node and any of these ordering behaviors can be renegotiated by using encapsulated groups. (Hopefully we've created a default order of operations on a node that matches the most common expectations, but there will always be exceptions to any rule...) ...jim On 11/19/12 5:46 PM, Scott Palmer wrote: > On 2012-11-19, at 7:54 PM, Randahl Fink Isaksen wrote: > >> I noticed that if you rotate a beach ball with JavaFX, its drop shadow rotates along with it. For a beach ball at least, this is not natural. Let's say that the drop shadow is located below the ball at its right-hand side. Once you rotate the ball the location of the drop shadow starts circling the ball, which obviously never happens in real life. So, while I can see why rotatable effects might be useful in some cases, at least for a beach ball it looks odd. >> >> I would imagine that the most common case is that you do not want a drop shadow to rotate along with its object, but can anyone confirm that this is an intentional design decision, and / or if there is some work-around for this. > > I haven't tried it yet, but as a potential work-around I would place the rotated beach ball in a Group and then apply the shadow to the Group. > > Scott > From hang.vo at oracle.com Tue Nov 20 14:03:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 22:03:37 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-25333: setPixels can ignore the x, y coordinates in the request Message-ID: <20121120220339.7110247AA2@hg.openjdk.java.net> Changeset: 6fc99f747830 Author: flar Date: 2012-11-20 13:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6fc99f747830 Fix RT-25333: setPixels can ignore the x,y coordinates in the request ! javafx-ui-common/src/com/sun/javafx/image/ByteToBytePixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/ByteToIntPixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/IntToBytePixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/IntToIntPixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/PixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToByteConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToIntConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToByteConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToIntConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/image/ConverterTest.java From hang.vo at oracle.com Tue Nov 20 15:34:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 20 Nov 2012 23:34:27 +0000 Subject: hg: openjfx/8/graphics/rt: RT-17392: Multi-line, multi-style, rich text support Message-ID: <20121120233428.543E147AA4@hg.openjdk.java.net> Changeset: 45aeaba1af4a Author: Felipe Heidrich Date: 2012-11-20 15:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/45aeaba1af4a RT-17392: Multi-line, multi-style, rich text support ! javafx-ui-common/src/javafx/scene/text/Text.java + javafx-ui-common/src/javafx/scene/text/TextFlow.java From hang.vo at oracle.com Tue Nov 20 16:37:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 21 Nov 2012 00:37:47 +0000 Subject: hg: openjfx/sandbox-8/controls/rt: Further work on TreeTableView: now with improved CSS styling and behavior implementation (for keyboard navigation) Message-ID: <20121121003749.716AA47AA8@hg.openjdk.java.net> Changeset: ddd73130f154 Author: jgiles Date: 2012-11-21 13:02 +1300 URL: http://hg.openjdk.java.net/openjfx/sandbox-8/controls/rt/rev/ddd73130f154 Further work on TreeTableView: now with improved CSS styling and behavior implementation (for keyboard navigation) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.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/TablePosition.java + javafx-ui-controls/src/javafx/scene/control/TablePositionBase.java ! javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java From pavel.safrata at oracle.com Wed Nov 21 00:19:10 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 21 Nov 2012 09:19:10 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> Message-ID: <50AC8E7E.20203@oracle.com> On 20.11.2012 15:41, Richard Bair wrote: >> *GridPaneBuilder* >> addColumn(int columnIndex, Node... children) >> addRow(int rowIndex, Node... children) >> add(Node child, int columnIndex, int rowIndex) >> add(Node child, int columnIndex, int rowIndex, int colspan, int rowspan) > Do we use columnIndex, rowIndex elsewhere? Usually I've seen "row, col", but "x, y", so it could go either way, but we should be consistent with elsewhere in the platform. > > In transforms we address matrix elements by "row, column". Pavel From mp at jugs.org Wed Nov 21 00:35:33 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 21 Nov 2012 09:35:33 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AC8E7E.20203@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50AC8E7E.20203@oracle.com> Message-ID: <50AC9255.4080304@jugs.org> Am 21.11.2012 09:19, schrieb Pavel Safrata: > On 20.11.2012 15:41, Richard Bair wrote: >>> *GridPaneBuilder* >>> addColumn(int columnIndex, Node... children) >>> addRow(int rowIndex, Node... children) >>> add(Node child, int columnIndex, int rowIndex) >>> add(Node child, int columnIndex, int rowIndex, int colspan, int >>> rowspan) >> Do we use columnIndex, rowIndex elsewhere? Usually I've seen "row, >> col", but "x, y", so it could go either way, but we should be >> consistent with elsewhere in the platform. >> >> > > In transforms we address matrix elements by "row, column". > > Pavel It is probably too late to be really consistent. For example in GridPane you have add(Node child, int columnIndex, int rowIndex) whereas for the transforms you have "row, column" as Pavel has pointed out. The only thing you can and should do is to make at least the builders consistent with the class they build. Michael -- -------------------------------------------------------------------------------------- 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 Wed Nov 21 00:38:47 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 21 Nov 2012 09:38:47 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <4FFEDD3B.6030109@oracle.com> References: <4FFEDD3B.6030109@oracle.com> Message-ID: <50AC9317.90306@tbee.org> Another approach would be to introduce formal constraint classes. I've blogged about this and wrote three test classes (HBox, VBox and GridPane). http://tbeernot.wordpress.com/2012/11/10/javafx-layout-a-silver-lining/ The exact API is under debate. However, the advantage of using explicit constraint classes is that you'll not only lose the weird static methods, but it is also possible to specify different constraints for all layouts that a node may become a child of (because of animation). The current approach of having a constraint map in a node is questionable; who says that if I want valigment=left in one layout, I also want that in another? Tom On 2012-07-12 16:20, Eva Krejcirova wrote: > Hi, > > I would like to add following methods to our layout builders. Similar convenience methods are present in their respective layout classes: > > *GridPaneBuilder* > addColumn(int columnIndex, Node... children) > addRow(int rowIndex, Node... children) > add(Node child, int columnIndex, int rowIndex) > add(Node child, int columnIndex, int rowIndex, int colspan, int rowspan) > > *RegionBuilder* > maxSize(double width, double height) > minSize(double width, double height) > prefSize(double width, double height) > These will be inherited by all layout builders. > > A also propose to add following convenience methods which don't have direct counterpart in layout classes (the constraints can be specified only by static methods there) > Adding these would enable us to add child with constraint to layout without having to hold a reference to it. e.g > Hbox h = HBoxBuilder.create().add(CircleBuilder.create...build(), margin).build(); > instead of > Circle circle = CircleBuilder.create...build(); > Hbox h = HBoxBuilder.create().children(circle).build(); > Hbox.setMargin (circle, margin); > > The proposed methods are: > *AnchorPaneBuilder* > add(Node child, Double topAnchor, Double rightAnchor, Double bottomAnchor, Double leftAnchor) > > *BorderPaneBuilder* > add(Node child, Pos alignment) > add(Node child, Insets margin) > add(Node child, Pos alignment, Insets margin) > > *FlowPaneBuilder* > add(Node child, Insets margin) > > *GridPaneBuilder* > add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment) > add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment, Priority hgrow, Priority vgrow) > add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment, Priority hgrow, Priority vgrow, Insets margin) > > *HBoxBuilder* > add(Node child, Priority hgrow) > add(Node child, Insets margin) > add(Node child, Priority hgrow, Insets margin) > > *StackPaneBuilder* > add(Node child, Pos alignment) > add(Node child, Insets margin) > add(Node child, Pos alignment, Insets margin) > > *TilePaneBuilder* > add(Node child, Pos alignment) > add(Node child, Insets margin) > add(Node child, Pos alignment, Insets margin) > > *VBoxBuilder* > add(Node child, Priority vgrow) > add(Node child, Insets margin) > add(Node child, Priority vgrow, Insets margin) > > Thanks, > Eva From richard.bair at oracle.com Wed Nov 21 00:46:24 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 21 Nov 2012 09:46:24 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AC9317.90306@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> Message-ID: I wanted constraint classes from the start. There was a problem there, which I don't accurately remember now, but I do want to see some discussion around deprecating (or at least no longer depending on) the static methods and having some constraint classes again. Richard On Nov 21, 2012, at 9:38 AM, Tom Eugelink wrote: > Another approach would be to introduce formal constraint classes. I've blogged about this and wrote three test classes (HBox, VBox and GridPane). > > http://tbeernot.wordpress.com/2012/11/10/javafx-layout-a-silver-lining/ > > The exact API is under debate. However, the advantage of using explicit constraint classes is that you'll not only lose the weird static methods, but it is also possible to specify different constraints for all layouts that a node may become a child of (because of animation). The current approach of having a constraint map in a node is questionable; who says that if I want valigment=left in one layout, I also want that in another? > > Tom > > > On 2012-07-12 16:20, Eva Krejcirova wrote: >> Hi, >> >> I would like to add following methods to our layout builders. Similar convenience methods are present in their respective layout classes: >> >> *GridPaneBuilder* >> addColumn(int columnIndex, Node... children) >> addRow(int rowIndex, Node... children) >> add(Node child, int columnIndex, int rowIndex) >> add(Node child, int columnIndex, int rowIndex, int colspan, int rowspan) >> >> *RegionBuilder* >> maxSize(double width, double height) >> minSize(double width, double height) >> prefSize(double width, double height) >> These will be inherited by all layout builders. >> >> A also propose to add following convenience methods which don't have direct counterpart in layout classes (the constraints can be specified only by static methods there) >> Adding these would enable us to add child with constraint to layout without having to hold a reference to it. e.g >> Hbox h = HBoxBuilder.create().add(CircleBuilder.create...build(), margin).build(); >> instead of >> Circle circle = CircleBuilder.create...build(); >> Hbox h = HBoxBuilder.create().children(circle).build(); >> Hbox.setMargin (circle, margin); >> >> The proposed methods are: >> *AnchorPaneBuilder* >> add(Node child, Double topAnchor, Double rightAnchor, Double bottomAnchor, Double leftAnchor) >> >> *BorderPaneBuilder* >> add(Node child, Pos alignment) >> add(Node child, Insets margin) >> add(Node child, Pos alignment, Insets margin) >> >> *FlowPaneBuilder* >> add(Node child, Insets margin) >> >> *GridPaneBuilder* >> add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment) >> add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment, Priority hgrow, Priority vgrow) >> add(Node child, int columnIndex, int rowIndex, int columnspan, int rowspan, HPos halignment, VPos valignment, Priority hgrow, Priority vgrow, Insets margin) >> >> *HBoxBuilder* >> add(Node child, Priority hgrow) >> add(Node child, Insets margin) >> add(Node child, Priority hgrow, Insets margin) >> >> *StackPaneBuilder* >> add(Node child, Pos alignment) >> add(Node child, Insets margin) >> add(Node child, Pos alignment, Insets margin) >> >> *TilePaneBuilder* >> add(Node child, Pos alignment) >> add(Node child, Insets margin) >> add(Node child, Pos alignment, Insets margin) >> >> *VBoxBuilder* >> add(Node child, Priority vgrow) >> add(Node child, Insets margin) >> add(Node child, Priority vgrow, Insets margin) >> >> Thanks, >> Eva > From pavel.safrata at oracle.com Wed Nov 21 00:47:29 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 21 Nov 2012 09:47:29 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AC9255.4080304@jugs.org> References: <4FFEDD3B.6030109@oracle.com> <50AC8E7E.20203@oracle.com> <50AC9255.4080304@jugs.org> Message-ID: <50AC9521.3070406@oracle.com> On 21.11.2012 9:35, Dr. Michael Paus wrote: > Am 21.11.2012 09:19, schrieb Pavel Safrata: >> On 20.11.2012 15:41, Richard Bair wrote: >>>> *GridPaneBuilder* >>>> addColumn(int columnIndex, Node... children) >>>> addRow(int rowIndex, Node... children) >>>> add(Node child, int columnIndex, int rowIndex) >>>> add(Node child, int columnIndex, int rowIndex, int colspan, int >>>> rowspan) >>> Do we use columnIndex, rowIndex elsewhere? Usually I've seen "row, >>> col", but "x, y", so it could go either way, but we should be >>> consistent with elsewhere in the platform. >>> >>> >> >> In transforms we address matrix elements by "row, column". >> >> Pavel > It is probably too late to be really consistent. For example in > GridPane you have > > add(Node child, int columnIndex, int rowIndex) > > whereas for the transforms you have "row, column" as Pavel has pointed > out. This is embarrassing. The transforms have not been released yet (the matrix features were added to 8.0), so we probably still can change the order. But users specifically requested this order as the usual one. Pavel > > The only thing you can and should do is to make at least the builders > consistent with the > class they build. > > Michael > From richard.bair at oracle.com Wed Nov 21 01:28:11 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 21 Nov 2012 10:28:11 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AC9521.3070406@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50AC8E7E.20203@oracle.com> <50AC9255.4080304@jugs.org> <50AC9521.3070406@oracle.com> Message-ID: <61EE9007-7FD3-4E46-AF01-EBADAD6B8520@oracle.com> >> It is probably too late to be really consistent. For example in GridPane you have >> >> add(Node child, int columnIndex, int rowIndex) >> >> whereas for the transforms you have "row, column" as Pavel has pointed out. > > This is embarrassing. The transforms have not been released yet (the matrix features were added to 8.0), so we probably still can change the order. But users specifically requested this order as the usual one. Personally I have always liked "row, col" because that is the normal mathematical notation. Jasper liked "col, row" because that translates into "x, y", and when thinking in 2-D space that is most natural. From hang.vo at oracle.com Wed Nov 21 01:33:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 21 Nov 2012 09:33:51 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26391: optimized local-to-scene transform property. Message-ID: <20121121093353.6F46A47AB2@hg.openjdk.java.net> Changeset: cacf5b967ed3 Author: Pavel Safrata Date: 2012-11-21 10:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cacf5b967ed3 RT-26391: optimized local-to-scene transform property. ! javafx-ui-common/src/com/sun/javafx/scene/transform/TransformUtils.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/transform/Transform.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/transform/TransformUtilsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/TransformHelper.java ! javafx-ui-common/test/unit/javafx/scene/Node_LocalToParentTransform_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_LocalToSceneTransform_Test.java ! javafx-ui-common/test/unit/javafx/scene/transform/AffineOperationsTest.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformOperationsTest.java From mp at jugs.org Wed Nov 21 01:36:57 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 21 Nov 2012 10:36:57 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AC9521.3070406@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50AC8E7E.20203@oracle.com> <50AC9255.4080304@jugs.org> <50AC9521.3070406@oracle.com> Message-ID: <50ACA0B9.8070504@jugs.org> I would not want to change the transforms either. When you deal with matrices you simply expect something like M[row][column] where the row comes first and then the column and it would be very confusing if methods which deal with matrices would use a different ordering of the parameters. Why we have to use a reversed order when we deal with a GridPane for example is beyond me but this is probably unchangeable now, so we will have to live with that schism. Just make the builders consistent with their classes. Michael Am 21.11.2012 09:47, schrieb Pavel Safrata: > > On 21.11.2012 9:35, Dr. Michael Paus wrote: >> Am 21.11.2012 09:19, schrieb Pavel Safrata: >>> On 20.11.2012 15:41, Richard Bair wrote: >>>>> *GridPaneBuilder* >>>>> addColumn(int columnIndex, Node... children) >>>>> addRow(int rowIndex, Node... children) >>>>> add(Node child, int columnIndex, int rowIndex) >>>>> add(Node child, int columnIndex, int rowIndex, int colspan, int >>>>> rowspan) >>>> Do we use columnIndex, rowIndex elsewhere? Usually I've seen "row, >>>> col", but "x, y", so it could go either way, but we should be >>>> consistent with elsewhere in the platform. >>>> >>>> >>> >>> In transforms we address matrix elements by "row, column". >>> >>> Pavel >> It is probably too late to be really consistent. For example in >> GridPane you have >> >> add(Node child, int columnIndex, int rowIndex) >> >> whereas for the transforms you have "row, column" as Pavel has >> pointed out. > > This is embarrassing. The transforms have not been released yet (the > matrix features were added to 8.0), so we probably still can change > the order. But users specifically requested this order as the usual one. > > Pavel > >> >> The only thing you can and should do is to make at least the builders >> consistent with the >> class they build. >> >> Michael >> > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From eva.krejcirova at oracle.com Wed Nov 21 02:03:21 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 21 Nov 2012 11:03:21 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> Message-ID: <50ACA6E9.7010300@oracle.com> On 20.11.2012 15:41, Richard Bair wrote: >> *GridPaneBuilder* >> addColumn(int columnIndex, Node... children) >> addRow(int rowIndex, Node... children) >> add(Node child, int columnIndex, int rowIndex) >> add(Node child, int columnIndex, int rowIndex, int colspan, int rowspan) > Do we use columnIndex, rowIndex elsewhere? Usually I've seen "row, col", but "x, y", so it could go either way, but we should be consistent with elsewhere in the platform. I took the names and order of the arguments from the corresponding methods in GridPane, so that its builder is consistent with it. Having the order different in GrindPane and GridPaneBuilder would be extremely confusing, I think. >> *RegionBuilder* >> maxSize(double width, double height) >> minSize(double width, double height) >> prefSize(double width, double height) >> These will be inherited by all layout builders. >> >> A also propose to add following convenience methods which don't have direct counterpart in layout classes (the constraints can be specified only by static methods there) >> Adding these would enable us to add child with constraint to layout without having to hold a reference to it. e.g >> Hbox h = HBoxBuilder.create().add(CircleBuilder.create...build(), margin).build(); >> instead of >> Circle circle = CircleBuilder.create...build(); >> Hbox h = HBoxBuilder.create().children(circle).build(); >> Hbox.setMargin (circle, margin); >> >> The proposed methods are: >> *AnchorPaneBuilder* >> add(Node child, Double topAnchor, Double rightAnchor, Double bottomAnchor, Double leftAnchor) > Can these be primitive doubles instead? AnchorPane uses Doubles, so I used them in Builder too, but I can surely change them to primitives. Eva From hang.vo at oracle.com Wed Nov 21 06:34:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 21 Nov 2012 14:34:00 +0000 Subject: hg: openjfx/8/controls/rt: [TEST-ONLY] ignore failing test to get build back on track Message-ID: <20121121143404.EC2B447AB9@hg.openjdk.java.net> Changeset: 686b52a44cc4 Author: David Grieve Date: 2012-11-21 09:22 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/686b52a44cc4 [TEST-ONLY] ignore failing test to get build back on track ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java From tom.schindl at bestsolution.at Wed Nov 21 08:46:22 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 21 Nov 2012 17:46:22 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> Message-ID: <50AD055E.9080301@bestsolution.at> Am 21.11.12 09:46, schrieb Richard Bair: > I wanted constraint classes from the start. There was a problem there, which I don't accurately remember now, but I do want to see some discussion around deprecating (or at least no longer depending on) the static methods and having some constraint classes again. They've probably been harder to implement in FXML? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Wed Nov 21 08:48:42 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 21 Nov 2012 16:48:42 +0000 Subject: hg: openjfx/8/controls/rt: 7 new changesets Message-ID: <20121121164853.3209747ABF@hg.openjdk.java.net> Changeset: 6948b1cc29c5 Author: Felipe Heidrich Date: 2012-11-14 10:54 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6948b1cc29c5 [ECLISPE_ONLY] removing old classpath & project files - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project Changeset: 5c36a4a20edb Author: Martin Sladecek Date: 2012-11-19 09:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5c36a4a20edb RT-26296 Ensemble: Pause Transition hangs ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 0c13364d5766 Author: Lubomir Nerad Date: 2012-11-20 14:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0c13364d5766 Fix for RT-25977: added missing KeyCombination.ModifierValue javadoc ! javafx-ui-common/src/javafx/scene/input/KeyCombination.java Changeset: 591592a4ae64 Author: Lubomir Nerad Date: 2012-11-20 16:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/591592a4ae64 Fix for RT-26241: made Screen class more robust ! javafx-ui-common/src/javafx/stage/Screen.java + javafx-ui-common/test/unit/javafx/stage/ScreenTest.java Changeset: 37c2ab46c51d Author: Eva Krejcirova Date: 2012-11-20 17:52 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/37c2ab46c51d RT-25618: ArcTo needs javadoc ! javafx-ui-common/src/javafx/scene/shape/ArcTo.java + javafx-ui-common/src/javafx/scene/shape/doc-files/arcto-flags.png + javafx-ui-common/src/javafx/scene/shape/doc-files/arcto.png Changeset: f4ac2f436738 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-20 10:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f4ac2f436738 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project Changeset: ececf104ffcc Author: David Grieve Date: 2012-11-21 11:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ececf104ffcc branch merge - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project From eva.krejcirova at oracle.com Wed Nov 21 09:21:10 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 21 Nov 2012 18:21:10 +0100 Subject: Extending builders: PathBuilder In-Reply-To: <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> References: <4FFDAD1C.2010501@oracle.com> <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> Message-ID: <50AD0D86.3060807@oracle.com> On 20.11.2012 15:46, Richard Bair wrote: >> There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g. >> >> PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); >> or >> PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); >> >> There are several approaches for this : >> >> 1.) appending everything into one list so both of former examples return the same path. > This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed? > I didn't find any such usage in our code, but that doesn't mean that nobody does that... What do others think? From lubomir.nerad at oracle.com Wed Nov 21 09:52:19 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 21 Nov 2012 18:52:19 +0100 Subject: Extending builders: PathBuilder In-Reply-To: <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> References: <4FFDAD1C.2010501@oracle.com> <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> Message-ID: <50AD14D3.8090208@oracle.com> On 11/20/2012 3:46 PM, Richard Bair wrote: >> There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g. >> >> PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); >> or >> PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); >> >> There are several approaches for this : >> >> 1.) appending everything into one list so both of former examples return the same path. > This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed? What if somebody uses a single Group builder instance which is configured with common attributes and then used for building multiple Group-s each of them having different set of children. In that case I would expect children replacing and not adding to the existing list. > Richard Lubo From tbee at tbee.org Wed Nov 21 10:02:12 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 21 Nov 2012 19:02:12 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AD055E.9080301@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> Message-ID: <50AD1724.3090305@tbee.org> I suspect the constraints were already "out" before FXML, but this would be a fairly acceptable notation: | | Or: | | On 2012-11-21 17:46, Tom Schindl wrote: > Am 21.11.12 09:46, schrieb Richard Bair: >> I wanted constraint classes from the start. There was a problem there, which I don't accurately remember now, but I do want to see some discussion around deprecating (or at least no longer depending on) the static methods and having some constraint classes again. > They've probably been harder to implement in FXML? > > Tom > > From jasper.potts at oracle.com Wed Nov 21 12:17:54 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Wed, 21 Nov 2012 12:17:54 -0800 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS Message-ID: <6665F02E-826A-4782-B037-B06842862823@oracle.com> Hi all, When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like .my-button { -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; } The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. public abstract class Control{ ?... /** * Create a new instance of the default skin for this control. This is called to create a skin for the control if * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. * * @return new instance of default skin for this control. If null then the control will have no skin unless one * is provided by css. */ protected Skin createDefaultSkin() ?. ?. } The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. Thanks Jasper From hang.vo at oracle.com Wed Nov 21 12:18:25 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 21 Nov 2012 20:18:25 +0000 Subject: hg: openjfx/8/controls/rt: Fix RT-25325: Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS Message-ID: <20121121201827.CF2D047AC9@hg.openjdk.java.net> Changeset: acd1cfc745ee Author: "Jasper Potts" Date: 2012-11-21 12:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/acd1cfc745ee Fix RT-25325: Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.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/skin/AccordionSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/DoubleField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/InputField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Button.java ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java ! javafx-ui-controls/src/javafx/scene/control/ChoiceBox.java ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PasswordField.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitMenuButton.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableRow.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java From jonathan.giles at oracle.com Wed Nov 21 12:25:08 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 22 Nov 2012 09:25:08 +1300 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <6665F02E-826A-4782-B037-B06842862823@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> Message-ID: <50AD38A4.8010808@oracle.com> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). -- Jonathan On 22/11/2012 9:17 a.m., Jasper Potts wrote: > Hi all, > > When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like > > .my-button { > -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; > } > > The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. > > public abstract class Control{ > ?... > /** > * Create a new instance of the default skin for this control. This is called to create a skin for the control if > * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. > * > * @return new instance of default skin for this control. If null then the control will have no skin unless one > * is provided by css. > */ > protected Skin createDefaultSkin() ?. > ?. > } > > The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. > > All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. > > Thanks > > Jasper From steve.x.northover at oracle.com Wed Nov 21 12:43:28 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 21 Nov 2012 15:43:28 -0500 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <50AD38A4.8010808@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> Message-ID: <50AD3CF0.8000702@oracle.com> So the idea is not to use CSS at all and to reset the default skin? Could we support "default" as a value for -fx-skin instead? Can you give a simple example of how createDefaultSkin() would be used? Steve On 21/11/2012 3:25 PM, Jonathan Giles wrote: > Jasper and I have been speaking about this recently, so from my point > of view as tech lead inside the UI controls team I believe this is a > good move - it speeds up instantiation time (less use of the costly > reflection) and it allows for easier styling, both of which Jasper has > outlined below. These are both good wins. > > The other big perk is that we can release more samples code without > referring to private API (that is, the skins we use to style our > controls). > > -- Jonathan > > On 22/11/2012 9:17 a.m., Jasper Potts wrote: >> Hi all, >> >> When building applications we often want to remove and replace all >> the default styling from a control but still use the default skin. To >> do this so far you had to respecify the default skin in your css file >> with something like >> >> .my-button { >> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >> } >> >> The problem with this is the skins are in a com.sun package so not >> public API and may change in the future. So what I propose doing is >> adding new protected method to Control class so that sub-classes can >> create instances of their default skin. >> >> public abstract class Control{ >> ?... >> /** >> * Create a new instance of the default skin for this control. >> This is called to create a skin for the control if >> * no skin is provided via CSS {@code -fx-skin} or set >> explicitly in a sub-class with {@code setSkin(...)}. >> * >> * @return new instance of default skin for this control. If >> null then the control will have no skin unless one >> * is provided by css. >> */ >> protected Skin createDefaultSkin() ?. >> ?. >> } >> >> The reason for returning a instance rather than class name string is >> it speeds up start up to not have to do the reflection to lookup and >> instantiate the class from classname. It would have been nice if this >> could have been a abstract method but that would have not been >> backwards compatible. >> >> All existing code will work as it does not but any css specifying the >> default skin can now be removed when running on 8. >> >> Thanks >> >> Jasper > From david.grieve at oracle.com Wed Nov 21 13:01:33 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 21 Nov 2012 16:01:33 -0500 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <50AD3CF0.8000702@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> Message-ID: <35BC4C3D-C685-42AB-A679-379431656B43@oracle.com> -fx-skin still works. If there isn't a -fx-skin setting, then the skin from createDefaultSkin is used. On Nov 21, 2012, at 3:43 PM, steve.x.northover at oracle.com wrote: > So the idea is not to use CSS at all and to reset the default skin? > Could we support "default" as a value for -fx-skin instead? > Can you give a simple example of how createDefaultSkin() would be used? > > Steve > > On 21/11/2012 3:25 PM, Jonathan Giles wrote: >> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >> >> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >> >> -- Jonathan >> >> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>> Hi all, >>> >>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>> >>> .my-button { >>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>> } >>> >>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>> >>> public abstract class Control{ >>> ?... >>> /** >>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>> * >>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>> * is provided by css. >>> */ >>> protected Skin createDefaultSkin() ?. >>> ?. >>> } >>> >>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>> >>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>> >>> Thanks >>> >>> Jasper >> From jasper.potts at oracle.com Wed Nov 21 13:05:07 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Wed, 21 Nov 2012 13:05:07 -0800 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <50AD3CF0.8000702@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> Message-ID: The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. Here is a example for Pagination control. public class Pagination extends Control { ... @Override protected Skin createDefaultSkin() { return new PaginationSkin(this); } ? } Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. Jasper On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: > So the idea is not to use CSS at all and to reset the default skin? > Could we support "default" as a value for -fx-skin instead? > Can you give a simple example of how createDefaultSkin() would be used? > > Steve > > On 21/11/2012 3:25 PM, Jonathan Giles wrote: >> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >> >> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >> >> -- Jonathan >> >> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>> Hi all, >>> >>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>> >>> .my-button { >>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>> } >>> >>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>> >>> public abstract class Control{ >>> ?... >>> /** >>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>> * >>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>> * is provided by css. >>> */ >>> protected Skin createDefaultSkin() ?. >>> ?. >>> } >>> >>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>> >>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>> >>> Thanks >>> >>> Jasper >> From jasper.potts at oracle.com Wed Nov 21 13:09:03 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Wed, 21 Nov 2012 13:09:03 -0800 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet Message-ID: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> Hi All, I would like to add API to Application to add the ability to set the default user agent stylesheet. So far JavaFX has had a default stylesheet of capsian.css hard coded for all applications. In 8 if we have time I would like to have a new stylesheet that you can use as alternative to caspian.css. This would also open the platform to easy use of 3rd party look and feels. public abstract class Application { ?. /** * Set the default user agent stylesheet. This is used to provide default * styling for all ui controls and other nodes. Each release of JavaFX may * have a new default value for this so if you need to guarantee consistency * you will need to call this method and choose what default you would like * for your application. * * @param url The URL to the stylesheet as a String. */ public static void setDefaultUserAgentStylesheet(String url) ?. ?.. } This has been a much requested feature for a long time: http://javafx-jira.kenai.com/browse/RT-8054 http://javafx-jira.kenai.com/browse/RT-5753 http://javafx-jira.kenai.com/browse/RT-19713 There have been some workarounds for specific use cases and a proposed solution for a Theme class but none have solved the root problem of being able to change the default user agent stylesheet. Thanks Jasper From jonathan.giles at oracle.com Wed Nov 21 13:29:22 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 22 Nov 2012 10:29:22 +1300 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> Message-ID: <50AD47B2.6030103@oracle.com> I think the comment in Jaspers code is very important to pull out and highlight, as what he says in the javadoc comment is exactly what I want. In short, my personal preference is to push for JavaFX to upgrade to new user agent stylesheets _by default_. I mentioned this issue in RT-19713, but I'm keen to discuss this more widely. The benefit of this approach is that it would prevent the issue we had in Swing where the default look remained as Metal forever - which didn't really help Swing take the world by storm. Many months ago Jasper started investigating a new CSS style and I was helping to give feedback. The reason I mention this is that immediately the new style made the current Caspian style look dated and heavy, in my opinion (which is pretty impressive as Caspian doesn't look bad by any means). I would upgrade my personal applications to the new look in a heartbeat, and I would love to have all JavaFX applications upgrade to this as well - rather than be stuck on Caspian. Of course, just because we update by default doesn't mean that this is what people necessarily want for their software - they want to be certain we don't break their apps when the styles change. To allow for this, developers would have to explicitly state (using the API Jasper has outlined below) what style they want to use. In other words, I would like us to switch from opt-in to opt-out (of new styles), and I'd be very keen to hear feedback on this in conjunction with the feedback Jasper is seeking. -- Jonathan On 22/11/2012 10:09 a.m., Jasper Potts wrote: > Hi All, > > I would like to add API to Application to add the ability to set the default user agent stylesheet. So far JavaFX has had a default stylesheet of capsian.css hard coded for all applications. In 8 if we have time I would like to have a new stylesheet that you can use as alternative to caspian.css. This would also open the platform to easy use of 3rd party look and feels. > > public abstract class Application { > ?. > /** > * Set the default user agent stylesheet. This is used to provide default > * styling for all ui controls and other nodes. Each release of JavaFX may > * have a new default value for this so if you need to guarantee consistency > * you will need to call this method and choose what default you would like > * for your application. > * > * @param url The URL to the stylesheet as a String. > */ > public static void setDefaultUserAgentStylesheet(String url) ?. > ?.. > } > > This has been a much requested feature for a long time: > http://javafx-jira.kenai.com/browse/RT-8054 > http://javafx-jira.kenai.com/browse/RT-5753 > http://javafx-jira.kenai.com/browse/RT-19713 > > There have been some workarounds for specific use cases and a proposed solution for a Theme class but none have solved the root problem of being able to change the default user agent stylesheet. > > Thanks > > Jasper From steve.x.northover at oracle.com Wed Nov 21 13:31:04 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 21 Nov 2012 16:31:04 -0500 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> Message-ID: <50AD4818.8000005@oracle.com> Ok, I should have read the JavaDoc more closely. Am I correct in saying that this will create a hard reference between control classes and their skins (when there isn't one right now?). I am not a fan of reflection but it seems weird that I can't ask what the default skin will be (as a String) so that I can use that to set CSS for a control using code? The method createDefaultSkin() is normally called exactly once when a skin is needed for the control. Why not initDefaultSkin() (or a better name) that takes no arguments and set the default skin for the control? Does it make sense to query the skin in a subclass, then set it somewhere else or call this method then not call setSkin() with the result? Steve On 21/11/2012 4:05 PM, Jasper Potts wrote: > The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. > > Here is a example for Pagination control. > > public class Pagination extends Control { > ... > @Override protected Skin createDefaultSkin() { > return new PaginationSkin(this); > } > ? > } > > Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. > > I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. > > Jasper > > On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: > >> So the idea is not to use CSS at all and to reset the default skin? >> Could we support "default" as a value for -fx-skin instead? >> Can you give a simple example of how createDefaultSkin() would be used? >> >> Steve >> >> On 21/11/2012 3:25 PM, Jonathan Giles wrote: >>> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >>> >>> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >>> >>> -- Jonathan >>> >>> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>>> Hi all, >>>> >>>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>>> >>>> .my-button { >>>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>>> } >>>> >>>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>>> >>>> public abstract class Control{ >>>> ?... >>>> /** >>>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>>> * >>>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>>> * is provided by css. >>>> */ >>>> protected Skin createDefaultSkin() ?. >>>> ?. >>>> } >>>> >>>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>>> >>>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>>> >>>> Thanks >>>> >>>> Jasper From jonathan.giles at oracle.com Wed Nov 21 13:37:15 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 22 Nov 2012 10:37:15 +1300 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> Message-ID: <50AD498B.9080202@oracle.com> On 22/11/2012 10:09 a.m., Jasper Potts wrote: > http://javafx-jira.kenai.com/browse/RT-19713 > > There have been some workarounds for specific use cases and a proposed solution for a Theme class but none have solved the root problem of being able to change the default user agent stylesheet. I should also note that the patch proposed in RT-19713 did tackle the root problem of changing the default user agent stylesheet. It was just deemed too heavyweight to bring in the concept of themes for the limited use cases where it would be used, and therefore failed to gain the required support. The currently proposed approach was what I originally intended before going down the themes route, so I'm happy either way (especially if we can move to the opt-out automatic upgrade model I mentioned in my last email). -- Jonathan From james.weaver at oracle.com Wed Nov 21 13:38:20 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Wed, 21 Nov 2012 16:38:20 -0500 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> Message-ID: <50AD49CC.4000902@oracle.com> I am very much in favor of this idea. Thanks, Jim Weaver On 11/21/12 4:05 PM, Jasper Potts wrote: > The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. > > Here is a example for Pagination control. > > public class Pagination extends Control { > ... > @Override protected Skin createDefaultSkin() { > return new PaginationSkin(this); > } > ? > } > > Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. > > I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. > > Jasper > > On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: > >> So the idea is not to use CSS at all and to reset the default skin? >> Could we support "default" as a value for -fx-skin instead? >> Can you give a simple example of how createDefaultSkin() would be used? >> >> Steve >> >> On 21/11/2012 3:25 PM, Jonathan Giles wrote: >>> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >>> >>> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >>> >>> -- Jonathan >>> >>> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>>> Hi all, >>>> >>>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>>> >>>> .my-button { >>>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>>> } >>>> >>>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>>> >>>> public abstract class Control{ >>>> ?... >>>> /** >>>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>>> * >>>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>>> * is provided by css. >>>> */ >>>> protected Skin createDefaultSkin() ?. >>>> ?. >>>> } >>>> >>>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>>> >>>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>>> >>>> Thanks >>>> >>>> Jasper -- Regards, Jim Weaver Java Evangelist Oracle Corporation james.weaver at oracle.com From james.weaver at oracle.com Wed Nov 21 13:38:56 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Wed, 21 Nov 2012 16:38:56 -0500 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> Message-ID: <50AD49F0.4050301@oracle.com> +1. Thanks, Jim Weaver On 11/21/12 4:09 PM, Jasper Potts wrote: > Hi All, > > I would like to add API to Application to add the ability to set the default user agent stylesheet. So far JavaFX has had a default stylesheet of capsian.css hard coded for all applications. In 8 if we have time I would like to have a new stylesheet that you can use as alternative to caspian.css. This would also open the platform to easy use of 3rd party look and feels. > > public abstract class Application { > ?. > /** > * Set the default user agent stylesheet. This is used to provide default > * styling for all ui controls and other nodes. Each release of JavaFX may > * have a new default value for this so if you need to guarantee consistency > * you will need to call this method and choose what default you would like > * for your application. > * > * @param url The URL to the stylesheet as a String. > */ > public static void setDefaultUserAgentStylesheet(String url) ?. > ?.. > } > > This has been a much requested feature for a long time: > http://javafx-jira.kenai.com/browse/RT-8054 > http://javafx-jira.kenai.com/browse/RT-5753 > http://javafx-jira.kenai.com/browse/RT-19713 > > There have been some workarounds for specific use cases and a proposed solution for a Theme class but none have solved the root problem of being able to change the default user agent stylesheet. > > Thanks > > Jasper -- Regards, Jim Weaver Java Evangelist Oracle Corporation james.weaver at oracle.com From jasper.potts at oracle.com Wed Nov 21 13:41:13 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Wed, 21 Nov 2012 13:41:13 -0800 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <50AD4818.8000005@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> <50AD4818.8000005@oracle.com> Message-ID: <815587D8-E3EB-4DBA-9F7A-038F3DEA7D74@oracle.com> Answers inline: On Nov 21, 2012, at 1:31 PM, steve.x.northover at oracle.com wrote: > Ok, I should have read the JavaDoc more closely. Am I correct in saying that this will create a hard reference between control classes and their skins (when there isn't one right now?). I am not a fan of reflection but it seems weird that I can't ask what the default skin will be (as a String) so that I can use that to set CSS for a control using code? Not sure we want people to be able to query it as it may change and would not want people copy and pasting the value into their css files. This would have same issues as today. > > The method createDefaultSkin() is normally called exactly once when a skin is needed for the control. Why not initDefaultSkin() (or a better name) that takes no arguments and set the default skin for the control? Does it make sense to query the skin in a subclass, then set it somewhere else or call this method then not call setSkin() with the result? It might be possible to do this but not 100% sure as using private access to Control to set the skin to value from create method without CSS thinking it is a user set property that would not be overridable. Jasper > > Steve > > On 21/11/2012 4:05 PM, Jasper Potts wrote: >> The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. >> >> Here is a example for Pagination control. >> >> public class Pagination extends Control { >> ... >> @Override protected Skin createDefaultSkin() { >> return new PaginationSkin(this); >> } >> ? >> } >> >> Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. >> >> I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. >> >> Jasper >> >> On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: >> >>> So the idea is not to use CSS at all and to reset the default skin? >>> Could we support "default" as a value for -fx-skin instead? >>> Can you give a simple example of how createDefaultSkin() would be used? >>> >>> Steve >>> >>> On 21/11/2012 3:25 PM, Jonathan Giles wrote: >>>> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >>>> >>>> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >>>> >>>> -- Jonathan >>>> >>>> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>>>> Hi all, >>>>> >>>>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>>>> >>>>> .my-button { >>>>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>>>> } >>>>> >>>>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>>>> >>>>> public abstract class Control{ >>>>> ?... >>>>> /** >>>>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>>>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>>>> * >>>>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>>>> * is provided by css. >>>>> */ >>>>> protected Skin createDefaultSkin() ?. >>>>> ?. >>>>> } >>>>> >>>>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>>>> >>>>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>>>> >>>>> Thanks >>>>> >>>>> Jasper From tom.schindl at bestsolution.at Wed Nov 21 13:42:47 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 21 Nov 2012 22:42:47 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AD1724.3090305@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> Message-ID: <50AD4AD7.5030301@bestsolution.at> the nice thing about the current expression with static calls is that the semantics for adding children are always the same whether your target is a Layout-Container or e.g. a Group. You always call add on the target your specified. Your way of layout containers expects two different things to happen: * for layout container you want to call add on the owner because you want to pass the constraint object * you can add on the list itself for stuff like Group but also Tables Not to forget how would you like set the constraint when you not add to a list e.g. when using a borderpane? Tom Am 21.11.12 19:02, schrieb Tom Eugelink: > I suspect the constraints were already "out" before FXML, but this would > be a fairly acceptable notation: > > | > > | > > > Or: > > | > > | > > > > On 2012-11-21 17:46, Tom Schindl wrote: >> Am 21.11.12 09:46, schrieb Richard Bair: >>> I wanted constraint classes from the start. There was a problem >>> there, which I don't accurately remember now, but I do want to see >>> some discussion around deprecating (or at least no longer depending >>> on) the static methods and having some constraint classes again. >> They've probably been harder to implement in FXML? >> >> 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 james.weaver at oracle.com Wed Nov 21 13:47:43 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Wed, 21 Nov 2012 16:47:43 -0500 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: <50AD47B2.6030103@oracle.com> References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> <50AD47B2.6030103@oracle.com> Message-ID: <50AD4BFF.9080201@oracle.com> Jonathan, Jasper, et al, I like this approach for the reason that the latest and greatest style is applied by default, unless the developer/organization has a preference for a particular (e.g. Caspian, or custom) stylesheet. Thanks, Jim Weaver On 11/21/12 4:29 PM, Jonathan Giles wrote: > I think the comment in Jaspers code is very important to pull out and > highlight, as what he says in the javadoc comment is exactly what I > want. In short, my personal preference is to push for JavaFX to > upgrade to new user agent stylesheets _by default_. I mentioned this > issue in RT-19713, but I'm keen to discuss this more widely. > > The benefit of this approach is that it would prevent the issue we had > in Swing where the default look remained as Metal forever - which > didn't really help Swing take the world by storm. Many months ago > Jasper started investigating a new CSS style and I was helping to give > feedback. The reason I mention this is that immediately the new style > made the current Caspian style look dated and heavy, in my opinion > (which is pretty impressive as Caspian doesn't look bad by any means). > I would upgrade my personal applications to the new look in a > heartbeat, and I would love to have all JavaFX applications upgrade to > this as well - rather than be stuck on Caspian. > > Of course, just because we update by default doesn't mean that this is > what people necessarily want for their software - they want to be > certain we don't break their apps when the styles change. To allow for > this, developers would have to explicitly state (using the API Jasper > has outlined below) what style they want to use. > > In other words, I would like us to switch from opt-in to opt-out (of > new styles), and I'd be very keen to hear feedback on this in > conjunction with the feedback Jasper is seeking. > > -- Jonathan > > On 22/11/2012 10:09 a.m., Jasper Potts wrote: >> Hi All, >> >> I would like to add API to Application to add the ability to set the >> default user agent stylesheet. So far JavaFX has had a default >> stylesheet of capsian.css hard coded for all applications. In 8 if we >> have time I would like to have a new stylesheet that you can use as >> alternative to caspian.css. This would also open the platform to easy >> use of 3rd party look and feels. >> >> public abstract class Application { >> ?. >> /** >> * Set the default user agent stylesheet. This is used to >> provide default >> * styling for all ui controls and other nodes. Each release of >> JavaFX may >> * have a new default value for this so if you need to guarantee >> consistency >> * you will need to call this method and choose what default you >> would like >> * for your application. >> * >> * @param url The URL to the stylesheet as a String. >> */ >> public static void setDefaultUserAgentStylesheet(String url) ?. >> ?.. >> } >> >> This has been a much requested feature for a long time: >> http://javafx-jira.kenai.com/browse/RT-8054 >> http://javafx-jira.kenai.com/browse/RT-5753 >> http://javafx-jira.kenai.com/browse/RT-19713 >> >> There have been some workarounds for specific use cases and a >> proposed solution for a Theme class but none have solved the root >> problem of being able to change the default user agent stylesheet. >> >> Thanks >> >> Jasper > -- Regards, Jim Weaver Java Evangelist Oracle Corporation james.weaver at oracle.com From zonski at gmail.com Wed Nov 21 14:04:13 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 22 Nov 2012 09:04:13 +1100 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> <50AD49F0.4050301@oracle.com> Message-ID: reply-all got me again... On Thu, Nov 22, 2012 at 8:58 AM, Daniel Zwolenski wrote: > +1 to the idea. > > I'm wondering if it's worth having some sort of System property (or > something similar if System properties are bad form) that could set the > default stylesheet as well if none has been explicitly set by the > developer. That way if I forgot to specifically link my app to a default > style sheet and then 12 months later a new release of Java causes me > problems I could at least set the style via a system property rather than > having to get back into my old code, change it, recompile, redeploy, etc. > Applets and JNLP are the prime problem children for the auto-updating > issues so anything that could be set in the HTML or JNLP to change the > style would do the job in my opinion. > > Also more just thinking out loud, but some build tool support for this > might be interesting. e.g. the native installers, and/or jnlp files could > bundle in a default style per OS or something (and Maven could just use > convention to look for the existence of say a default-win32-style.css vs a > -osx, etc). > > > > > On Thu, Nov 22, 2012 at 8:38 AM, Jim Weaver wrote: > >> +1. >> >> Thanks, >> Jim Weaver >> >> >> On 11/21/12 4:09 PM, Jasper Potts wrote: >> >>> Hi All, >>> >>> I would like to add API to Application to add the ability to set the >>> default user agent stylesheet. So far JavaFX has had a default stylesheet >>> of capsian.css hard coded for all applications. In 8 if we have time I >>> would like to have a new stylesheet that you can use as alternative to >>> caspian.css. This would also open the platform to easy use of 3rd party >>> look and feels. >>> >>> public abstract class Application { >>> ?. >>> /** >>> * Set the default user agent stylesheet. This is used to provide >>> default >>> * styling for all ui controls and other nodes. Each release of >>> JavaFX may >>> * have a new default value for this so if you need to guarantee >>> consistency >>> * you will need to call this method and choose what default you >>> would like >>> * for your application. >>> * >>> * @param url The URL to the stylesheet as a String. >>> */ >>> public static void setDefaultUserAgentStylesheet(**String url) ?. >>> ?.. >>> } >>> >>> This has been a much requested feature for a long time: >>> http://javafx-jira.kenai.com/**browse/RT-8054 >>> http://javafx-jira.kenai.com/**browse/RT-5753 >>> http://javafx-jira.kenai.com/**browse/RT-19713 >>> >>> There have been some workarounds for specific use cases and a proposed >>> solution for a Theme class but none have solved the root problem of being >>> able to change the default user agent stylesheet. >>> >>> Thanks >>> >>> Jasper >>> >> >> >> -- >> Regards, >> Jim Weaver >> Java Evangelist >> Oracle Corporation >> james.weaver at oracle.com >> >> > From jasper.potts at oracle.com Wed Nov 21 14:13:42 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Wed, 21 Nov 2012 14:13:42 -0800 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> <50AD49F0.4050301@oracle.com> Message-ID: <3D608AF3-663E-4855-86CA-30FC0634A3C5@oracle.com> Daniel I agree that a system property for this would be nice and think we should add one before switching the default (I have filed a issue http://javafx-jira.kenai.com/browse/RT-26435 to track). At the moment I want to make a start with a API to switch so that I can have a application for development and testing of the new look and feel that replaces caspian with its own look. At the moment there is no proper way of doing that. Jasper On Nov 21, 2012, at 2:04 PM, Daniel Zwolenski wrote: > reply-all got me again... > > > On Thu, Nov 22, 2012 at 8:58 AM, Daniel Zwolenski wrote: > >> +1 to the idea. >> >> I'm wondering if it's worth having some sort of System property (or >> something similar if System properties are bad form) that could set the >> default stylesheet as well if none has been explicitly set by the >> developer. That way if I forgot to specifically link my app to a default >> style sheet and then 12 months later a new release of Java causes me >> problems I could at least set the style via a system property rather than >> having to get back into my old code, change it, recompile, redeploy, etc. >> Applets and JNLP are the prime problem children for the auto-updating >> issues so anything that could be set in the HTML or JNLP to change the >> style would do the job in my opinion. >> >> Also more just thinking out loud, but some build tool support for this >> might be interesting. e.g. the native installers, and/or jnlp files could >> bundle in a default style per OS or something (and Maven could just use >> convention to look for the existence of say a default-win32-style.css vs a >> -osx, etc). >> >> >> >> >> On Thu, Nov 22, 2012 at 8:38 AM, Jim Weaver wrote: >> >>> +1. >>> >>> Thanks, >>> Jim Weaver >>> >>> >>> On 11/21/12 4:09 PM, Jasper Potts wrote: >>> >>>> Hi All, >>>> >>>> I would like to add API to Application to add the ability to set the >>>> default user agent stylesheet. So far JavaFX has had a default stylesheet >>>> of capsian.css hard coded for all applications. In 8 if we have time I >>>> would like to have a new stylesheet that you can use as alternative to >>>> caspian.css. This would also open the platform to easy use of 3rd party >>>> look and feels. >>>> >>>> public abstract class Application { >>>> ?. >>>> /** >>>> * Set the default user agent stylesheet. This is used to provide >>>> default >>>> * styling for all ui controls and other nodes. Each release of >>>> JavaFX may >>>> * have a new default value for this so if you need to guarantee >>>> consistency >>>> * you will need to call this method and choose what default you >>>> would like >>>> * for your application. >>>> * >>>> * @param url The URL to the stylesheet as a String. >>>> */ >>>> public static void setDefaultUserAgentStylesheet(**String url) ?. >>>> ?.. >>>> } >>>> >>>> This has been a much requested feature for a long time: >>>> http://javafx-jira.kenai.com/**browse/RT-8054 >>>> http://javafx-jira.kenai.com/**browse/RT-5753 >>>> http://javafx-jira.kenai.com/**browse/RT-19713 >>>> >>>> There have been some workarounds for specific use cases and a proposed >>>> solution for a Theme class but none have solved the root problem of being >>>> able to change the default user agent stylesheet. >>>> >>>> Thanks >>>> >>>> Jasper >>>> >>> >>> >>> -- >>> Regards, >>> Jim Weaver >>> Java Evangelist >>> Oracle Corporation >>> james.weaver at oracle.com >>> >>> >> From steve.x.northover at oracle.com Wed Nov 21 14:29:50 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 21 Nov 2012 17:29:50 -0500 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <815587D8-E3EB-4DBA-9F7A-038F3DEA7D74@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> <50AD4818.8000005@oracle.com> <815587D8-E3EB-4DBA-9F7A-038F3DEA7D74@oracle.com> Message-ID: <50AD55DE.7030308@oracle.com> Answers inline: On 21/11/2012 4:41 PM, Jasper Potts wrote: > Answers inline: > On Nov 21, 2012, at 1:31 PM, steve.x.northover at oracle.com wrote: > >> Ok, I should have read the JavaDoc more closely. Am I correct in saying that this will create a hard reference between control classes and their skins (when there isn't one right now?). I am not a fan of reflection but it seems weird that I can't ask what the default skin will be (as a String) so that I can use that to set CSS for a control using code? > Not sure we want people to be able to query it as it may change and would not want people copy and pasting the value into their css files. This would have same issues as today. I suppose that people could run a program, query the string, print it out and use it. Would you even set -fx-skin in code? I am wondering whether the hard reference to the skin is a problem. I will ask Daniel what he thinks. >> The method createDefaultSkin() is normally called exactly once when a skin is needed for the control. Why not initDefaultSkin() (or a better name) that takes no arguments and set the default skin for the control? Does it make sense to query the skin in a subclass, then set it somewhere else or call this method then not call setSkin() with the result? > It might be possible to do this but not 100% sure as using private access to Control to set the skin to value from create method without CSS thinking it is a user set property that would not be overridable. My point here is that this is a method that gets called once when a skin is initialized and I was going to just add an init() sort of method rather than one that returned a value that could only be used under restricted circumstances. That's all. > > Jasper > > >> Steve >> >> On 21/11/2012 4:05 PM, Jasper Potts wrote: >>> The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. >>> >>> Here is a example for Pagination control. >>> >>> public class Pagination extends Control { >>> ... >>> @Override protected Skin createDefaultSkin() { >>> return new PaginationSkin(this); >>> } >>> ? >>> } >>> >>> Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. >>> >>> I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. >>> >>> Jasper >>> >>> On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: >>> >>>> So the idea is not to use CSS at all and to reset the default skin? >>>> Could we support "default" as a value for -fx-skin instead? >>>> Can you give a simple example of how createDefaultSkin() would be used? >>>> >>>> Steve >>>> >>>> On 21/11/2012 3:25 PM, Jonathan Giles wrote: >>>>> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >>>>> >>>>> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >>>>> >>>>> -- Jonathan >>>>> >>>>> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>>>>> Hi all, >>>>>> >>>>>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>>>>> >>>>>> .my-button { >>>>>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>>>>> } >>>>>> >>>>>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>>>>> >>>>>> public abstract class Control{ >>>>>> ?... >>>>>> /** >>>>>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>>>>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>>>>> * >>>>>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>>>>> * is provided by css. >>>>>> */ >>>>>> protected Skin createDefaultSkin() ?. >>>>>> ?. >>>>>> } >>>>>> >>>>>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>>>>> >>>>>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jasper From jasper.potts at oracle.com Wed Nov 21 14:39:37 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Wed, 21 Nov 2012 14:39:37 -0800 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <50AD55DE.7030308@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> <50AD4818.8000005@oracle.com> <815587D8-E3EB-4DBA-9F7A-038F3DEA7D74@oracle.com> <50AD55DE.7030308@oracle.com> Message-ID: On Nov 21, 2012, at 2:29 PM, steve.x.northover at oracle.com wrote: > Answers inline: > > On 21/11/2012 4:41 PM, Jasper Potts wrote: >> Answers inline: >> On Nov 21, 2012, at 1:31 PM, steve.x.northover at oracle.com wrote: >> >>> Ok, I should have read the JavaDoc more closely. Am I correct in saying that this will create a hard reference between control classes and their skins (when there isn't one right now?). I am not a fan of reflection but it seems weird that I can't ask what the default skin will be (as a String) so that I can use that to set CSS for a control using code? >> Not sure we want people to be able to query it as it may change and would not want people copy and pasting the value into their css files. This would have same issues as today. > I suppose that people could run a program, query the string, print it out and use it. Would you even set -fx-skin in code? > I am wondering whether the hard reference to the skin is a problem. I will ask Daniel what he thinks. I assume you want to ask Daniel because of embedded. At the moment embedded uses all the same skins as desktop. If they want to use different in the future they can still override defaults in the embedded.css stylesheet. >>> The method createDefaultSkin() is normally called exactly once when a skin is needed for the control. Why not initDefaultSkin() (or a better name) that takes no arguments and set the default skin for the control? Does it make sense to query the skin in a subclass, then set it somewhere else or call this method then not call setSkin() with the result? >> It might be possible to do this but not 100% sure as using private access to Control to set the skin to value from create method without CSS thinking it is a user set property that would not be overridable. > My point here is that this is a method that gets called once when a skin is initialized and I was going to just add an init() sort of method rather than one that returned a value that could only be used under restricted circumstances. That's all. If the css is set back to "-fx-skin: null" at some point then this method will be called a second time to create a new skin. Jasper > >> >> Jasper >> >> >>> Steve >>> >>> On 21/11/2012 4:05 PM, Jasper Potts wrote: >>>> The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. >>>> >>>> Here is a example for Pagination control. >>>> >>>> public class Pagination extends Control { >>>> ... >>>> @Override protected Skin createDefaultSkin() { >>>> return new PaginationSkin(this); >>>> } >>>> ? >>>> } >>>> >>>> Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. >>>> >>>> I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. >>>> >>>> Jasper >>>> >>>> On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: >>>> >>>>> So the idea is not to use CSS at all and to reset the default skin? >>>>> Could we support "default" as a value for -fx-skin instead? >>>>> Can you give a simple example of how createDefaultSkin() would be used? >>>>> >>>>> Steve >>>>> >>>>> On 21/11/2012 3:25 PM, Jonathan Giles wrote: >>>>>> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >>>>>> >>>>>> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >>>>>> >>>>>> -- Jonathan >>>>>> >>>>>> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>>>>>> >>>>>>> .my-button { >>>>>>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>>>>>> } >>>>>>> >>>>>>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>>>>>> >>>>>>> public abstract class Control{ >>>>>>> ?... >>>>>>> /** >>>>>>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>>>>>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>>>>>> * >>>>>>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>>>>>> * is provided by css. >>>>>>> */ >>>>>>> protected Skin createDefaultSkin() ?. >>>>>>> ?. >>>>>>> } >>>>>>> >>>>>>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>>>>>> >>>>>>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jasper From randahl at rockit.dk Wed Nov 21 15:02:50 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 22 Nov 2012 00:02:50 +0100 Subject: The single core nature of JavaFX and complex UI construction Message-ID: For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. Thanks Randahl From zonski at gmail.com Thu Nov 22 04:19:46 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 22 Nov 2012 23:19:46 +1100 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <50AD38A4.8010808@oracle.com> <50AD3CF0.8000702@oracle.com> <50AD4818.8000005@oracle.com> <815587D8-E3EB-4DBA-9F7A-038F3DEA7D74@oracle.com> <50AD55DE.7030308@oracle.com> Message-ID: I'm not overly fussed on the reflection vs not debate but I am curious if the reflection is actually that much slower. I did some digging on reflection performance a while back and found stats that reckoned it was on par in most cases, only worse in a few situations and rarely by much, and ever so occasionally reflection was actually more performant. I ran some of my own tests on things and found in most cases the difference was negligible. Just curious if the aversion to reflection was based on metrics or general sentiment? On 22/11/2012, at 9:39 AM, Jasper Potts wrote: > > On Nov 21, 2012, at 2:29 PM, steve.x.northover at oracle.com wrote: > >> Answers inline: >> >> On 21/11/2012 4:41 PM, Jasper Potts wrote: >>> Answers inline: >>> On Nov 21, 2012, at 1:31 PM, steve.x.northover at oracle.com wrote: >>> >>>> Ok, I should have read the JavaDoc more closely. Am I correct in saying that this will create a hard reference between control classes and their skins (when there isn't one right now?). I am not a fan of reflection but it seems weird that I can't ask what the default skin will be (as a String) so that I can use that to set CSS for a control using code? >>> Not sure we want people to be able to query it as it may change and would not want people copy and pasting the value into their css files. This would have same issues as today. >> I suppose that people could run a program, query the string, print it out and use it. Would you even set -fx-skin in code? >> I am wondering whether the hard reference to the skin is a problem. I will ask Daniel what he thinks. > I assume you want to ask Daniel because of embedded. At the moment embedded uses all the same skins as desktop. If they want to use different in the future they can still override defaults in the embedded.css stylesheet. > >>>> The method createDefaultSkin() is normally called exactly once when a skin is needed for the control. Why not initDefaultSkin() (or a better name) that takes no arguments and set the default skin for the control? Does it make sense to query the skin in a subclass, then set it somewhere else or call this method then not call setSkin() with the result? >>> It might be possible to do this but not 100% sure as using private access to Control to set the skin to value from create method without CSS thinking it is a user set property that would not be overridable. >> My point here is that this is a method that gets called once when a skin is initialized and I was going to just add an init() sort of method rather than one that returned a value that could only be used under restricted circumstances. That's all. > If the css is set back to "-fx-skin: null" at some point then this method will be called a second time to create a new skin. > > Jasper > >> >>> >>> Jasper >>> >>> >>>> Steve >>>> >>>> On 21/11/2012 4:05 PM, Jasper Potts wrote: >>>>> The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been. >>>>> >>>>> Here is a example for Pagination control. >>>>> >>>>> public class Pagination extends Control { >>>>> ... >>>>> @Override protected Skin createDefaultSkin() { >>>>> return new PaginationSkin(this); >>>>> } >>>>> ? >>>>> } >>>>> >>>>> Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass. >>>>> >>>>> I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing. >>>>> >>>>> Jasper >>>>> >>>>> On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote: >>>>> >>>>>> So the idea is not to use CSS at all and to reset the default skin? >>>>>> Could we support "default" as a value for -fx-skin instead? >>>>>> Can you give a simple example of how createDefaultSkin() would be used? >>>>>> >>>>>> Steve >>>>>> >>>>>> On 21/11/2012 3:25 PM, Jonathan Giles wrote: >>>>>>> Jasper and I have been speaking about this recently, so from my point of view as tech lead inside the UI controls team I believe this is a good move - it speeds up instantiation time (less use of the costly reflection) and it allows for easier styling, both of which Jasper has outlined below. These are both good wins. >>>>>>> >>>>>>> The other big perk is that we can release more samples code without referring to private API (that is, the skins we use to style our controls). >>>>>>> >>>>>>> -- Jonathan >>>>>>> >>>>>>> On 22/11/2012 9:17 a.m., Jasper Potts wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >>>>>>>> >>>>>>>> .my-button { >>>>>>>> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >>>>>>>> } >>>>>>>> >>>>>>>> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >>>>>>>> >>>>>>>> public abstract class Control{ >>>>>>>> ?... >>>>>>>> /** >>>>>>>> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >>>>>>>> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >>>>>>>> * >>>>>>>> * @return new instance of default skin for this control. If null then the control will have no skin unless one >>>>>>>> * is provided by css. >>>>>>>> */ >>>>>>>> protected Skin createDefaultSkin() ?. >>>>>>>> ?. >>>>>>>> } >>>>>>>> >>>>>>>> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >>>>>>>> >>>>>>>> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Jasper > From richard.bair at oracle.com Thu Nov 22 05:18:40 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 22 Nov 2012 14:18:40 +0100 Subject: Extending builders: PathBuilder In-Reply-To: <50AD14D3.8090208@oracle.com> References: <4FFDAD1C.2010501@oracle.com> <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> <50AD14D3.8090208@oracle.com> Message-ID: <8F343DDF-FEE8-4BE5-BA8A-1561F3C167E9@oracle.com> >>> There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g. >>> >>> PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); >>> or >>> PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); >>> >>> There are several approaches for this : >>> >>> 1.) appending everything into one list so both of former examples return the same path. >> This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed? > > What if somebody uses a single Group builder instance which is configured with common attributes and then used for building multiple Group-s each of them having different set of children. In that case I would expect children replacing and not adding to the existing list. Good argument. From richard.bair at oracle.com Thu Nov 22 05:33:11 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 22 Nov 2012 14:33:11 +0100 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <6665F02E-826A-4782-B037-B06842862823@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> Message-ID: <2B0D9C05-98EE-440D-8432-FEE49905F673@oracle.com> I like this idea. Is the createDefaultSkin method called from the constructor, or only during the CSS application phase? Richard On Nov 21, 2012, at 9:17 PM, Jasper Potts wrote: > Hi all, > > When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like > > .my-button { > -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; > } > > The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. > > public abstract class Control{ > ?... > /** > * Create a new instance of the default skin for this control. This is called to create a skin for the control if > * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. > * > * @return new instance of default skin for this control. If null then the control will have no skin unless one > * is provided by css. > */ > protected Skin createDefaultSkin() ?. > ?. > } > > The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. > > All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. > > Thanks > > Jasper From lubomir.nerad at oracle.com Thu Nov 22 06:17:15 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Thu, 22 Nov 2012 15:17:15 +0100 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: References: Message-ID: <50AE33EB.20805@oracle.com> Hi Randahl, On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: > For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. > > Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. > > Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. > I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. > > Thanks > > Randahl Thanks, Lubo From eva.krejcirova at oracle.com Thu Nov 22 06:40:10 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Thu, 22 Nov 2012 15:40:10 +0100 Subject: Extending builders In-Reply-To: <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> Message-ID: <50AE394A.4060703@oracle.com> Hi, There is one more thing which needs to be sorted out before adding new methods to builders: SceneBuilder and FXML use builders to find names of properties of a class, so they need to have a way to differentiate between the new convenience methods and the methods which correspond to properties of a class. Daniel, is this still true? Last time we discussed this, Daniel suggested to annotate these new convenience methods. If we go this way, we need to create a new runtime annotation (and find a name for it :-) ) Eva From daniel.fuchs at oracle.com Thu Nov 22 07:01:47 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 22 Nov 2012 16:01:47 +0100 Subject: Extending builders In-Reply-To: <50AE394A.4060703@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> <50AE394A.4060703@oracle.com> Message-ID: <50AE3E5B.6010400@oracle.com> On 11/22/12 3:40 PM, Eva Krejcirova wrote: > Hi, > > There is one more thing which needs to be sorted out before adding new > methods to builders: > SceneBuilder and FXML use builders to find names of properties of a > class, so they need to have a way to differentiate between the new > convenience methods and the methods which correspond to properties of a > class. Daniel, is this still true? > > Last time we discussed this, Daniel suggested to annotate these new > convenience methods. If we go this way, we need to create a new runtime > annotation (and find a name for it :-) ) > > Eva Hi Eva, Yes this is still true. Note that SceneBuilder actually uses builders only in special cases - for WebView - for instance - because of the fake location attribute available on WebViewBuilder only - and for any type which has no public constructors (e.g.: all charts, Insets, etc...) However - SceneBuilder discovers whether there are constructor properties by introspecting ClassX and ClassXBuilder and comparing the results: it takes the name of all the single parameter instance methods in ClassXBuilder which returns a builder, remove the names of all writable (getter+setter) properties found in ClassX, and what remain are assumed to be constructor properties. As long as the convenience methods have more than 1 parameter (varargs count for 1) then this logic should remain valid. The FXMLLoader's JavaFXBuilderFactory also introspects builders in order to find out writable properties and type of properties, so that's another place you will have to look at (class JavaFXBuilderFactory.JavaFXBuilder). best regards, -- daniel From jasper.potts at oracle.com Thu Nov 22 07:08:58 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Thu, 22 Nov 2012 07:08:58 -0800 Subject: [REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS In-Reply-To: <2B0D9C05-98EE-440D-8432-FEE49905F673@oracle.com> References: <6665F02E-826A-4782-B037-B06842862823@oracle.com> <2B0D9C05-98EE-440D-8432-FEE49905F673@oracle.com> Message-ID: <0676BFAB-CC58-4CCA-8576-3C37B5C1E3C7@oracle.com> Only during CSS application so that we can give CSS a chance first at setting the skin. Jasper Sent from my iPhone On Nov 22, 2012, at 5:33 AM, Richard Bair wrote: > I like this idea. Is the createDefaultSkin method called from the constructor, or only during the CSS application phase? > > Richard > > On Nov 21, 2012, at 9:17 PM, Jasper Potts wrote: > >> Hi all, >> >> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like >> >> .my-button { >> -fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin"; >> } >> >> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin. >> >> public abstract class Control{ >> ?... >> /** >> * Create a new instance of the default skin for this control. This is called to create a skin for the control if >> * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code setSkin(...)}. >> * >> * @return new instance of default skin for this control. If null then the control will have no skin unless one >> * is provided by css. >> */ >> protected Skin createDefaultSkin() ?. >> ?. >> } >> >> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible. >> >> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8. >> >> Thanks >> >> Jasper > From chris.s at thoughtslinger.com Thu Nov 22 09:43:33 2012 From: chris.s at thoughtslinger.com (Chris Sonnenberg) Date: Thu, 22 Nov 2012 10:43:33 -0700 Subject: Passing iscc.exe command line options during native bundling Message-ID: Just wondering if there is a way to pass command line parameters to iscc.exe when it is used as part of the bundling process? Specifically, I?d like to be able to pass the sign tool parameters so that my installers are signed. It?s one of those cases where the signing tool has to be specified outside of the installer script itself. I?m running with 7u9. Thanks Chris Sonnenberg From tbee at tbee.org Thu Nov 22 10:48:06 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 22 Nov 2012 19:48:06 +0100 Subject: [REVIEW REQUEST] RT-19713 Add API to JavaFX to allow for setting preferred user agent stylesheet In-Reply-To: <50AD47B2.6030103@oracle.com> References: <88AD6F62-90AA-48F4-B535-AAFD690672DF@oracle.com> <50AD47B2.6030103@oracle.com> Message-ID: <50AE7366.1040304@tbee.org> Equally as important, now that we're discussing new styles, is that it should be easy for 3rd party controls to adopt to the new styling. There has to be some notion of "apply the focus styling", "apply the highlight styling" in the CSS. Tom On 2012-11-21 22:29, Jonathan Giles wrote: > I think the comment in Jaspers code is very important to pull out and highlight, as what he says in the javadoc comment is exactly what I want. In short, my personal preference is to push for JavaFX to upgrade to new user agent stylesheets _by default_. I mentioned this issue in RT-19713, but I'm keen to discuss this more widely. > > The benefit of this approach is that it would prevent the issue we had in Swing where the default look remained as Metal forever - which didn't really help Swing take the world by storm. Many months ago Jasper started investigating a new CSS style and I was helping to give feedback. The reason I mention this is that immediately the new style made the current Caspian style look dated and heavy, in my opinion (which is pretty impressive as Caspian doesn't look bad by any means). I would upgrade my personal applications to the new look in a heartbeat, and I would love to have all JavaFX applications upgrade to this as well - rather than be stuck on Caspian. > > Of course, just because we update by default doesn't mean that this is what people necessarily want for their software - they want to be certain we don't break their apps when the styles change. To allow for this, developers would have to explicitly state (using the API Jasper has outlined below) what style they want to use. > > In other words, I would like us to switch from opt-in to opt-out (of new styles), and I'd be very keen to hear feedback on this in conjunction with the feedback Jasper is seeking. > > -- Jonathan > > On 22/11/2012 10:09 a.m., Jasper Potts wrote: >> Hi All, >> >> I would like to add API to Application to add the ability to set the default user agent stylesheet. So far JavaFX has had a default stylesheet of capsian.css hard coded for all applications. In 8 if we have time I would like to have a new stylesheet that you can use as alternative to caspian.css. This would also open the platform to easy use of 3rd party look and feels. >> >> public abstract class Application { >> ?. >> /** >> * Set the default user agent stylesheet. This is used to provide default >> * styling for all ui controls and other nodes. Each release of JavaFX may >> * have a new default value for this so if you need to guarantee consistency >> * you will need to call this method and choose what default you would like >> * for your application. >> * >> * @param url The URL to the stylesheet as a String. >> */ >> public static void setDefaultUserAgentStylesheet(String url) ?. >> ?.. >> } >> >> This has been a much requested feature for a long time: >> http://javafx-jira.kenai.com/browse/RT-8054 >> http://javafx-jira.kenai.com/browse/RT-5753 >> http://javafx-jira.kenai.com/browse/RT-19713 >> >> There have been some workarounds for specific use cases and a proposed solution for a Theme class but none have solved the root problem of being able to change the default user agent stylesheet. >> >> Thanks >> >> Jasper > From tbee at tbee.org Thu Nov 22 10:51:33 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 22 Nov 2012 19:51:33 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AD4AD7.5030301@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> Message-ID: <50AE7435.8020503@tbee.org> Not sure I understand what you are trying to say here. Each layout has different and much deviating constraints, so they cannot be unified into one model. I think I summarized it well in my blogpost: "All information about the layout of a single node should be stored in one place." This means absolute layout can suffice with the X,Y,W,H information available in the nodes (and thus allow binding), but all more advanced layouts require a separate constraint class. Tom On 2012-11-21 22:42, Tom Schindl wrote: > the nice thing about the current expression with static calls is that > the semantics for adding children are always the same whether your > target is a Layout-Container or e.g. a Group. > > You always call add on the target your specified. Your way of layout > containers expects two different things to happen: > * for layout container you want to call add on the owner because you > want to pass the constraint object > * you can add on the list itself for stuff like Group but also Tables > > Not to forget how would you like set the constraint when you not add to > a list e.g. when using a borderpane? > > Tom > > Am 21.11.12 19:02, schrieb Tom Eugelink: >> I suspect the constraints were already "out" before FXML, but this would >> be a fairly acceptable notation: >> >> | >> >> | >> >> >> Or: >> >> | >> >> | >> >> >> >> On 2012-11-21 17:46, Tom Schindl wrote: >>> Am 21.11.12 09:46, schrieb Richard Bair: >>>> I wanted constraint classes from the start. There was a problem >>>> there, which I don't accurately remember now, but I do want to see >>>> some discussion around deprecating (or at least no longer depending >>>> on) the static methods and having some constraint classes again. >>> They've probably been harder to implement in FXML? >>> >>> Tom >>> >>> > From randahl at rockit.dk Thu Nov 22 12:20:39 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 22 Nov 2012 21:20:39 +0100 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: <50AE33EB.20805@oracle.com> References: <50AE33EB.20805@oracle.com> Message-ID: Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. Awesome! Randahl On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: > Hi Randahl, > > On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >> >> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >> >> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. > > JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. > >> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >> >> Thanks >> >> Randahl > > Thanks, > Lubo From randahl at rockit.dk Thu Nov 22 13:04:15 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 22 Nov 2012 22:04:15 +0100 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: References: <50AE33EB.20805@oracle.com> Message-ID: <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> Oh-no? it fails periodically, so I have filed a new Jira http://javafx-jira.kenai.com/browse/RT-26482. java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-2-thread-3 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:237) at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:397) at javafx.scene.Scene.(Scene.java:287) at javafx.scene.Scene.(Scene.java:195) at javafx.stage.PopupWindow.(PopupWindow.java:109) at javafx.scene.control.PopupControl.(PopupControl.java:99) at javafx.scene.control.ContextMenu.(ContextMenu.java:129) at com.sun.javafx.scene.control.behavior.TextFieldBehavior.(TextFieldBehavior.java:104) at com.sun.javafx.scene.control.skin.TextFieldSkin.(TextFieldSkin.java:152) at com.intuism.ui.form.text.ITextFieldSkin.(ITextFieldSkin.java:17) at com.intuism.ui.form.text.ITextField.(ITextField.java:59) at com.intuism.ui.form.text.ITextField.(ITextField.java:52) at com.intuism.ui.form.text.ITextField.(ITextField.java:49) at com.wefend.pc.timeline.views.LoginEventView.(LoginEventView.java:59) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at java.lang.Class.newInstance0(Class.java:372) at java.lang.Class.newInstance(Class.java:325) at com.intuism.ui.component.showcase.TypeMappingViewFactory.createView(TypeMappingViewFactory.java:38) at com.intuism.ui.component.showcase.Slot.createView(Slot.java:42) at com.intuism.ui.component.showcase.Slot.(Slot.java:35) at com.intuism.ui.component.showcase.Showcase$8$1.call(Showcase.java:253) at javafx.concurrent.Task$TaskCallable.call(Task.java:1259) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) On Nov 22, 2012, at 21:20 , Randahl Fink Isaksen wrote: > Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. > > Awesome! > > Randahl > > > > On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: > >> Hi Randahl, >> >> On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >>> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >>> >>> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >>> >>> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. >> >> JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. >> >>> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >>> >>> Thanks >>> >>> Randahl >> >> Thanks, >> Lubo > From jonathan.giles at oracle.com Thu Nov 22 13:15:46 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 23 Nov 2012 10:15:46 +1300 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> References: <50AE33EB.20805@oracle.com> <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> Message-ID: <50AE9602.6000002@oracle.com> This is a duplicate of a number of other issues, such as: http://javafx-jira.kenai.com/browse/RT-25127 http://javafx-jira.kenai.com/browse/RT-17716 http://javafx-jira.kenai.com/browse/RT-17855 http://javafx-jira.kenai.com/browse/RT-15288 -- Jonathan On 23/11/2012 10:04 a.m., Randahl Fink Isaksen wrote: > Oh-no? it fails periodically, so I have filed a new Jira http://javafx-jira.kenai.com/browse/RT-26482. > > java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-2-thread-3 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:237) > at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:397) > at javafx.scene.Scene.(Scene.java:287) > at javafx.scene.Scene.(Scene.java:195) > at javafx.stage.PopupWindow.(PopupWindow.java:109) > at javafx.scene.control.PopupControl.(PopupControl.java:99) > at javafx.scene.control.ContextMenu.(ContextMenu.java:129) > at com.sun.javafx.scene.control.behavior.TextFieldBehavior.(TextFieldBehavior.java:104) > at com.sun.javafx.scene.control.skin.TextFieldSkin.(TextFieldSkin.java:152) > at com.intuism.ui.form.text.ITextFieldSkin.(ITextFieldSkin.java:17) > at com.intuism.ui.form.text.ITextField.(ITextField.java:59) > at com.intuism.ui.form.text.ITextField.(ITextField.java:52) > at com.intuism.ui.form.text.ITextField.(ITextField.java:49) > at com.wefend.pc.timeline.views.LoginEventView.(LoginEventView.java:59) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at java.lang.Class.newInstance0(Class.java:372) > at java.lang.Class.newInstance(Class.java:325) > at com.intuism.ui.component.showcase.TypeMappingViewFactory.createView(TypeMappingViewFactory.java:38) > at com.intuism.ui.component.showcase.Slot.createView(Slot.java:42) > at com.intuism.ui.component.showcase.Slot.(Slot.java:35) > at com.intuism.ui.component.showcase.Showcase$8$1.call(Showcase.java:253) > at javafx.concurrent.Task$TaskCallable.call(Task.java:1259) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > > > > On Nov 22, 2012, at 21:20 , Randahl Fink Isaksen wrote: > >> Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. >> >> Awesome! >> >> Randahl >> >> >> >> On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: >> >>> Hi Randahl, >>> >>> On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >>>> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >>>> >>>> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >>>> >>>> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. >>> JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. >>> >>>> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >>>> >>>> Thanks >>>> >>>> Randahl >>> Thanks, >>> Lubo From randahl at rockit.dk Thu Nov 22 14:27:23 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 22 Nov 2012 23:27:23 +0100 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: <50AE9602.6000002@oracle.com> References: <50AE33EB.20805@oracle.com> <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> <50AE9602.6000002@oracle.com> Message-ID: <793B9EBC-E940-40C6-95A5-EFB66A089983@rockit.dk> Thanks Jonathan. I will see if I can figure out a work around and then post it to the top issue. Randahl On Nov 22, 2012, at 22:15 , Jonathan Giles wrote: > This is a duplicate of a number of other issues, such as: > > http://javafx-jira.kenai.com/browse/RT-25127 > http://javafx-jira.kenai.com/browse/RT-17716 > http://javafx-jira.kenai.com/browse/RT-17855 > http://javafx-jira.kenai.com/browse/RT-15288 > > -- Jonathan > > On 23/11/2012 10:04 a.m., Randahl Fink Isaksen wrote: >> Oh-no? it fails periodically, so I have filed a new Jira http://javafx-jira.kenai.com/browse/RT-26482. >> >> java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-2-thread-3 >> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:237) >> at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:397) >> at javafx.scene.Scene.(Scene.java:287) >> at javafx.scene.Scene.(Scene.java:195) >> at javafx.stage.PopupWindow.(PopupWindow.java:109) >> at javafx.scene.control.PopupControl.(PopupControl.java:99) >> at javafx.scene.control.ContextMenu.(ContextMenu.java:129) >> at com.sun.javafx.scene.control.behavior.TextFieldBehavior.(TextFieldBehavior.java:104) >> at com.sun.javafx.scene.control.skin.TextFieldSkin.(TextFieldSkin.java:152) >> at com.intuism.ui.form.text.ITextFieldSkin.(ITextFieldSkin.java:17) >> at com.intuism.ui.form.text.ITextField.(ITextField.java:59) >> at com.intuism.ui.form.text.ITextField.(ITextField.java:52) >> at com.intuism.ui.form.text.ITextField.(ITextField.java:49) >> at com.wefend.pc.timeline.views.LoginEventView.(LoginEventView.java:59) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) >> at java.lang.Class.newInstance0(Class.java:372) >> at java.lang.Class.newInstance(Class.java:325) >> at com.intuism.ui.component.showcase.TypeMappingViewFactory.createView(TypeMappingViewFactory.java:38) >> at com.intuism.ui.component.showcase.Slot.createView(Slot.java:42) >> at com.intuism.ui.component.showcase.Slot.(Slot.java:35) >> at com.intuism.ui.component.showcase.Showcase$8$1.call(Showcase.java:253) >> at javafx.concurrent.Task$TaskCallable.call(Task.java:1259) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >> at java.lang.Thread.run(Thread.java:722) >> >> >> >> On Nov 22, 2012, at 21:20 , Randahl Fink Isaksen wrote: >> >>> Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. >>> >>> Awesome! >>> >>> Randahl >>> >>> >>> >>> On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: >>> >>>> Hi Randahl, >>>> >>>> On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >>>>> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >>>>> >>>>> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >>>>> >>>>> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. >>>> JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. >>>> >>>>> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >>>>> >>>>> Thanks >>>>> >>>>> Randahl >>>> Thanks, >>>> Lubo > From randahl at rockit.dk Thu Nov 22 15:08:54 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 23 Nov 2012 00:08:54 +0100 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: <50AE9602.6000002@oracle.com> References: <50AE33EB.20805@oracle.com> <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> <50AE9602.6000002@oracle.com> Message-ID: Nailed it. ? It turns out that you can work around this bug by creating a subclass of TextField which ensures that no skin is set if you are not on the JavaFX thread. Then, I added a listener to the scene property and added my skin once the skin is assigned, because at that point I am back on the JavaFX thread. Works like a charm Randahl On Nov 22, 2012, at 22:15 , Jonathan Giles wrote: > This is a duplicate of a number of other issues, such as: > > http://javafx-jira.kenai.com/browse/RT-25127 > http://javafx-jira.kenai.com/browse/RT-17716 > http://javafx-jira.kenai.com/browse/RT-17855 > http://javafx-jira.kenai.com/browse/RT-15288 > > -- Jonathan > > On 23/11/2012 10:04 a.m., Randahl Fink Isaksen wrote: >> Oh-no? it fails periodically, so I have filed a new Jira http://javafx-jira.kenai.com/browse/RT-26482. >> >> java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-2-thread-3 >> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:237) >> at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:397) >> at javafx.scene.Scene.(Scene.java:287) >> at javafx.scene.Scene.(Scene.java:195) >> at javafx.stage.PopupWindow.(PopupWindow.java:109) >> at javafx.scene.control.PopupControl.(PopupControl.java:99) >> at javafx.scene.control.ContextMenu.(ContextMenu.java:129) >> at com.sun.javafx.scene.control.behavior.TextFieldBehavior.(TextFieldBehavior.java:104) >> at com.sun.javafx.scene.control.skin.TextFieldSkin.(TextFieldSkin.java:152) >> at com.intuism.ui.form.text.ITextFieldSkin.(ITextFieldSkin.java:17) >> at com.intuism.ui.form.text.ITextField.(ITextField.java:59) >> at com.intuism.ui.form.text.ITextField.(ITextField.java:52) >> at com.intuism.ui.form.text.ITextField.(ITextField.java:49) >> at com.wefend.pc.timeline.views.LoginEventView.(LoginEventView.java:59) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) >> at java.lang.Class.newInstance0(Class.java:372) >> at java.lang.Class.newInstance(Class.java:325) >> at com.intuism.ui.component.showcase.TypeMappingViewFactory.createView(TypeMappingViewFactory.java:38) >> at com.intuism.ui.component.showcase.Slot.createView(Slot.java:42) >> at com.intuism.ui.component.showcase.Slot.(Slot.java:35) >> at com.intuism.ui.component.showcase.Showcase$8$1.call(Showcase.java:253) >> at javafx.concurrent.Task$TaskCallable.call(Task.java:1259) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >> at java.lang.Thread.run(Thread.java:722) >> >> >> >> On Nov 22, 2012, at 21:20 , Randahl Fink Isaksen wrote: >> >>> Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. >>> >>> Awesome! >>> >>> Randahl >>> >>> >>> >>> On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: >>> >>>> Hi Randahl, >>>> >>>> On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >>>>> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >>>>> >>>>> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >>>>> >>>>> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. >>>> JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. >>>> >>>>> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >>>>> >>>>> Thanks >>>>> >>>>> Randahl >>>> Thanks, >>>> Lubo > From steve.x.northover at oracle.com Thu Nov 22 15:14:19 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 22 Nov 2012 18:14:19 -0500 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: References: <50AE33EB.20805@oracle.com> <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> <50AE9602.6000002@oracle.com> Message-ID: <50AEB1CB.3060505@oracle.com> Thanks for adding the work around to the bug report. Steve On 22/11/2012 6:08 PM, Randahl Fink Isaksen wrote: > Nailed it. ? It turns out that you can work around this bug by creating a subclass of TextField which ensures that no skin is set if you are not on the JavaFX thread. Then, I added a listener to the scene property and added my skin once the skin is assigned, because at that point I am back on the JavaFX thread. > > Works like a charm > > Randahl > > On Nov 22, 2012, at 22:15 , Jonathan Giles wrote: > >> This is a duplicate of a number of other issues, such as: >> >> http://javafx-jira.kenai.com/browse/RT-25127 >> http://javafx-jira.kenai.com/browse/RT-17716 >> http://javafx-jira.kenai.com/browse/RT-17855 >> http://javafx-jira.kenai.com/browse/RT-15288 >> >> -- Jonathan >> >> On 23/11/2012 10:04 a.m., Randahl Fink Isaksen wrote: >>> Oh-no? it fails periodically, so I have filed a new Jira http://javafx-jira.kenai.com/browse/RT-26482. >>> >>> java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-2-thread-3 >>> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:237) >>> at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:397) >>> at javafx.scene.Scene.(Scene.java:287) >>> at javafx.scene.Scene.(Scene.java:195) >>> at javafx.stage.PopupWindow.(PopupWindow.java:109) >>> at javafx.scene.control.PopupControl.(PopupControl.java:99) >>> at javafx.scene.control.ContextMenu.(ContextMenu.java:129) >>> at com.sun.javafx.scene.control.behavior.TextFieldBehavior.(TextFieldBehavior.java:104) >>> at com.sun.javafx.scene.control.skin.TextFieldSkin.(TextFieldSkin.java:152) >>> at com.intuism.ui.form.text.ITextFieldSkin.(ITextFieldSkin.java:17) >>> at com.intuism.ui.form.text.ITextField.(ITextField.java:59) >>> at com.intuism.ui.form.text.ITextField.(ITextField.java:52) >>> at com.intuism.ui.form.text.ITextField.(ITextField.java:49) >>> at com.wefend.pc.timeline.views.LoginEventView.(LoginEventView.java:59) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) >>> at java.lang.Class.newInstance0(Class.java:372) >>> at java.lang.Class.newInstance(Class.java:325) >>> at com.intuism.ui.component.showcase.TypeMappingViewFactory.createView(TypeMappingViewFactory.java:38) >>> at com.intuism.ui.component.showcase.Slot.createView(Slot.java:42) >>> at com.intuism.ui.component.showcase.Slot.(Slot.java:35) >>> at com.intuism.ui.component.showcase.Showcase$8$1.call(Showcase.java:253) >>> at javafx.concurrent.Task$TaskCallable.call(Task.java:1259) >>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>> at java.lang.Thread.run(Thread.java:722) >>> >>> >>> >>> On Nov 22, 2012, at 21:20 , Randahl Fink Isaksen wrote: >>> >>>> Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. >>>> >>>> Awesome! >>>> >>>> Randahl >>>> >>>> >>>> >>>> On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: >>>> >>>>> Hi Randahl, >>>>> >>>>> On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >>>>>> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >>>>>> >>>>>> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >>>>>> >>>>>> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. >>>>> JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. >>>>> >>>>>> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Randahl >>>>> Thanks, >>>>> Lubo From randahl at rockit.dk Thu Nov 22 15:16:25 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 23 Nov 2012 00:16:25 +0100 Subject: The single core nature of JavaFX and complex UI construction In-Reply-To: <50AEB1CB.3060505@oracle.com> References: <50AE33EB.20805@oracle.com> <4B99B817-9A0A-4FA1-93AB-0043CF30DE0B@rockit.dk> <50AE9602.6000002@oracle.com> <50AEB1CB.3060505@oracle.com> Message-ID: You are welcome. On Nov 23, 2012, at 0:14 , steve.x.northover at oracle.com wrote: > Thanks for adding the work around to the bug report. > > Steve > > On 22/11/2012 6:08 PM, Randahl Fink Isaksen wrote: >> Nailed it. ? It turns out that you can work around this bug by creating a subclass of TextField which ensures that no skin is set if you are not on the JavaFX thread. Then, I added a listener to the scene property and added my skin once the skin is assigned, because at that point I am back on the JavaFX thread. >> >> Works like a charm >> >> Randahl >> >> On Nov 22, 2012, at 22:15 , Jonathan Giles wrote: >> >>> This is a duplicate of a number of other issues, such as: >>> >>> http://javafx-jira.kenai.com/browse/RT-25127 >>> http://javafx-jira.kenai.com/browse/RT-17716 >>> http://javafx-jira.kenai.com/browse/RT-17855 >>> http://javafx-jira.kenai.com/browse/RT-15288 >>> >>> -- Jonathan >>> >>> On 23/11/2012 10:04 a.m., Randahl Fink Isaksen wrote: >>>> Oh-no? it fails periodically, so I have filed a new Jira http://javafx-jira.kenai.com/browse/RT-26482. >>>> >>>> java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-2-thread-3 >>>> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:237) >>>> at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:397) >>>> at javafx.scene.Scene.(Scene.java:287) >>>> at javafx.scene.Scene.(Scene.java:195) >>>> at javafx.stage.PopupWindow.(PopupWindow.java:109) >>>> at javafx.scene.control.PopupControl.(PopupControl.java:99) >>>> at javafx.scene.control.ContextMenu.(ContextMenu.java:129) >>>> at com.sun.javafx.scene.control.behavior.TextFieldBehavior.(TextFieldBehavior.java:104) >>>> at com.sun.javafx.scene.control.skin.TextFieldSkin.(TextFieldSkin.java:152) >>>> at com.intuism.ui.form.text.ITextFieldSkin.(ITextFieldSkin.java:17) >>>> at com.intuism.ui.form.text.ITextField.(ITextField.java:59) >>>> at com.intuism.ui.form.text.ITextField.(ITextField.java:52) >>>> at com.intuism.ui.form.text.ITextField.(ITextField.java:49) >>>> at com.wefend.pc.timeline.views.LoginEventView.(LoginEventView.java:59) >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) >>>> at java.lang.Class.newInstance0(Class.java:372) >>>> at java.lang.Class.newInstance(Class.java:325) >>>> at com.intuism.ui.component.showcase.TypeMappingViewFactory.createView(TypeMappingViewFactory.java:38) >>>> at com.intuism.ui.component.showcase.Slot.createView(Slot.java:42) >>>> at com.intuism.ui.component.showcase.Slot.(Slot.java:35) >>>> at com.intuism.ui.component.showcase.Showcase$8$1.call(Showcase.java:253) >>>> at javafx.concurrent.Task$TaskCallable.call(Task.java:1259) >>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>> at java.lang.Thread.run(Thread.java:722) >>>> >>>> >>>> >>>> On Nov 22, 2012, at 21:20 , Randahl Fink Isaksen wrote: >>>> >>>>> Thanks you Lubomir! Thank you very much indeed. You are absolutely right, and following your comments, I took a long hard look at the code, and I am now able to reduce the UI construction time significantly by taking advantage of multi-core construction. >>>>> >>>>> Awesome! >>>>> >>>>> Randahl >>>>> >>>>> >>>>> >>>>> On Nov 22, 2012, at 15:17 , Lubomir Nerad wrote: >>>>> >>>>>> Hi Randahl, >>>>>> >>>>>> On 11/22/2012 12:02 AM, Randahl Fink Isaksen wrote: >>>>>>> For some weeks now, I have been struggling with poor UI construction performance in our application. JavaFX renders like a breeze, but the time it takes to construct complex Node trees is unacceptable to end users. >>>>>>> >>>>>>> Our app presents a landscape of data, which the user can navigate freely. A large number of entities are presented in this landscape each in their own little editing panel, complete with buttons, labels and text fields. This works great for small data sets of up to 10 entities. The problem is, that the raw construction of each panel takes around 80 milliseconds ? even on my crazily fast 16 core MacPro ? because, it seems all UI construction is carried out on a single core. The end result is, constructing a UI containing 50 editing panels takes 50 x 80 milliseconds = 4 seconds. That is not too bad given the complexity of the UI ? the real problem is, the UI freezes completely during those 4 seconds, so I am not able to provide animated feedback like, say, a progress bar giving telling the user how long the UI construction will take. >>>>>>> >>>>>>> Now, I have indeed tried a divide and conquer approach where I used 4 separate threads to create the editing panels in parallel, but apparantly that is a no-go, because each UI has complex bindings and listeners which are triggered from my editing panel constructors, and then I end up with deep down JavaFX internal exceptions saying something along the lines of "You have to use the JavaFX thread", which of course is no surprise, recalling the JavaFX single threaded nature. >>>>>> JavaFX is supposed to support constructing isolated subtrees of the scenegraph on separate threads, but then if you need to add them to the main tree (connected to the Scene), you'll need to do that final step on the main thread. So if you get exceptions while constructing subtrees, you should report them in Jira. >>>>>> >>>>>>> I would be very interested in hearing from other application developers implementing complex UI, if they would be so kind to share their experiences. Or from JavaFX API developers who could share some insights on how to speed up complex UI construction. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Randahl >>>>>> Thanks, >>>>>> Lubo From tom.schindl at bestsolution.at Fri Nov 23 02:08:35 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 23 Nov 2012 11:08:35 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AE7435.8020503@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> Message-ID: <50AF4B23.9000404@bestsolution.at> Hi, Let me retry - I hope this doesn't get too long. FXML is simply a serialization definition to serialize ANY given java-object graph. Let's take your example: which means in full blown FXML without default-attributes So written in Java-Code it means HBox box = new HBox(); Label l = new Label(); l.set... HBox.C c = new HBox.C(); c.set... l.setConstraint(c); box.getChildren().add(l); Definately not what you want because your layout-containers code looks like this: HBox box = new HBox(); Label l = new Label(); l.set... HBox.C c = new HBox.C(); c.set... box.add(l,c); Which clearly violates the generic serialisation which says sub-elements are always added (if it is a list) / set (single attribute) on the attribute they are the child of. So if we take your proposed FXML as shown above we have a problem because when we follow the general serialization/deserialization strategy we'd have to have a layoutConstraint-Property on the *Node* although things like layouts only make sense when you add the node inside a layout-container but not if it is e.g. a child of a Group, ... To summerize: My point - I fully agree with you that when coding the UI in Java your layout-container additions make a whole lot of sense but they break the serialization infrastructure because the addition is not done on the attribute itself (children) but through the owner of the attribute (HBox). Tom Am 22.11.12 19:51, schrieb Tom Eugelink: > Not sure I understand what you are trying to say here. Each layout has > different and much deviating constraints, so they cannot be unified into > one model. > > I think I summarized it well in my blogpost: "All information about the > layout of a single node should be stored in one place." This means > absolute layout can suffice with the X,Y,W,H information available in > the nodes (and thus allow binding), but all more advanced layouts > require a separate constraint class. > > Tom > > > > > On 2012-11-21 22:42, Tom Schindl wrote: >> the nice thing about the current expression with static calls is that >> the semantics for adding children are always the same whether your >> target is a Layout-Container or e.g. a Group. >> >> You always call add on the target your specified. Your way of layout >> containers expects two different things to happen: >> * for layout container you want to call add on the owner because you >> want to pass the constraint object >> * you can add on the list itself for stuff like Group but also Tables >> >> Not to forget how would you like set the constraint when you not add to >> a list e.g. when using a borderpane? >> >> Tom >> >> Am 21.11.12 19:02, schrieb Tom Eugelink: >>> I suspect the constraints were already "out" before FXML, but this would >>> be a fairly acceptable notation: >>> >>> | >>> >>> | >>> >>> >>> Or: >>> >>> | >>> >>> | >>> >>> >>> >>> On 2012-11-21 17:46, Tom Schindl wrote: >>>> Am 21.11.12 09:46, schrieb Richard Bair: >>>>> I wanted constraint classes from the start. There was a problem >>>>> there, which I don't accurately remember now, but I do want to see >>>>> some discussion around deprecating (or at least no longer depending >>>>> on) the static methods and having some constraint classes again. >>>> They've probably been harder to implement in FXML? >>>> >>>> Tom >>>> >>>> >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Fri Nov 23 06:48:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 23 Nov 2012 14:48:35 +0000 Subject: hg: openjfx/8/graphics/rt: impl_ method cleanup in Animation. Message-ID: <20121123144839.D427447AF2@hg.openjdk.java.net> Changeset: 4e7d364feafc Author: Martin Sladecek Date: 2012-11-23 14:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4e7d364feafc impl_ method cleanup in Animation. ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java From tbee at tbee.org Fri Nov 23 23:18:35 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 24 Nov 2012 08:18:35 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50AF4B23.9000404@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> Message-ID: <50B074CB.6010807@tbee.org> Ah, yes. We can start by agreeing that it will not be easy, or even possible, to always create a good Java API that also is easy mappable and readable onto FXML by simple serialization. So then you come into a conflict of priorities, what is more important: a good Java API or a readable FXML? We had similar issues with MigPane which also has a constaint class: Here we decided to use the string notation for the controls. But in order to process this, we also needed a few static methods on MigPane. Since I really feel uncomfortable with polluting the Java API with things that basically are required by the layer above, I decided (to the dismay of some others) to create a separate MigPane class in a fxml subpackage which contains these methods. http://code.google.com/p/miglayout/source/browse/javafx/src/main/java/org/tbee/javafx/scene/layout/fxml/MigPane.java A similar approach for the alternative HBox would basically result in the same API as HBox currently has: With one important difference in that there still is a formal constraint class being set instead of an obscure internal map. And, like MigPane, I would not place these methods in the HBox class directly, but a special FXML version. Keep the Java API clean. But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider In this way both Java API and FXML can be optimal. The plugin can also be extended to help the scene builder, by providing meta data for when it can't rely on reflection alone. I suspect the future will only introduce more of such conflict areas and rolling in a good solution instead of patching it would be IMHO the right way (tm). Tom On 2012-11-23 11:08, Tom Schindl wrote: > Hi, > > Let me retry - I hope this doesn't get too long. > > FXML is simply a serialization definition to serialize ANY given > java-object graph. > > Let's take your example: > > > > > which means in full blown FXML without default-attributes > > > > > > > So written in Java-Code it means > > HBox box = new HBox(); > Label l = new Label(); > l.set... > HBox.C c = new HBox.C(); > c.set... > l.setConstraint(c); > box.getChildren().add(l); > > Definately not what you want because your layout-containers code looks > like this: > > HBox box = new HBox(); > Label l = new Label(); > l.set... > HBox.C c = new HBox.C(); > c.set... > box.add(l,c); > > Which clearly violates the generic serialisation which says sub-elements > are always added (if it is a list) / set (single attribute) on the > attribute they are the child of. > > So if we take your proposed FXML as shown above we have a problem > because when we follow the general serialization/deserialization > strategy we'd have to have a layoutConstraint-Property on the *Node* > although things like layouts only make sense when you add the node > inside a layout-container but not if it is e.g. a child of a Group, ... > > To summerize: My point - I fully agree with you that when coding the UI > in Java your layout-container additions make a whole lot of sense but > they break the serialization infrastructure because the addition is not > done on the attribute itself (children) but through the owner of the > attribute (HBox). > > Tom > > Am 22.11.12 19:51, schrieb Tom Eugelink: >> Not sure I understand what you are trying to say here. Each layout has >> different and much deviating constraints, so they cannot be unified into >> one model. >> >> I think I summarized it well in my blogpost: "All information about the >> layout of a single node should be stored in one place." This means >> absolute layout can suffice with the X,Y,W,H information available in >> the nodes (and thus allow binding), but all more advanced layouts >> require a separate constraint class. >> >> Tom >> >> >> >> >> On 2012-11-21 22:42, Tom Schindl wrote: >>> the nice thing about the current expression with static calls is that >>> the semantics for adding children are always the same whether your >>> target is a Layout-Container or e.g. a Group. >>> >>> You always call add on the target your specified. Your way of layout >>> containers expects two different things to happen: >>> * for layout container you want to call add on the owner because you >>> want to pass the constraint object >>> * you can add on the list itself for stuff like Group but also Tables >>> >>> Not to forget how would you like set the constraint when you not add to >>> a list e.g. when using a borderpane? >>> >>> Tom >>> >>> Am 21.11.12 19:02, schrieb Tom Eugelink: >>>> I suspect the constraints were already "out" before FXML, but this would >>>> be a fairly acceptable notation: >>>> >>>> | >>>> >>>> | >>>> >>>> >>>> Or: >>>> >>>> | >>>> >>>> | >>>> >>>> >>>> >>>> On 2012-11-21 17:46, Tom Schindl wrote: >>>>> Am 21.11.12 09:46, schrieb Richard Bair: >>>>>> I wanted constraint classes from the start. There was a problem >>>>>> there, which I don't accurately remember now, but I do want to see >>>>>> some discussion around deprecating (or at least no longer depending >>>>>> on) the static methods and having some constraint classes again. >>>>> They've probably been harder to implement in FXML? >>>>> >>>>> Tom >>>>> >>>>> > From tbee at tbee.org Sun Nov 25 00:09:30 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 25 Nov 2012 09:09:30 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B074CB.6010807@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> Message-ID: <50B1D23A.3090706@tbee.org> I've pondered a bit on the "glue". Suppose there is a plugin interface like this: interface FxmlPlugin { /** * Called after the FXML is parsed and before deserializing. * Allows for the XML tree to be modified with, for example, XSLT. */ boolean beforeDocument(xml.Document document); /** * Called before each XML node is processed. * JavafxNodes contains the hierarchical list of nodes with the immediate parent at (0) to the root and the end of the list. * @return true if the engine should continue deserializing with this node, false if the node should be skipped */ boolean beforeNode(xml.Document document, xml.Node xmlNode, List javafxNodes); /** * Called after each XML node is processed. * JavafxNodes contains the hierarchical list of nodes with the just created node at (0) to the root and the end of the list. */ void afterNode(xml.Document document, xml.Node xmlNode, List javafxNodes); /** * Called after the FXML is parsed and deserialized. * Allows for the JavaFX nodes to be post processed */ void afterDocument(xml.Document document, javafx.Node javafxRoot); } There is a lot more to the interface than this, but adding that would obfuscate the essence at this point. In order to allow the (by me) favored FXML notation: The plugin would look something like this (in pseudo code) class HBoxFxmlPlugin extends FxnmlPluginImpl { @Override boolean beforeNode(xml.Document document, xml.Node xmlNode, List javafxNodes) { // when processing HBox.C if (xmlNode instanceof HBox.C == false) return true; // maybe we should create a annotation for this // parent of parent must be HBox if (javafxNodes.get(1) instanceof HBox == false) throw exception; // create constraint HBox.C c = new HBox.C(); if (xmlNode.getAttribute("vgrow") != null) c.vgrow( xmlNode.getAttribute("vgrow") ); if (xmlNode.getAttribute("valignment") != null) c.valignment( xmlNode.getAttribute("valignment") ); ... // set constraint for node ((HBox)javafxNodes.get(1)).setConstraint( javafxNodes.get(0), c); // the deserialize engine should not process this node anymore return false; } } Some advanced features, like setting a constraint for nodes that are not yet part of a layout (and don't even exist at that time), like so: Can be handled by detecting the "for" attribute, temporarily storing the xml and Javafx node plus the layout, and adding the constraint in the afterDocument method. Something similar can be done for scene builder. Basically scene builder manipulates a XML tree, so by responding to events: interface SceneBuilderPlugin { void beforeNodeAdd(Document document, Node parent, Node node); void afterNodeAdd(Document document, Node parent, Node node); void beforeNodeRemove(Document document, Node parent, Node node); void afterNodeRemove(Document document, Node parent, Node node); } The "HBox.C" node can easily be inserted after a node is added to an HBox layout. Or when changing the layout class from HBox to, say, GridPane, the scene builder first should: - remove all children from the layout (thus also removing the HBox.C constraint class), - then remove the HBox node, - add a new GridPane node, - add all children to the GridPane (thus causing the default GridPane.C to be added) In this way the Java API can be completely clean, and all the glue is neatly placed into two clear classes, which are provided as part of the jar. Tom On 2012-11-24 08:18, Tom Eugelink wrote: > But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. > > http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider From zonski at gmail.com Sun Nov 25 03:29:31 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 25 Nov 2012 22:29:31 +1100 Subject: JavaFX Maven Plugin In-Reply-To: <50A3A0C7.1050704@nosphere.org> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> Message-ID: Hey guys, Is there any more news on the open sourcing of the packaging tools? It's been a "few days away" since October 27. I have made some good progress with the JavaFX Maven Plugin. It now supports a lot of stuff Maven users would expect and could potentially reduce the barrier to entry for a lot of people to using JavaFX, especially Maven users (i.e. the bulk of the JEE community). I've written a blog post showcasing some of the more useful features here: http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/ I have also made in-roads into getting it so that WiX can be downloaded automatically for users when needed, instead of the current, very non-Maven need to manually install it. I have permission (or at least recognition and no objections) from the WiX devs to put the zip of Wix in the Maven repo. I'm half way through the motions of making this happen. Unfortunately the JFX native bundler code is totally hard coded for a lot of things it shouldn't be and I am going to have to build my own so I can use the downloaded WiX (the jfx packager assumes it is on the system path). I think using Velocity templates I can make a more powerful/customisable/extensible native bundler anyway, so rewriting this was already on the cards and it doesn't look overly complicated. What I'd really like to not have to rewrite are the native launcher executables that get bundled into the installers (i.e. the "exe" on windows). I can rip these out of the Java bundle for now to do my development but I won't be able to release my improved bundler until these bits are open sourced, giving me the legal all clear to include them in my plugin. Any chance I could get an actual timeframe on when the packaging tools are to be open sourced? I'm doing my best to contribute what I personally think is vitally important for JavaFX. In general I'm accepting of the fact that what I'm doing is not something Oracle sees as overly important and I'm on my own (it's been quite a liberating attitude to take to be honest). Open Sourcing the packaging tools however, was something you said you were going to do anyway and it would save me having to write a whole new native launcher for each platform. Cheers, Dan On Thu, Nov 15, 2012 at 12:46 AM, Paul Merlin wrote: > Dan, > > Daniel Zwolenski a ?crit : > > Hi Paul, >> >> Not sure if you came into the group before or after some of the more >> recent discussions. Probably worth having a flick through the recent >> archives on the topic of "JavaFX Packaging tools". >> >> As discussed somewhat before, the use of reflection was a work around the >> licencing issues. I'm legally not allowed to put the jar in a public Maven >> repo so instead I hacked up a solution that looked for the JAR in the JDK >> and used reflection to call onto it. Crude, but after a year of trying to >> get better Maven support going in JFX, this was my fallback. >> >> There's many ways to skin a cat, and your option is perfectly valid too - >> basically doing the same search into the JDK but instead of using >> reflection, installing it into the local repo (and thus avoiding licencing >> issues, assuming it's a private repo). One small drawback to this for me is >> that the developer still has to add dependencies to their POM, and as soon >> as Java 8 (or possibly 7u10) properly add JFX to the classpath those >> dependencies will need to be removed. In the hack I went for, the mess is >> hidden from the developer and the pain is all hidden inside my code - >> easier for the user, harder for me. >> > > Sure, I needed to hack a plugin that use the somewhat limited JavaFX build > tools currently available but allowing to roll maven releases plus some > other things. I choosed to not use reflection because I needed it working > quickly and installing the artifact in the local repository made everything > much easier. > > About the dependency to jfx-rt issue that should go away anytime soon. > This dependency should be declared in the provided scope, meaning that even > if people will be able to remove it, it should not prevent their project to > build. > > My maven plugin works starting today but is not the panacea, indeed. > > > In any case, I've started on a different tact to the reflection based one >> anyway. The more I've tried to use the built in JFX tasks, the more >> limiting I've found them. So now I'm in the process of writing an >> alternative toolset (https://github.com/zonski/**javafx-deploy-lib). >> At this stage I'm just creating my own JNLP and Applet generators, but if >> it makes sense and I have the energy I may look at going all the way. Once >> the JFX tools are open sourced I don't believe there's anything stopping me >> from taking bits that I like directly out of there if I use the same >> licence (need to check up on this). So stuff like the signing I might take >> verbatim but stuff like the JNLP generation, I'll completely replace with >> something more powerful. >> >> Depending on motivation and time, I may also look at doing the native >> bundling in a different way and also adding Windows 8 Metro support. I'd >> really like to avoid developers having to download additional tools like >> WiX for standard builds. This could be a huge amount of work though, so >> need to look into it before aiming too high (and alternative might be to >> look at the Maven plugin downloading WiX magically). >> > > Having this in separate projects make sense to me. Like you say below this > would allow different build systems (ant, maven, gradle, sbt ...) to reuse > this. I agree that it should help with the release cycle issue too. > > Downloading needed tools and instrumenting them can surely be done. WiX > provide a zipped binary distribution without installer and it is command > line driven so it should be pretty straight forward. > > Another example of what could be easily added is producing .deb packages > for Debian based Linux distributions. > > > I've also shot off some questions to the guys building the compact JRE >> profiles and in theory there is nothing stopping us from getting these >> working for desktop as well. If we can make that happen then building in >> compact profile management into the build tool would be another great goal >> (and maybe even one day being able to build all the cross-platform >> installers on the one OS - pipe dream). All of this work would also be a >> necessary pre-cursor to mobile, which I'm still naively holding out hope >> that this will one day get sorted. A Maven plugin where you just add an >> extra and tag into it and magically get a distro ready for >> the app stores would be very nice. >> >> If you, or anyone, are interested in working collaboratively on this, I'd >> be keen for that. My goal is to have a super slick Maven tool that can >> build production-grade, release-ready JavaFX apps with absolute minimal >> fuss. If that same code can then be shared between Gradle and other build >> tools giving developers the full spectrum of choice that would be a good >> thing in my book. I feel like the deploy-lib is the way to go, rather than >> wrappering the JFX tools so if you're on board with that basic direction, >> then join on in. >> > > Seems to be the way to go and looks exciting. > I'm in, waiting for the JavaFX build tools to be opensourced, then we'll > see what's next. > > /Paul > > > From tbee at tbee.org Sun Nov 25 03:51:01 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 25 Nov 2012 12:51:01 +0100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> Message-ID: <50B20625.8080502@tbee.org> Hey Dan, Just read your blog and I think it is great that someone is finally tackling the Maven / installer issue. However, I would like to point one thing out: from the remark about duplicate classnames I conclude that you unpack all jars and repack them into a single jar. This is the only easy way to get a startable jar, but there are a few other catches beside the duplicate classnames. First, some licenses do not allow this repacking and require that you distributed the jar as-is. Secondly, some jars have been signed and repackaging will break them. I ran into all of these when I tried to create a single jar deliverable of my Swing ERP application. The better approach would be to use one-jar (http://one-jar.sourceforge.net/) which adds a special class loader to load classes from the jars inside the jar. It's a good and often used solution. However, I ran into the problem that this approach prevents the use of certain command line arguments, like -javaagent, because the classloader is not installed when the command line arguments are parsed. So I created an alternative called "app-jar", which basically does what EDI's do and spawns a separate JVM; it unpacks the jar into a tmp directory, then creates a new java JVM and starts that. The initial JVM then goes into a monitoring state, watching the spawned JVM, and as soon as that is stopped, it cleans up the tmp directory. The only catch is that you have to understand this spawning process, because you need to specify "double D's" (which has nothing to do with women) for certain parameters. This is because of the "-D-D" notation being used: "-Dtest" goes to the spawing JVM, "-D-Dtest" is forwarded as "-Dtest" to the spawned JVM. So the "-javaagent" is set as "-D-javaagent". Just a suggestion. Tom On 2012-11-25 12:29, Daniel Zwolenski wrote: > Hey guys, > > Is there any more news on the open sourcing of the packaging tools? It's > been a "few days away" since October 27. > > I have made some good progress with the JavaFX Maven Plugin. It now > supports a lot of stuff Maven users would expect and could potentially > reduce the barrier to entry for a lot of people to using JavaFX, especially > Maven users (i.e. the bulk of the JEE community). I've written a blog post > showcasing some of the more useful features here: > http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/ > > I have also made in-roads into getting it so that WiX can be downloaded > automatically for users when needed, instead of the current, very non-Maven > need to manually install it. I have permission (or at least recognition and > no objections) from the WiX devs to put the zip of Wix in the Maven repo. > I'm half way through the motions of making this happen. > > Unfortunately the JFX native bundler code is totally hard coded for a lot > of things it shouldn't be and I am going to have to build my own so I can > use the downloaded WiX (the jfx packager assumes it is on the system path). > I think using Velocity templates I can make a more > powerful/customisable/extensible native bundler anyway, so rewriting this > was already on the cards and it doesn't look overly complicated. > > What I'd really like to not have to rewrite are the native launcher > executables that get bundled into the installers (i.e. the "exe" on > windows). I can rip these out of the Java bundle for now to do my > development but I won't be able to release my improved bundler until these > bits are open sourced, giving me the legal all clear to include them in my > plugin. > > Any chance I could get an actual timeframe on when the packaging tools are > to be open sourced? > > I'm doing my best to contribute what I personally think is vitally > important for JavaFX. In general I'm accepting of the fact that what I'm > doing is not something Oracle sees as overly important and I'm on my own > (it's been quite a liberating attitude to take to be honest). Open Sourcing > the packaging tools however, was something you said you were going to do > anyway and it would save me having to write a whole new native launcher for > each platform. > > Cheers, > Dan > > > > > > > > > On Thu, Nov 15, 2012 at 12:46 AM, Paul Merlin wrote: > >> Dan, >> >> Daniel Zwolenski a ?crit : >> >> Hi Paul, >>> Not sure if you came into the group before or after some of the more >>> recent discussions. Probably worth having a flick through the recent >>> archives on the topic of "JavaFX Packaging tools". >>> >>> As discussed somewhat before, the use of reflection was a work around the >>> licencing issues. I'm legally not allowed to put the jar in a public Maven >>> repo so instead I hacked up a solution that looked for the JAR in the JDK >>> and used reflection to call onto it. Crude, but after a year of trying to >>> get better Maven support going in JFX, this was my fallback. >>> >>> There's many ways to skin a cat, and your option is perfectly valid too - >>> basically doing the same search into the JDK but instead of using >>> reflection, installing it into the local repo (and thus avoiding licencing >>> issues, assuming it's a private repo). One small drawback to this for me is >>> that the developer still has to add dependencies to their POM, and as soon >>> as Java 8 (or possibly 7u10) properly add JFX to the classpath those >>> dependencies will need to be removed. In the hack I went for, the mess is >>> hidden from the developer and the pain is all hidden inside my code - >>> easier for the user, harder for me. >>> >> Sure, I needed to hack a plugin that use the somewhat limited JavaFX build >> tools currently available but allowing to roll maven releases plus some >> other things. I choosed to not use reflection because I needed it working >> quickly and installing the artifact in the local repository made everything >> much easier. >> >> About the dependency to jfx-rt issue that should go away anytime soon. >> This dependency should be declared in the provided scope, meaning that even >> if people will be able to remove it, it should not prevent their project to >> build. >> >> My maven plugin works starting today but is not the panacea, indeed. >> >> >> In any case, I've started on a different tact to the reflection based one >>> anyway. The more I've tried to use the built in JFX tasks, the more >>> limiting I've found them. So now I'm in the process of writing an >>> alternative toolset (https://github.com/zonski/**javafx-deploy-lib). >>> At this stage I'm just creating my own JNLP and Applet generators, but if >>> it makes sense and I have the energy I may look at going all the way. Once >>> the JFX tools are open sourced I don't believe there's anything stopping me >>> from taking bits that I like directly out of there if I use the same >>> licence (need to check up on this). So stuff like the signing I might take >>> verbatim but stuff like the JNLP generation, I'll completely replace with >>> something more powerful. >>> >>> Depending on motivation and time, I may also look at doing the native >>> bundling in a different way and also adding Windows 8 Metro support. I'd >>> really like to avoid developers having to download additional tools like >>> WiX for standard builds. This could be a huge amount of work though, so >>> need to look into it before aiming too high (and alternative might be to >>> look at the Maven plugin downloading WiX magically). >>> >> Having this in separate projects make sense to me. Like you say below this >> would allow different build systems (ant, maven, gradle, sbt ...) to reuse >> this. I agree that it should help with the release cycle issue too. >> >> Downloading needed tools and instrumenting them can surely be done. WiX >> provide a zipped binary distribution without installer and it is command >> line driven so it should be pretty straight forward. >> >> Another example of what could be easily added is producing .deb packages >> for Debian based Linux distributions. >> >> >> I've also shot off some questions to the guys building the compact JRE >>> profiles and in theory there is nothing stopping us from getting these >>> working for desktop as well. If we can make that happen then building in >>> compact profile management into the build tool would be another great goal >>> (and maybe even one day being able to build all the cross-platform >>> installers on the one OS - pipe dream). All of this work would also be a >>> necessary pre-cursor to mobile, which I'm still naively holding out hope >>> that this will one day get sorted. A Maven plugin where you just add an >>> extra and tag into it and magically get a distro ready for >>> the app stores would be very nice. >>> >>> If you, or anyone, are interested in working collaboratively on this, I'd >>> be keen for that. My goal is to have a super slick Maven tool that can >>> build production-grade, release-ready JavaFX apps with absolute minimal >>> fuss. If that same code can then be shared between Gradle and other build >>> tools giving developers the full spectrum of choice that would be a good >>> thing in my book. I feel like the deploy-lib is the way to go, rather than >>> wrappering the JFX tools so if you're on board with that basic direction, >>> then join on in. >>> >> Seems to be the way to go and looks exciting. >> I'm in, waiting for the JavaFX build tools to be opensourced, then we'll >> see what's next. >> >> /Paul >> >> >> From zonski at gmail.com Sun Nov 25 04:40:45 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 25 Nov 2012 23:40:45 +1100 Subject: JavaFX Maven Plugin In-Reply-To: <50B20625.8080502@tbee.org> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> <50B20625.8080502@tbee.org> Message-ID: <3C4FBFF9-D386-406E-89EC-47C6481D7744@gmail.com> Thanks for the feedback Tom. I'm bleary eyed and off to bed now (it's been a long week of late night coding) so I'll look at this again in the morning. Just briefly though, for the executable jar I believe I'm just following the procedure used by the jfx Ant tasks. So the problems you raise (and great that you raise them) all apply to the ant tasks too. As such it would be good to get input from the Oracle jfx packaging team on your comments - ie what's their take on these problems and what's their solution. Not that I'm limited to doing it their way but would be good to hear thoughts on it before going down any particular road. On 25/11/2012, at 10:51 PM, Tom Eugelink wrote: > Hey Dan, > > Just read your blog and I think it is great that someone is finally tackling the Maven / installer issue. However, I would like to point one thing out: from the remark about duplicate classnames I conclude that you unpack all jars and repack them into a single jar. This is the only easy way to get a startable jar, but there are a few other catches beside the duplicate classnames. First, some licenses do not allow this repacking and require that you distributed the jar as-is. Secondly, some jars have been signed and repackaging will break them. I ran into all of these when I tried to create a single jar deliverable of my Swing ERP application. > > The better approach would be to use one-jar (http://one-jar.sourceforge.net/) which adds a special class loader to load classes from the jars inside the jar. It's a good and often used solution. > > However, I ran into the problem that this approach prevents the use of certain command line arguments, like -javaagent, because the classloader is not installed when the command line arguments are parsed. So I created an alternative called "app-jar", which basically does what EDI's do and spawns a separate JVM; it unpacks the jar into a tmp directory, then creates a new java JVM and starts that. The initial JVM then goes into a monitoring state, watching the spawned JVM, and as soon as that is stopped, it cleans up the tmp directory. The only catch is that you have to understand this spawning process, because you need to specify "double D's" (which has nothing to do with women) for certain parameters. This is because of the "-D-D" notation being used: "-Dtest" goes to the spawing JVM, "-D-Dtest" is forwarded as "-Dtest" to the spawned JVM. So the "-javaagent" is set as "-D-javaagent". > > Just a suggestion. > > Tom > > > On 2012-11-25 12:29, Daniel Zwolenski wrote: >> Hey guys, >> >> Is there any more news on the open sourcing of the packaging tools? It's >> been a "few days away" since October 27. >> >> I have made some good progress with the JavaFX Maven Plugin. It now >> supports a lot of stuff Maven users would expect and could potentially >> reduce the barrier to entry for a lot of people to using JavaFX, especially >> Maven users (i.e. the bulk of the JEE community). I've written a blog post >> showcasing some of the more useful features here: >> http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/ >> >> I have also made in-roads into getting it so that WiX can be downloaded >> automatically for users when needed, instead of the current, very non-Maven >> need to manually install it. I have permission (or at least recognition and >> no objections) from the WiX devs to put the zip of Wix in the Maven repo. >> I'm half way through the motions of making this happen. >> >> Unfortunately the JFX native bundler code is totally hard coded for a lot >> of things it shouldn't be and I am going to have to build my own so I can >> use the downloaded WiX (the jfx packager assumes it is on the system path). >> I think using Velocity templates I can make a more >> powerful/customisable/extensible native bundler anyway, so rewriting this >> was already on the cards and it doesn't look overly complicated. >> >> What I'd really like to not have to rewrite are the native launcher >> executables that get bundled into the installers (i.e. the "exe" on >> windows). I can rip these out of the Java bundle for now to do my >> development but I won't be able to release my improved bundler until these >> bits are open sourced, giving me the legal all clear to include them in my >> plugin. >> >> Any chance I could get an actual timeframe on when the packaging tools are >> to be open sourced? >> >> I'm doing my best to contribute what I personally think is vitally >> important for JavaFX. In general I'm accepting of the fact that what I'm >> doing is not something Oracle sees as overly important and I'm on my own >> (it's been quite a liberating attitude to take to be honest). Open Sourcing >> the packaging tools however, was something you said you were going to do >> anyway and it would save me having to write a whole new native launcher for >> each platform. >> >> Cheers, >> Dan >> >> >> >> >> >> >> >> >> On Thu, Nov 15, 2012 at 12:46 AM, Paul Merlin wrote: >> >>> Dan, >>> >>> Daniel Zwolenski a ?crit : >>> >>> Hi Paul, >>>> Not sure if you came into the group before or after some of the more >>>> recent discussions. Probably worth having a flick through the recent >>>> archives on the topic of "JavaFX Packaging tools". >>>> >>>> As discussed somewhat before, the use of reflection was a work around the >>>> licencing issues. I'm legally not allowed to put the jar in a public Maven >>>> repo so instead I hacked up a solution that looked for the JAR in the JDK >>>> and used reflection to call onto it. Crude, but after a year of trying to >>>> get better Maven support going in JFX, this was my fallback. >>>> >>>> There's many ways to skin a cat, and your option is perfectly valid too - >>>> basically doing the same search into the JDK but instead of using >>>> reflection, installing it into the local repo (and thus avoiding licencing >>>> issues, assuming it's a private repo). One small drawback to this for me is >>>> that the developer still has to add dependencies to their POM, and as soon >>>> as Java 8 (or possibly 7u10) properly add JFX to the classpath those >>>> dependencies will need to be removed. In the hack I went for, the mess is >>>> hidden from the developer and the pain is all hidden inside my code - >>>> easier for the user, harder for me. >>>> >>> Sure, I needed to hack a plugin that use the somewhat limited JavaFX build >>> tools currently available but allowing to roll maven releases plus some >>> other things. I choosed to not use reflection because I needed it working >>> quickly and installing the artifact in the local repository made everything >>> much easier. >>> >>> About the dependency to jfx-rt issue that should go away anytime soon. >>> This dependency should be declared in the provided scope, meaning that even >>> if people will be able to remove it, it should not prevent their project to >>> build. >>> >>> My maven plugin works starting today but is not the panacea, indeed. >>> >>> >>> In any case, I've started on a different tact to the reflection based one >>>> anyway. The more I've tried to use the built in JFX tasks, the more >>>> limiting I've found them. So now I'm in the process of writing an >>>> alternative toolset (https://github.com/zonski/**javafx-deploy-lib). >>>> At this stage I'm just creating my own JNLP and Applet generators, but if >>>> it makes sense and I have the energy I may look at going all the way. Once >>>> the JFX tools are open sourced I don't believe there's anything stopping me >>>> from taking bits that I like directly out of there if I use the same >>>> licence (need to check up on this). So stuff like the signing I might take >>>> verbatim but stuff like the JNLP generation, I'll completely replace with >>>> something more powerful. >>>> >>>> Depending on motivation and time, I may also look at doing the native >>>> bundling in a different way and also adding Windows 8 Metro support. I'd >>>> really like to avoid developers having to download additional tools like >>>> WiX for standard builds. This could be a huge amount of work though, so >>>> need to look into it before aiming too high (and alternative might be to >>>> look at the Maven plugin downloading WiX magically). >>>> >>> Having this in separate projects make sense to me. Like you say below this >>> would allow different build systems (ant, maven, gradle, sbt ...) to reuse >>> this. I agree that it should help with the release cycle issue too. >>> >>> Downloading needed tools and instrumenting them can surely be done. WiX >>> provide a zipped binary distribution without installer and it is command >>> line driven so it should be pretty straight forward. >>> >>> Another example of what could be easily added is producing .deb packages >>> for Debian based Linux distributions. >>> >>> >>> I've also shot off some questions to the guys building the compact JRE >>>> profiles and in theory there is nothing stopping us from getting these >>>> working for desktop as well. If we can make that happen then building in >>>> compact profile management into the build tool would be another great goal >>>> (and maybe even one day being able to build all the cross-platform >>>> installers on the one OS - pipe dream). All of this work would also be a >>>> necessary pre-cursor to mobile, which I'm still naively holding out hope >>>> that this will one day get sorted. A Maven plugin where you just add an >>>> extra and tag into it and magically get a distro ready for >>>> the app stores would be very nice. >>>> >>>> If you, or anyone, are interested in working collaboratively on this, I'd >>>> be keen for that. My goal is to have a super slick Maven tool that can >>>> build production-grade, release-ready JavaFX apps with absolute minimal >>>> fuss. If that same code can then be shared between Gradle and other build >>>> tools giving developers the full spectrum of choice that would be a good >>>> thing in my book. I feel like the deploy-lib is the way to go, rather than >>>> wrappering the JFX tools so if you're on board with that basic direction, >>>> then join on in. >>>> >>> Seems to be the way to go and looks exciting. >>> I'm in, waiting for the JavaFX build tools to be opensourced, then we'll >>> see what's next. >>> >>> /Paul >>> >>> >>> > From scott.kovatch at oracle.com Sun Nov 25 11:25:32 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Sun, 25 Nov 2012 11:25:32 -0800 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> Message-ID: On Nov 25, 2012, at 3:29 AM, Daniel Zwolenski wrote: > Hey guys, > > Is there any more news on the open sourcing of the packaging tools? It's > been a "few days away" since October 27. > > What I'd really like to not have to rewrite are the native launcher > executables that get bundled into the installers (i.e. the "exe" on > windows). I can rip these out of the Java bundle for now to do my > development but I won't be able to release my improved bundler until these > bits are open sourced, giving me the legal all clear to include them in my > plugin. > > Any chance I could get an actual timeframe on when the packaging tools are > to be open sourced? I'm chugging along with this, but I was off last week due to the US Thanksgiving holiday. The code has been cleaned up (read: commented, TODO's removed/bugs created) and ready for review. There is some code we want to retire as part of this process, and that means modifying some makefiles and ensuring everything builds correctly in the closed repository, and then we can move it to the open rt project in OpenJFX and make sure it builds there. So, it's happening, but there were some changes in assumptions I have to work around. Releasing something that won't build isn't helpful. I'll have a better timeframe early this week. > I'm doing my best to contribute what I personally think is vitally > important for JavaFX. In general I'm accepting of the fact that what I'm > doing is not something Oracle sees as overly important and I'm on my own > (it's been quite a liberating attitude to take to be honest). Open Sourcing > the packaging tools however, was something you said you were going to do > anyway and it would save me having to write a whole new native launcher for > each platform. I think it's great that you're interested in working on this. Deployment is not a glamorous job but it needs to be done. Without it, the rest of JavaFX isn't as useful, IMO. What we want to do is have a core API that's as tool-ignorant as possible, and then let developers like you put the tool frameworks around it. Right now we're closely tied to ant, and I'd like to get away from that. -- Scott K. ------------------------ Scott Kovatch Oracle Pleasanton, CA From james.weaver at oracle.com Sun Nov 25 13:13:22 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Sun, 25 Nov 2012 16:13:22 -0500 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> Message-ID: <4A963F55-D096-4873-8B6A-15489CBC0DEB@oracle.com> Daniel, +1 to Scott's sentiments about being glad that you're contributing to the vitally important JavaFX deployment effort! Thanks, Jim Weaver On Nov 25, 2012, at 2:25 PM, Scott Kovatch wrote: > On Nov 25, 2012, at 3:29 AM, Daniel Zwolenski wrote: > >> Hey guys, >> >> Is there any more news on the open sourcing of the packaging tools? It's >> been a "few days away" since October 27. >> >> What I'd really like to not have to rewrite are the native launcher >> executables that get bundled into the installers (i.e. the "exe" on >> windows). I can rip these out of the Java bundle for now to do my >> development but I won't be able to release my improved bundler until these >> bits are open sourced, giving me the legal all clear to include them in my >> plugin. >> >> Any chance I could get an actual timeframe on when the packaging tools are >> to be open sourced? > > I'm chugging along with this, but I was off last week due to the US Thanksgiving holiday. > > The code has been cleaned up (read: commented, TODO's removed/bugs created) and ready for review. There is some code we want to retire as part of this process, and that means modifying some makefiles and ensuring everything builds correctly in the closed repository, and then we can move it to the open rt project in OpenJFX and make sure it builds there. > > So, it's happening, but there were some changes in assumptions I have to work around. Releasing something that won't build isn't helpful. I'll have a better timeframe early this week. > >> I'm doing my best to contribute what I personally think is vitally >> important for JavaFX. In general I'm accepting of the fact that what I'm >> doing is not something Oracle sees as overly important and I'm on my own >> (it's been quite a liberating attitude to take to be honest). Open Sourcing >> the packaging tools however, was something you said you were going to do >> anyway and it would save me having to write a whole new native launcher for >> each platform. > > I think it's great that you're interested in working on this. Deployment is not a glamorous job but it needs to be done. Without it, the rest of JavaFX isn't as useful, IMO. > > What we want to do is have a core API that's as tool-ignorant as possible, and then let developers like you put the tool frameworks around it. Right now we're closely tied to ant, and I'd like to get away from that. > > -- Scott K. > > ------------------------ > Scott Kovatch > Oracle > Pleasanton, CA > From randahl at rockit.dk Sun Nov 25 15:44:12 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 26 Nov 2012 00:44:12 +0100 Subject: Increasing UI performance with multiple threads Message-ID: <33A9F180-C686-4DDD-A58A-DDF11689C66A@rockit.dk> I just wrote a how-to article on using multiple threads in JavaFX applications, but since this is rather complex, I cannot help feeling this ought to go into the JavaFX docs somewhere. Would the JavaFX team be interested in publishing some of this for everyones benefit? http://blog.randahl.dk/2012/11/javafx-leveraging-multi-core-performance.html Randahl From hang.vo at oracle.com Mon Nov 26 06:48:54 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 14:48:54 +0000 Subject: hg: openjfx/8/controls/rt: RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input Message-ID: <20121126144859.5B0E547B22@hg.openjdk.java.net> Changeset: 156774e6fa98 Author: mickf Date: 2012-11-26 14:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/156774e6fa98 RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input ! javafx-ui-common/src/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TitledPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ToolBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusListBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusPopupBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java From hang.vo at oracle.com Mon Nov 26 07:18:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 15:18:18 +0000 Subject: hg: openjfx/8/graphics/rt: fix of classpath related to move of the project from rt-closed repo to rt repo Message-ID: <20121126151824.A26E747B23@hg.openjdk.java.net> Changeset: 7a36755b17b5 Author: Milan Kubec Date: 2012-11-26 16:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a36755b17b5 fix of classpath related to move of the project from rt-closed repo to rt repo ! javafx-fxml/nbproject/project.xml From sven.reimers at gmail.com Mon Nov 26 08:12:25 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 26 Nov 2012 17:12:25 +0100 Subject: Why is jfxrt.jar not distributed as .pack? Message-ID: Hi, the subject says it all. rt.jar is delivered inside the jre installer as a .pack file to reduce download bandwidth / distribution size. Why is jfxrt.jar not delivered the same way? Should this be the case? Is this behaviour intentional? Shall I file a bug with JIRA? Thanks -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 lehmann at media-interactive.de Mon Nov 26 10:23:39 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 26 Nov 2012 19:23:39 +0100 Subject: NPE in FX code Message-ID: <50B3B3AB.80208@media-interactive.de> Hi, using an Eclipse exception breakpoint on NullPointerException I am getting a lot of internal NPE. They are catched somewhere and I am seeing them in the debugger only. It is not a big problem because I can simply filter everything in com.sun.* and javafx.* (and that's what I have to do). Question is, should this be happening in the first place? See below for an example of what I am getting right now on FX 2.2.2. Rgds Werner > Thread [JavaFX Application Thread] (Suspended (exception NullPointerException)) > T2KFontFactory.addToMaps(T2KFontFile) line: 1506 > T2KFontFactory.populateFontFileNameMapGeneric(String) line: 1548 > T2KFontFactory$5.run() line: 1433 > T2KFontFactory$5.run() line: 1431 > AccessController.doPrivileged(PrivilegedExceptionAction) line: not available [native method] > T2KFontFactory.getFullNameToFileMap() line: 1430 > T2KFontFactory.getFontFamilyNames() line: 1063 > WCFontImpl.getFont(String, boolean, boolean, float) line: 37 > FXGraphicsManager.getWCFont(String, boolean, boolean, float) line: 56 > URLLoader.twkDidFail(int, String, String, long) line: not available [native method] > URLLoader.access$1400(int, String, String, long) line: 42 > URLLoader$7.run() line: 669 > WinApplication._runLoop(String[], Launchable) line: not available [native method] > WinApplication.access$100(WinApplication, String[], Launchable) line: 29 > WinApplication$2$1.run() line: 67 > Thread.run() line: not available > Thread [AWT-EventQueue-0] (Suspended (exception NullPointerException)) > SystemProperties.setVersions() line: 81 > SystemProperties.access$200() line: 31 > SystemProperties$1.run() line: 66 > AccessController.doPrivileged(PrivilegedAction) line: not available [native method] > SystemProperties.() line: 62 > PlatformImpl.runLater(Runnable, boolean) line: 159 > PlatformImpl.runLater(Runnable) line: 148 > Platform.runLater(Runnable) line: 52 > MintSwingLoginScreen.() line: 39 > MintWebAssistantApplication.() line: 100 > MintWebAssistantApplication.() line: 79 > MintWebAssistantStart$1.startApplication() line: 133 > MintWebAssistantStart$1.run() line: 53 > InvocationEvent.dispatch() line: not available > EventQueue.dispatchEventImpl(AWTEvent, Object) line: not available > EventQueue.access$000(EventQueue, AWTEvent, Object) line: not available > EventQueue$1.run() line: not available > EventQueue$1.run() line: not available > AccessController.doPrivileged(PrivilegedAction, AccessControlContext) line: not available [native method] > AccessControlContext$1.doIntersectionPrivilege(PrivilegedAction, AccessControlContext, AccessControlContext) line: not available > EventQueue.dispatchEvent(AWTEvent) line: not available > EventDispatchThread.pumpOneEventForFilters(int) line: not available > EventDispatchThread.pumpEventsForFilter(int, Conditional, EventFilter) line: not available > EventDispatchThread.pumpEventsForHierarchy(int, Conditional, Component) line: not available > EventDispatchThread.pumpEvents(int, Conditional) line: not available > EventDispatchThread.pumpEvents(Conditional) line: not available > EventDispatchThread.run() line: not available > Thread [JavaFX Application Thread] (Suspended (exception NullPointerException)) > PropertyHelper$1.run() line: 41 > PropertyHelper$1.run() line: 37 > AccessController.doPrivileged(PrivilegedAction) line: not available [native method] > PropertyHelper.getBooleanProperty(String) line: 36 > Parent.() line: 88 > MintSwingLoginScreen$1.run() line: 43 > PlatformImpl$4.run() line: 173 > WinApplication._runLoop(String[], Launchable) line: not available [native method] > WinApplication.access$100(WinApplication, String[], Launchable) line: 29 > WinApplication$2$1.run() line: 67 > Thread.run() line: not available > Thread [JavaFX Application Thread] (Suspended (exception NullPointerException)) > SelectBinding$SelectBindingHelper.getObservableValue() line: 422 > SelectBinding$SelectBindingHelper.access$200(SelectBinding$SelectBindingHelper) line: 372 > SelectBinding$AsDouble.computeValue() line: 171 > SelectBinding$AsDouble(DoubleBinding).get() line: 202 > SelectBinding$AsDouble(DoubleExpression).getValue() line: 68 > SelectBinding$AsDouble(DoubleBinding).getValue() line: 111 > ExpressionHelper.addListener(ExpressionHelper, ObservableValue, InvalidationListener) line: 73 > SelectBinding$AsDouble(DoubleBinding).addListener(InvalidationListener) line: 121 > Region$7(DoublePropertyBase).bind(ObservableValue) line: 202 > MintApplicationBar.initialize(URL, ResourceBundle) line: 153 > FXMLLoader.load(InputStream) line: 2152 > MintFXUtils.loadFXML(FXMLLoader, URL) line: 154 > MintFXUtils.initializeCustomControl(Node, Class) line: 138 > MintFXUtils.initializeCustomControl(Node) line: 118 > MintApplicationBar.() line: 147 > MintSwingApplicationBar$1.run() line: 59 > PlatformImpl$4.run() line: 173 > WinApplication._runLoop(String[], Launchable) line: not available [native method] > WinApplication.access$100(WinApplication, String[], Launchable) line: 29 > WinApplication$2$1.run() line: 67 > Thread.run() line: not available From philip.race at oracle.com Mon Nov 26 10:37:32 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 26 Nov 2012 10:37:32 -0800 Subject: NPE in FX code In-Reply-To: <50B3B3AB.80208@media-interactive.de> References: <50B3B3AB.80208@media-interactive.de> Message-ID: <50B3B6EC.2030808@oracle.com> I am fairly certain this is http://javafx-jira.kenai.com/browse/RT-23826: ignored NPE loading jre font into font factory tables which is fixed in the FX8 release. -phil. On 11/26/2012 10:23 AM, Werner Lehmann wrote: > Hi, > > using an Eclipse exception breakpoint on NullPointerException I am > getting a lot of internal NPE. They are catched somewhere and I am > seeing them in the debugger only. It is not a big problem because I > can simply filter everything in com.sun.* and javafx.* (and that's > what I have to do). > > Question is, should this be happening in the first place? See below > for an example of what I am getting right now on FX 2.2.2. > > Rgds > Werner > >> Thread [JavaFX Application Thread] (Suspended (exception >> NullPointerException)) >> T2KFontFactory.addToMaps(T2KFontFile) line: 1506 >> T2KFontFactory.populateFontFileNameMapGeneric(String) line: 1548 >> T2KFontFactory$5.run() line: 1433 >> T2KFontFactory$5.run() line: 1431 >> AccessController.doPrivileged(PrivilegedExceptionAction) line: >> not available [native method] >> T2KFontFactory.getFullNameToFileMap() line: 1430 >> T2KFontFactory.getFontFamilyNames() line: 1063 >> WCFontImpl.getFont(String, boolean, boolean, float) line: 37 >> FXGraphicsManager.getWCFont(String, boolean, boolean, float) >> line: 56 >> URLLoader.twkDidFail(int, String, String, long) line: not >> available [native method] >> URLLoader.access$1400(int, String, String, long) line: 42 >> URLLoader$7.run() line: 669 >> WinApplication._runLoop(String[], Launchable) line: not available >> [native method] >> WinApplication.access$100(WinApplication, String[], Launchable) >> line: 29 >> WinApplication$2$1.run() line: 67 >> Thread.run() line: not available > >> Thread [AWT-EventQueue-0] (Suspended (exception NullPointerException)) >> SystemProperties.setVersions() line: 81 >> SystemProperties.access$200() line: 31 >> SystemProperties$1.run() line: 66 >> AccessController.doPrivileged(PrivilegedAction) line: not >> available [native method] >> SystemProperties.() line: 62 >> PlatformImpl.runLater(Runnable, boolean) line: 159 >> PlatformImpl.runLater(Runnable) line: 148 >> Platform.runLater(Runnable) line: 52 >> MintSwingLoginScreen.() line: 39 >> MintWebAssistantApplication.() line: 100 >> MintWebAssistantApplication.() line: 79 >> MintWebAssistantStart$1.startApplication() line: 133 >> MintWebAssistantStart$1.run() line: 53 >> InvocationEvent.dispatch() line: not available >> EventQueue.dispatchEventImpl(AWTEvent, Object) line: not available >> EventQueue.access$000(EventQueue, AWTEvent, Object) line: not >> available >> EventQueue$1.run() line: not available >> EventQueue$1.run() line: not available >> AccessController.doPrivileged(PrivilegedAction, >> AccessControlContext) line: not available [native method] >> AccessControlContext$1.doIntersectionPrivilege(PrivilegedAction, >> AccessControlContext, AccessControlContext) line: not available >> EventQueue.dispatchEvent(AWTEvent) line: not available >> EventDispatchThread.pumpOneEventForFilters(int) line: not available >> EventDispatchThread.pumpEventsForFilter(int, Conditional, >> EventFilter) line: not available >> EventDispatchThread.pumpEventsForHierarchy(int, Conditional, >> Component) line: not available >> EventDispatchThread.pumpEvents(int, Conditional) line: not available >> EventDispatchThread.pumpEvents(Conditional) line: not available >> EventDispatchThread.run() line: not available > >> Thread [JavaFX Application Thread] (Suspended (exception >> NullPointerException)) >> PropertyHelper$1.run() line: 41 >> PropertyHelper$1.run() line: 37 >> AccessController.doPrivileged(PrivilegedAction) line: not >> available [native method] >> PropertyHelper.getBooleanProperty(String) line: 36 >> Parent.() line: 88 >> MintSwingLoginScreen$1.run() line: 43 >> PlatformImpl$4.run() line: 173 >> WinApplication._runLoop(String[], Launchable) line: not available >> [native method] >> WinApplication.access$100(WinApplication, String[], Launchable) >> line: 29 >> WinApplication$2$1.run() line: 67 >> Thread.run() line: not available > >> Thread [JavaFX Application Thread] (Suspended (exception >> NullPointerException)) >> SelectBinding$SelectBindingHelper.getObservableValue() line: 422 >> SelectBinding$SelectBindingHelper.access$200(SelectBinding$SelectBindingHelper) >> line: 372 >> SelectBinding$AsDouble.computeValue() line: 171 >> SelectBinding$AsDouble(DoubleBinding).get() line: 202 >> SelectBinding$AsDouble(DoubleExpression).getValue() line: 68 >> SelectBinding$AsDouble(DoubleBinding).getValue() line: 111 >> ExpressionHelper.addListener(ExpressionHelper, >> ObservableValue, InvalidationListener) line: 73 >> SelectBinding$AsDouble(DoubleBinding).addListener(InvalidationListener) >> line: 121 >> Region$7(DoublePropertyBase).bind(ObservableValue) line: 202 >> MintApplicationBar.initialize(URL, ResourceBundle) line: 153 >> FXMLLoader.load(InputStream) line: 2152 >> MintFXUtils.loadFXML(FXMLLoader, URL) line: 154 >> MintFXUtils.initializeCustomControl(Node, Class) line: 138 >> MintFXUtils.initializeCustomControl(Node) line: 118 >> MintApplicationBar.() line: 147 >> MintSwingApplicationBar$1.run() line: 59 >> PlatformImpl$4.run() line: 173 >> WinApplication._runLoop(String[], Launchable) line: not available >> [native method] >> WinApplication.access$100(WinApplication, String[], Launchable) >> line: 29 >> WinApplication$2$1.run() line: 67 >> Thread.run() line: not available > From hang.vo at oracle.com Mon Nov 26 10:48:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 18:48:57 +0000 Subject: hg: openjfx/8/controls/rt: Fix for control skin needing two pulses after default skin change. Message-ID: <20121126184901.A994247B26@hg.openjdk.java.net> Changeset: 8b2acf78b060 Author: "Jasper Potts" Date: 2012-11-26 10:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8b2acf78b060 Fix for control skin needing two pulses after default skin change. ! javafx-ui-controls/src/javafx/scene/control/Control.java From lehmann at media-interactive.de Mon Nov 26 11:00:57 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 26 Nov 2012 20:00:57 +0100 Subject: NPE in FX code In-Reply-To: <50B3B6EC.2030808@oracle.com> References: <50B3B3AB.80208@media-interactive.de> <50B3B6EC.2030808@oracle.com> Message-ID: <50B3BC69.40102@media-interactive.de> Hi Phil, thanks - but that would apply to the first stacktrace only. Werner On 26.11.2012 19:37, Phil Race wrote: > I am fairly certain this is > http://javafx-jira.kenai.com/browse/RT-23826: ignored NPE loading jre > font into font factory tables > which is fixed in the FX8 release. From philip.race at oracle.com Mon Nov 26 11:04:00 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 26 Nov 2012 11:04:00 -0800 Subject: NPE in FX code In-Reply-To: <50B3BC69.40102@media-interactive.de> References: <50B3B3AB.80208@media-interactive.de> <50B3B6EC.2030808@oracle.com> <50B3BC69.40102@media-interactive.de> Message-ID: <50B3BD20.3010706@oracle.com> Yes, I don't know about the rest of them, I just recognised the top one. -phil. On 11/26/2012 11:00 AM, Werner Lehmann wrote: > Hi Phil, > > thanks - but that would apply to the first stacktrace only. > > Werner > > On 26.11.2012 19:37, Phil Race wrote: >> I am fairly certain this is >> http://javafx-jira.kenai.com/browse/RT-23826: ignored NPE loading jre >> font into font factory tables >> which is fixed in the FX8 release. From hang.vo at oracle.com Mon Nov 26 11:18:08 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 19:18:08 +0000 Subject: hg: openjfx/8/controls/rt: Fix for control skin needing two pulses after default skin change. Message-ID: <20121126191809.F272847B27@hg.openjdk.java.net> Changeset: 1956221ada12 Author: "Jasper Potts" Date: 2012-11-26 10:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1956221ada12 Fix for control skin needing two pulses after default skin change. ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java From hang.vo at oracle.com Mon Nov 26 12:17:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 20:17:27 +0000 Subject: hg: openjfx/8/controls/rt: RT-24228: Add RTL support to Scrollbar / ScrollPane Message-ID: <20121126201730.2703447B29@hg.openjdk.java.net> Changeset: 4e5a8c827dc4 Author: leifs Date: 2012-11-26 12:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4e5a8c827dc4 RT-24228: Add RTL support to Scrollbar / ScrollPane ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From hang.vo at oracle.com Mon Nov 26 12:32:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 20:32:24 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-26110 LineChart removes existing styles from custom symbols Message-ID: <20121126203225.4E6F647B2D@hg.openjdk.java.net> Changeset: a90b954395d7 Author: Paru Somashekar Date: 2012-11-26 12:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a90b954395d7 fix RT-26110 LineChart removes existing styles from custom symbols ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java From hang.vo at oracle.com Mon Nov 26 13:47:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 26 Nov 2012 21:47:37 +0000 Subject: hg: openjfx/8/graphics/rt: RT-24357 Text class change Message-ID: <20121126214739.70BB247B2E@hg.openjdk.java.net> Changeset: fe4bf1068eda Author: Yao Wang Date: 2012-11-26 13:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe4bf1068eda RT-24357 Text class change ! javafx-ui-common/src/javafx/scene/text/Text.java From jonathan.giles at oracle.com Mon Nov 26 14:19:49 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 27 Nov 2012 11:19:49 +1300 Subject: [Review request] TreeTableView Message-ID: <50B3EB05.6000406@oracle.com> Hi all, I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: https://wikis.oracle.com/display/OpenJDK/TreeTableView This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: http://javafx-jira.kenai.com/browse/RT-17288 The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. Thanks! -- Jonathan From zonski at gmail.com Mon Nov 26 14:33:47 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 27 Nov 2012 09:33:47 +1100 Subject: JavaFX Maven Plugin In-Reply-To: <4A963F55-D096-4873-8B6A-15489CBC0DEB@oracle.com> References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> <4A963F55-D096-4873-8B6A-15489CBC0DEB@oracle.com> Message-ID: Ignore that bit about needing it open sourced to get the launch exe out - I was being stupid, I should be able to extract it from the JDK directly, dodging the legal issues. I will need the launcher code for AU though eventually and it would be nice to be able to read through the code without using a decompiler. I think I can do nearly everything I need to by myself (just going to take a heap of work) except for one thing that would open up a lot more options: If the JRE for each platform was available as a zip for download from somewhere public (i.e. that an automated program could download - none of that annoying "accept the licence" thing) then this opens the road to cross-platform native distros and simpler builds. It doesn't have to be in a Maven repo, it can still have the same licencing restrictions, it just needs to be publicly available without stop-gates in the way (e.g. a simple download from java.com). Technically this should be ridiculously easy and I think it would benefit the regular JFX deployment tools a lot too. I could actually create the zips but I'm not allowed to "distribute" the JRE, I can only "include" it in my app. The easiest way around this is for Oracle to be the distributor (as it is now) but just provide (a) the download as a zip file for each platform and (b) a way to download these zips without having to tick the "I accept the licence" thing on the web page. I know the second part will be the tricky one (kill all the lawyers) but if someone from Oracle (e.g. the JavaFX packaging team) could do some pushing, maybe it could happen sometime in the next year or two? On Mon, Nov 26, 2012 at 8:13 AM, Jim Weaver wrote: > Daniel, > > +1 to Scott's sentiments about being glad that you're contributing to the > vitally important JavaFX deployment effort! > > Thanks, > Jim Weaver > > On Nov 25, 2012, at 2:25 PM, Scott Kovatch > wrote: > > > On Nov 25, 2012, at 3:29 AM, Daniel Zwolenski wrote: > > > >> Hey guys, > >> > >> Is there any more news on the open sourcing of the packaging tools? It's > >> been a "few days away" since October 27. > >> > >> What I'd really like to not have to rewrite are the native launcher > >> executables that get bundled into the installers (i.e. the "exe" on > >> windows). I can rip these out of the Java bundle for now to do my > >> development but I won't be able to release my improved bundler until > these > >> bits are open sourced, giving me the legal all clear to include them in > my > >> plugin. > >> > >> Any chance I could get an actual timeframe on when the packaging tools > are > >> to be open sourced? > > > > I'm chugging along with this, but I was off last week due to the US > Thanksgiving holiday. > > > > The code has been cleaned up (read: commented, TODO's removed/bugs > created) and ready for review. There is some code we want to retire as part > of this process, and that means modifying some makefiles and ensuring > everything builds correctly in the closed repository, and then we can move > it to the open rt project in OpenJFX and make sure it builds there. > > > > So, it's happening, but there were some changes in assumptions I have to > work around. Releasing something that won't build isn't helpful. I'll have > a better timeframe early this week. > > > >> I'm doing my best to contribute what I personally think is vitally > >> important for JavaFX. In general I'm accepting of the fact that what I'm > >> doing is not something Oracle sees as overly important and I'm on my own > >> (it's been quite a liberating attitude to take to be honest). Open > Sourcing > >> the packaging tools however, was something you said you were going to do > >> anyway and it would save me having to write a whole new native launcher > for > >> each platform. > > > > I think it's great that you're interested in working on this. Deployment > is not a glamorous job but it needs to be done. Without it, the rest of > JavaFX isn't as useful, IMO. > > > > What we want to do is have a core API that's as tool-ignorant as > possible, and then let developers like you put the tool frameworks around > it. Right now we're closely tied to ant, and I'd like to get away from that. > > > > -- Scott K. > > > > ------------------------ > > Scott Kovatch > > Oracle > > Pleasanton, CA > > > From richard.bair at oracle.com Mon Nov 26 16:25:48 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 26 Nov 2012 16:25:48 -0800 Subject: [Review request] TreeTableView In-Reply-To: <50B3EB05.6000406@oracle.com> References: <50B3EB05.6000406@oracle.com> Message-ID: <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> Is there any kind of JavaDocs available for these APIs? For example, I'm wondering what the subclasses are of ResizeFeaturesBase, and the getters / setters / etc on the various proposed classes. Thanks Richard On Nov 26, 2012, at 2:19 PM, Jonathan Giles wrote: > Hi all, > > I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: > > https://wikis.oracle.com/display/OpenJDK/TreeTableView > > This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. > > To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: > > http://javafx-jira.kenai.com/browse/RT-17288 > > The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. > > I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. > > Thanks! > -- Jonathan From jonathan.giles at oracle.com Mon Nov 26 16:38:14 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 27 Nov 2012 13:38:14 +1300 Subject: [Review request] TreeTableView In-Reply-To: <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> Message-ID: <50B40B76.7030809@oracle.com> I'm working on writing the javadocs now, but I can put up a zip of the generated javadocs on jira as they stand now if that would be useful. -- Jonathan On Tuesday, 27 November 2012 1:25:48 p.m., Richard Bair wrote: > Is there any kind of JavaDocs available for these APIs? For example, I'm wondering what the subclasses are of ResizeFeaturesBase, and the getters / setters / etc on the various proposed classes. > > Thanks > Richard > > On Nov 26, 2012, at 2:19 PM, Jonathan Giles wrote: > >> Hi all, >> >> I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: >> >> https://wikis.oracle.com/display/OpenJDK/TreeTableView >> >> This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. >> >> To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: >> >> http://javafx-jira.kenai.com/browse/RT-17288 >> >> The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. >> >> I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. >> >> Thanks! >> -- Jonathan > From richard.bair at oracle.com Mon Nov 26 16:38:47 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 26 Nov 2012 16:38:47 -0800 Subject: [Review request] TreeTableView In-Reply-To: <50B40B76.7030809@oracle.com> References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> Message-ID: Sure, that would help. Richard On Nov 26, 2012, at 4:38 PM, Jonathan Giles wrote: > I'm working on writing the javadocs now, but I can put up a zip of the generated javadocs on jira as they stand now if that would be useful. > > -- Jonathan > > On Tuesday, 27 November 2012 1:25:48 p.m., Richard Bair wrote: >> Is there any kind of JavaDocs available for these APIs? For example, I'm wondering what the subclasses are of ResizeFeaturesBase, and the getters / setters / etc on the various proposed classes. >> >> Thanks >> Richard >> >> On Nov 26, 2012, at 2:19 PM, Jonathan Giles wrote: >> >>> Hi all, >>> >>> I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: >>> >>> https://wikis.oracle.com/display/OpenJDK/TreeTableView >>> >>> This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. >>> >>> To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: >>> >>> http://javafx-jira.kenai.com/browse/RT-17288 >>> >>> The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. >>> >>> I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. >>> >>> Thanks! >>> -- Jonathan >> From richard.bair at oracle.com Mon Nov 26 16:51:16 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 26 Nov 2012 16:51:16 -0800 Subject: Extending Builders: Layout Builders In-Reply-To: <50B074CB.6010807@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> Message-ID: > But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? Richard From richard.bair at oracle.com Mon Nov 26 16:55:26 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 26 Nov 2012 16:55:26 -0800 Subject: Increasing UI performance with multiple threads In-Reply-To: <33A9F180-C686-4DDD-A58A-DDF11689C66A@rockit.dk> References: <33A9F180-C686-4DDD-A58A-DDF11689C66A@rockit.dk> Message-ID: Hi Randahl, Has Jonathan linked this blog post via fxexperience? I've also forwarded to the docs team. Cheers Richard On Nov 25, 2012, at 3:44 PM, Randahl Fink Isaksen wrote: > I just wrote a how-to article on using multiple threads in JavaFX applications, but since this is rather complex, I cannot help feeling this ought to go into the JavaFX docs somewhere. Would the JavaFX team be interested in publishing some of this for everyones benefit? > http://blog.randahl.dk/2012/11/javafx-leveraging-multi-core-performance.html > > Randahl From jonathan.giles at oracle.com Mon Nov 26 17:00:56 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 27 Nov 2012 14:00:56 +1300 Subject: Increasing UI performance with multiple threads In-Reply-To: References: <33A9F180-C686-4DDD-A58A-DDF11689C66A@rockit.dk> Message-ID: <50B410C8.2030602@oracle.com> The post came out just after the weekly links were posted, but it is sitting ready to be posted next week. -- Jonathan On 27/11/2012 1:55 p.m., Richard Bair wrote: > Hi Randahl, > > Has Jonathan linked this blog post via fxexperience? I've also forwarded to the docs team. > > Cheers > Richard > > On Nov 25, 2012, at 3:44 PM, Randahl Fink Isaksen wrote: > >> I just wrote a how-to article on using multiple threads in JavaFX applications, but since this is rather complex, I cannot help feeling this ought to go into the JavaFX docs somewhere. Would the JavaFX team be interested in publishing some of this for everyones benefit? >> http://blog.randahl.dk/2012/11/javafx-leveraging-multi-core-performance.html >> >> Randahl From jonathan.giles at oracle.com Mon Nov 26 17:02:59 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 27 Nov 2012 14:02:59 +1300 Subject: [Review request] TreeTableView In-Reply-To: References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> Message-ID: <50B41143.30504@oracle.com> The Javadoc documentation has been attached to the Jira issue here: http://javafx-jira.kenai.com/browse/RT-17288 -- Jonathan On Tuesday, 27 November 2012 1:38:47 p.m., Richard Bair wrote: > Sure, that would help. > > Richard > > On Nov 26, 2012, at 4:38 PM, Jonathan Giles wrote: > >> I'm working on writing the javadocs now, but I can put up a zip of the generated javadocs on jira as they stand now if that would be useful. >> >> -- Jonathan >> >> On Tuesday, 27 November 2012 1:25:48 p.m., Richard Bair wrote: >>> Is there any kind of JavaDocs available for these APIs? For example, I'm wondering what the subclasses are of ResizeFeaturesBase, and the getters / setters / etc on the various proposed classes. >>> >>> Thanks >>> Richard >>> >>> On Nov 26, 2012, at 2:19 PM, Jonathan Giles wrote: >>> >>>> Hi all, >>>> >>>> I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: >>>> >>>> https://wikis.oracle.com/display/OpenJDK/TreeTableView >>>> >>>> This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. >>>> >>>> To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: >>>> >>>> http://javafx-jira.kenai.com/browse/RT-17288 >>>> >>>> The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. >>>> >>>> I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. >>>> >>>> Thanks! >>>> -- Jonathan >>> > From richard.bair at oracle.com Mon Nov 26 17:14:19 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 26 Nov 2012 17:14:19 -0800 Subject: [Review request] TreeTableView In-Reply-To: <50B41143.30504@oracle.com> References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> <50B41143.30504@oracle.com> Message-ID: Why does ResizeFeaturesBase getDelta return a Double instead of a double? What does the "null" value mean in this context? On Nov 26, 2012, at 5:02 PM, Jonathan Giles wrote: > The Javadoc documentation has been attached to the Jira issue here: > > http://javafx-jira.kenai.com/browse/RT-17288 > > -- Jonathan From jonathan.giles at oracle.com Mon Nov 26 17:19:31 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 27 Nov 2012 14:19:31 +1300 Subject: [Review request] TreeTableView In-Reply-To: References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> <50B41143.30504@oracle.com> Message-ID: <50B41523.40206@oracle.com> This appears to be an unfortunate and unintentional historical oversight. I have no desire for it to be Double, and could quite easily use double instead. Because of this, the meaning of null is undefined, but should probably mean 0.0. -- Jonathan On 27/11/2012 2:14 p.m., Richard Bair wrote: > Why does ResizeFeaturesBase getDelta return a Double instead of a double? What does the "null" value mean in this context? > > On Nov 26, 2012, at 5:02 PM, Jonathan Giles wrote: > >> The Javadoc documentation has been attached to the Jira issue here: >> >> http://javafx-jira.kenai.com/browse/RT-17288 >> >> -- Jonathan From richard.bair at oracle.com Mon Nov 26 17:21:26 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 26 Nov 2012 17:21:26 -0800 Subject: Increasing UI performance with multiple threads In-Reply-To: <33A9F180-C686-4DDD-A58A-DDF11689C66A@rockit.dk> References: <33A9F180-C686-4DDD-A58A-DDF11689C66A@rockit.dk> Message-ID: <7DA1A387-C99C-4189-9A8E-A696EE0890CC@oracle.com> Ah, just read the post (ya, I forwarded before I read ;-)) and this is great stuff. I didn't know about the Runnable.availableProcessors method call, that is going to prove useful when I go for a fork/join solution to rasterizing on multiple threads :-). Richard On Nov 25, 2012, at 3:44 PM, Randahl Fink Isaksen wrote: > I just wrote a how-to article on using multiple threads in JavaFX applications, but since this is rather complex, I cannot help feeling this ought to go into the JavaFX docs somewhere. Would the JavaFX team be interested in publishing some of this for everyones benefit? > http://blog.randahl.dk/2012/11/javafx-leveraging-multi-core-performance.html > > Randahl From hang.vo at oracle.com Mon Nov 26 19:17:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 27 Nov 2012 03:17:26 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121127031730.3FF6147B34@hg.openjdk.java.net> Changeset: 769200bca5be Author: "Jasper Potts" Date: 2012-11-26 19:06 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/769200bca5be Fix by David for StyleManager to make user agent stylesheet changes clear all caches and do complete refresh. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 5d89eacf62cc Author: "Jasper Potts" Date: 2012-11-26 19:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5d89eacf62cc Added way to override a nodes pseudo class state for testing and theme design. It is disabled by default and can be enabled by -Djavafx.pseudoClassOverrideEnabled=true that was done to minimize any performance impact. Once that is enabled you can do myButton.getProperties().put("javafx.scene.Node.pseudoClassOverride", "hover"); to make it look in the hover state. ! javafx-ui-common/src/javafx/scene/Node.java From markclaassenx at gmail.com Mon Nov 26 19:44:38 2012 From: markclaassenx at gmail.com (Mark Claassen) Date: Mon, 26 Nov 2012 22:44:38 -0500 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> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> <94AAF79B-01B5-442C-9270-D9705DB6454D@oracle.com> Message-ID: I sent a potential API change to Richard Bair a few weeks ago. He has not responded to me, which makes me think it was too complicated at this point and wasn't going to fly. I think for a good InputMaskField, the Content and the eventual caret position and selection needs to be controlled by the "model". This makes the solution a bit complex. However, for filtering, this is not the case. Doing both of these in one shot is, perhaps, a mistake. Here is another idea which takes care of the easy cases...easily. A more complex InputMask control I will save for later. So, here is the simplified idea: Add the ability to "filter". And by filter, I mean the ability to modify the input and only the input: Add the following sub-interface to the Content interface. No methods are added to the Content interface. interface Filter { String filter(int index, String text, String currentContent); } Add the following to TextFieldContent and TextAreaContent: private Content.Filter filter; public void setContentFilter(Content.Filter filter) { this.filter = filter; } Change the "insert" method of TextFieldContent and TextAreaContent to start with: @Override public void insert(int index, String text, boolean notifyListeners) { text = TextInputControl.filterInput(text, [boolean], [boolean]); if (filter != null) text = filter.filter(index, text, get()); Add a method in TextField: public void setContentFilter(Content.Filter filter) { ((TextFieldContent)getContent()).setContentFilter(filter); } Add a method in TextArea: public void setContentFilter(Content.Filter filter) { ((TextAreaContent)getContent()).setContentFilter(filter); } This would do a few things: 1) Use the current "TextInputControl.filterInput" mechanisms of TextField and TextArea (like to strip out special chars and newlines). 2) By specifying the Filter interface outside of TextField and TextArea, it allows the same filter to be used for TextField and TextArea 3) Makes it simple to do things like translate all input to upper case or limit the overall length 4) By not adding a method to Content directly, something like the InputMaskContent would not be forced to deal with the Filter interface at all. This implementation would allow someone creating a filter to "filter" the text to have illegal characters. I thought it was more validate this first, so that the implementer would only have to deal with proper input. However, TextInputControl.filterInput could be done both before and after the Filter.filter() call. text = TextInputControl.filterInput(text, [boolean], [boolean]); if (filter != null) { text = filter.filter(index, text, get()); text = TextInputControl.filterInput(text, [boolean], [boolean]); } Another possible addition to this may be to allow the filter to return null, signifying an error input and causing the system to "beep". Thanks for your consideration, Mark From tbee at tbee.org Mon Nov 26 22:16:18 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 27 Nov 2012 07:16:18 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> Message-ID: <50B45AB2.9070708@tbee.org> On 2012-11-27 01:51, Richard Bair wrote: >> But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. > Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? > I don't know. This is the first time I've heard of FXML builders, otherwise I would have used them for MigPane. I did not find anything on the google, do you have a reference to some documentation or example? Tom From zonski at gmail.com Mon Nov 26 22:51:11 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 27 Nov 2012 17:51:11 +1100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B45AB2.9070708@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B45AB2.9070708@tbee.org> Message-ID: They can be difficult to google thanks to "Scene Builder" hogging the google-sphere. Builders are basically convenience factories for building Nodes. Michael Heinrichs gives a good view on builders here: http://blog.netopyr.com/2012/01/24/advantages-of-javafx-builders/ They aren't really specific to FXML but FXML makes use of them to simplify the XML syntax and add convenience methods to Node classes. There's a bit of mention of them in the FXML docco: http://docs.oracle.com/javafx/2/api/javafx/fxml/doc-files/introduction_to_fxml.html#class_instance_elements There's a bit more of a clue on how to use them in this: http://jayskills.com/blog/2012/04/12/add-custom-components-to-fxml-using-builderfactory/ I haven't followed all of this conversation but I suspect builders could do the sort of syntactic sugar you wanted. >From the sounds of it, builders possibly could be used to simplify the MigPane code too (but I haven't looked and from a user's perspective, what you've done works fine). On Tue, Nov 27, 2012 at 5:16 PM, Tom Eugelink wrote: > On 2012-11-27 01:51, Richard Bair wrote: > >> But I'd rather use a different approach: provide (de)serializers that >>> help map the FXML onto the objects. I see FXML as a layer on top of the API >>> and good software development teachings say that lower layers should not >>> have any knowledge of higher layers, so I feel really really bad about >>> polluting the Java API to support FXML. Providing glue might be a better >>> approach. Java has standard plugin-style solutions in place, like >>> META-INF/services, so it should be easily possible to provide plugins >>> together with the components that help in those places where simple >>> serialization does not cut it. >>> >> Isn't this the role that the builders already play in the FXML >> deserialization routine? My understanding was that people would be able to >> create custom builders for their classes (and we could provide custom >> builders for ours) such that you would be able to map such things from the >> FXML? >> >> > I don't know. This is the first time I've heard of FXML builders, > otherwise I would have used them for MigPane. I did not find anything on > the google, do you have a reference to some documentation or example? > > Tom > From tbee at tbee.org Mon Nov 26 23:42:11 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 27 Nov 2012 08:42:11 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B45AB2.9070708@tbee.org> Message-ID: <50B46ED3.3040501@tbee.org> Uhuh. I see. Of course I know the regular builders for creating controls and layouts. I did not know that FXML uses builders with the same interface, which is probably why I skipped the wrong links on google. Anyhow, I see possible issues which would need to be addressed (http://docs.oracle.com/javafx/2/api/javafx/fxml/FXMLLoader.html): - First you can only provide one builder, so that would mean they'd have to chain, and that is very unpractical. - Secondly it's the fact that you need to explicitly provide the builder to the load method. I would aim for automatic inclusion; adding a jar with a set of control to the classpath should automatically add any builders required to parse the FXML. - And lastly: not all builders actually build something. In case of the HBox.C scenario it creates a constraint class, but pushes that out to a layout already created. The build method returns null. So I figure if these chances were made to the usage of builders in FXMLLoader, it could work for commen FXML scenario's. However, the SceneBuilder still would have no clue what constraint class to generate when adding a node to ABCLayout. And the thing I did with setting a HBox.C constraint on a layout where the node is not yet part of, would also be a problem: because it requires an "after document" style of event. It is my impression that the builder pattern is to narrow focused, and I'm not sure if bolting on the additional logic is the best course of action. It may be easier / cleaner to create a new API for that. Tom On 2012-11-27 07:51, Daniel Zwolenski wrote: > They can be difficult to google thanks to "Scene Builder" hogging the google-sphere. > > Builders are basically convenience factories for building Nodes. Michael Heinrichs gives a good view on builders here: http://blog.netopyr.com/2012/01/24/advantages-of-javafx-builders/ > > They aren't really specific to FXML but FXML makes use of them to simplify the XML syntax and add convenience methods to Node classes. There's a bit of mention of them in the FXML docco: http://docs.oracle.com/javafx/2/api/javafx/fxml/doc-files/introduction_to_fxml.html#class_instance_elements > > There's a bit more of a clue on how to use them in this: http://jayskills.com/blog/2012/04/12/add-custom-components-to-fxml-using-builderfactory/ > > I haven't followed all of this conversation but I suspect builders could do the sort of syntactic sugar you wanted. > > From the sounds of it, builders possibly could be used to simplify the MigPane code too (but I haven't looked and from a user's perspective, what you've done works fine). > > > > > On Tue, Nov 27, 2012 at 5:16 PM, Tom Eugelink > wrote: > > On 2012-11-27 01:51, Richard Bair wrote: > > But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. > > Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? > > > I don't know. This is the first time I've heard of FXML builders, otherwise I would have used them for MigPane. I did not find anything on the google, do you have a reference to some documentation or example? > > Tom > > From daniel.fuchs at oracle.com Tue Nov 27 01:29:39 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 27 Nov 2012 10:29:39 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: Message-ID: <50B48803.3010104@oracle.com> On 11/27/12 4:45 AM, openjfx-dev-request at openjdk.java.net wrote: > Message: 1 > Date: Mon, 26 Nov 2012 16:51:16 -0800 > From: Richard Bair > Subject: Re: Extending Builders: Layout Builders > To: Tom Eugelink > Cc:openjfx-dev at openjdk.java.net > Message-ID: > Content-Type: text/plain; charset=iso-8859-1 > >> > But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. > Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? > > Richard Hi, It is important for tools like SceneBuilder to be able to introspect builders, one way or another. At this time for every custom builder we need to add special code in SceneBuilder. The JavaFX generated builders can - until now - be introspected and so SceneBuilder can support them generically through introspection. Keep in mind that not all bean properties will be present in FXML - but all will need to be present in the SceneBuilder's Inspector. When a property is dynamically set by the user in the inspector, then SceneBuilder needs to emulate what the FXMLLoader would have done if it had encountered this property in FXML (this is that - or modify then reload the whole FXML). If the FXMLLoader uses custom builders whose behavior is opaque then there is no way to know what changing a property will do on the target object. Sometimes reloading the whole FXML is the only thing that SB will be able to do, for instance - if SB supports modifying some constructor property from the Inspector. But for this to happen it means that SB would first need to know that it is a constructor property - and not a simple read-write property. cheers, -- daniel From richard.bair at oracle.com Tue Nov 27 07:12:32 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 27 Nov 2012 07:12:32 -0800 Subject: [Review request] TreeTableView In-Reply-To: <50B41523.40206@oracle.com> References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> <50B41143.30504@oracle.com> <50B41523.40206@oracle.com> Message-ID: <1A44E4A1-CBCB-41EF-8374-328A225D6EE8@oracle.com> Is this part of existing API? On Nov 26, 2012, at 5:19 PM, Jonathan Giles wrote: > This appears to be an unfortunate and unintentional historical oversight. I have no desire for it to be Double, and could quite easily use double instead. Because of this, the meaning of null is undefined, but should probably mean 0.0. > > -- Jonathan > > On 27/11/2012 2:14 p.m., Richard Bair wrote: >> Why does ResizeFeaturesBase getDelta return a Double instead of a double? What does the "null" value mean in this context? >> >> On Nov 26, 2012, at 5:02 PM, Jonathan Giles wrote: >> >>> The Javadoc documentation has been attached to the Jira issue here: >>> >>> http://javafx-jira.kenai.com/browse/RT-17288 >>> >>> -- Jonathan > From hang.vo at oracle.com Tue Nov 27 07:32:10 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 27 Nov 2012 15:32:10 +0000 Subject: hg: openjfx/8/graphics/rt: TransformChangedEvent made final to be consistent with other events. Message-ID: <20121127153216.2394347B46@hg.openjdk.java.net> Changeset: 7a82d94e9019 Author: Pavel Safrata Date: 2012-11-27 16:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a82d94e9019 TransformChangedEvent made final to be consistent with other events. ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java From jonathan.giles at oracle.com Tue Nov 27 09:33:03 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 28 Nov 2012 06:33:03 +1300 Subject: [Review request] TreeTableView In-Reply-To: <1A44E4A1-CBCB-41EF-8374-328A225D6EE8@oracle.com> References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> <50B41143.30504@oracle.com> <50B41523.40206@oracle.com> <1A44E4A1-CBCB-41EF-8374-328A225D6EE8@oracle.com> Message-ID: <23221300-C1B1-4D18-8E0C-57E6EE61D6C3@oracle.com> Yes, it appears so. -- Jonathan On 28/11/2012, at 4:12 AM, Richard Bair wrote: > Is this part of existing API? > > On Nov 26, 2012, at 5:19 PM, Jonathan Giles wrote: > >> This appears to be an unfortunate and unintentional historical oversight. I have no desire for it to be Double, and could quite easily use double instead. Because of this, the meaning of null is undefined, but should probably mean 0.0. >> >> -- Jonathan >> >> On 27/11/2012 2:14 p.m., Richard Bair wrote: >>> Why does ResizeFeaturesBase getDelta return a Double instead of a double? What does the "null" value mean in this context? >>> >>> On Nov 26, 2012, at 5:02 PM, Jonathan Giles wrote: >>> >>>> The Javadoc documentation has been attached to the Jira issue here: >>>> >>>> http://javafx-jira.kenai.com/browse/RT-17288 >>>> >>>> -- Jonathan >> > From hang.vo at oracle.com Tue Nov 27 10:47:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 27 Nov 2012 18:47:50 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121127184757.CEF3D47B4C@hg.openjdk.java.net> Changeset: 71a6192f9af2 Author: David Grieve Date: 2012-11-27 12:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/71a6192f9af2 RT-26525: check for null displayNode in ColorPickerSkin colorLabelVisible property invalidated method ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 60400c9e4ce7 Author: David Grieve Date: 2012-11-27 13:01 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/60400c9e4ce7 [TEST-ONLY] Ignore test in StyleablePropertyTest that fails with ArrayIndexOutOfBounds. A fix for the exception exists in another scrum, so this test should be restored after integration. ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java From hang.vo at oracle.com Tue Nov 27 11:03:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 27 Nov 2012 19:03:47 +0000 Subject: hg: openjfx/8/graphics/rt: 14 new changesets Message-ID: <20121127190407.0F58C47B4D@hg.openjdk.java.net> Changeset: a7ce5f766cf4 Author: David Grieve Date: 2012-11-20 13:55 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a7ce5f766cf4 RT-26326: distance to look for font styles was zero if no shorthand was found. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 686b52a44cc4 Author: David Grieve Date: 2012-11-21 09:22 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/686b52a44cc4 [TEST-ONLY] ignore failing test to get build back on track ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java Changeset: ececf104ffcc Author: David Grieve Date: 2012-11-21 11:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ececf104ffcc branch merge - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project Changeset: acd1cfc745ee Author: "Jasper Potts" Date: 2012-11-21 12:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/acd1cfc745ee Fix RT-25325: Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.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/skin/AccordionSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/DoubleField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/InputField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Button.java ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java ! javafx-ui-controls/src/javafx/scene/control/ChoiceBox.java ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PasswordField.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitMenuButton.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableRow.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 156774e6fa98 Author: mickf Date: 2012-11-26 14:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/156774e6fa98 RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input ! javafx-ui-common/src/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TitledPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ToolBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusListBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusPopupBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java Changeset: 8b2acf78b060 Author: "Jasper Potts" Date: 2012-11-26 10:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8b2acf78b060 Fix for control skin needing two pulses after default skin change. ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 1956221ada12 Author: "Jasper Potts" Date: 2012-11-26 10:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1956221ada12 Fix for control skin needing two pulses after default skin change. ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 4e5a8c827dc4 Author: leifs Date: 2012-11-26 12:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4e5a8c827dc4 RT-24228: Add RTL support to Scrollbar / ScrollPane ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: a90b954395d7 Author: Paru Somashekar Date: 2012-11-26 12:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a90b954395d7 fix RT-26110 LineChart removes existing styles from custom symbols ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java Changeset: 769200bca5be Author: "Jasper Potts" Date: 2012-11-26 19:06 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/769200bca5be Fix by David for StyleManager to make user agent stylesheet changes clear all caches and do complete refresh. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 5d89eacf62cc Author: "Jasper Potts" Date: 2012-11-26 19:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5d89eacf62cc Added way to override a nodes pseudo class state for testing and theme design. It is disabled by default and can be enabled by -Djavafx.pseudoClassOverrideEnabled=true that was done to minimize any performance impact. Once that is enabled you can do myButton.getProperties().put("javafx.scene.Node.pseudoClassOverride", "hover"); to make it look in the hover state. ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 71a6192f9af2 Author: David Grieve Date: 2012-11-27 12:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/71a6192f9af2 RT-26525: check for null displayNode in ColorPickerSkin colorLabelVisible property invalidated method ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 60400c9e4ce7 Author: David Grieve Date: 2012-11-27 13:01 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/60400c9e4ce7 [TEST-ONLY] Ignore test in StyleablePropertyTest that fails with ArrayIndexOutOfBounds. A fix for the exception exists in another scrum, so this test should be restored after integration. ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java Changeset: e732d95172cf Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-27 10:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e732d95172cf Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java From zonski at gmail.com Tue Nov 27 11:49:17 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 28 Nov 2012 06:49:17 +1100 Subject: [Review request] TreeTableView In-Reply-To: <50B3EB05.6000406@oracle.com> References: <50B3EB05.6000406@oracle.com> Message-ID: <696269E8-EB6D-47EF-AAC8-054FA5916861@gmail.com> Consistently awesome work Jonathan. I haven't had a chance to dig into all the finer details of this but on the surface it looks fantastic. One very small thing for me would be the ability to disable scrolling? I tend to mimic the web style ui where there is one big scroll bar for the whole page. The fact that I couldn't turn off scrolling on lists and tables meant I often couldn't use these cool controls in my app and had to roll my own crude ones. Probably lowish on the list though. On 27/11/2012, at 9:19 AM, Jonathan Giles wrote: > Hi all, > > I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: > > https://wikis.oracle.com/display/OpenJDK/TreeTableView > > This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. > > To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: > > http://javafx-jira.kenai.com/browse/RT-17288 > > The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. > > I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. > > Thanks! > -- Jonathan From jonathan.giles at oracle.com Tue Nov 27 12:01:47 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 28 Nov 2012 09:01:47 +1300 Subject: [Review request] TreeTableView In-Reply-To: <696269E8-EB6D-47EF-AAC8-054FA5916861@gmail.com> References: <50B3EB05.6000406@oracle.com> <696269E8-EB6D-47EF-AAC8-054FA5916861@gmail.com> Message-ID: <50B51C2B.2040607@oracle.com> Thanks. Regarding disabling scrolling: it sounds like a reasonable request, and I'm not sure that there is a jira feature / tweak request logged yet. It would be great if you might consider creating one. -- Jonathan On 28/11/2012 8:49 a.m., Daniel Zwolenski wrote: > Consistently awesome work Jonathan. > > I haven't had a chance to dig into all the finer details of this but on the surface it looks fantastic. > > One very small thing for me would be the ability to disable scrolling? I tend to mimic the web style ui where there is one big scroll bar for the whole page. The fact that I couldn't turn off scrolling on lists and tables meant I often couldn't use these cool controls in my app and had to roll my own crude ones. Probably lowish on the list though. > > > On 27/11/2012, at 9:19 AM, Jonathan Giles wrote: > >> Hi all, >> >> I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: >> >> https://wikis.oracle.com/display/OpenJDK/TreeTableView >> >> This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. >> >> To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: >> >> http://javafx-jira.kenai.com/browse/RT-17288 >> >> The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. >> >> I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. >> >> Thanks! >> -- Jonathan From John_Smith at symantec.com Tue Nov 27 13:28:26 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 27 Nov 2012 13:28:26 -0800 Subject: Extending Builders: Layout Builders In-Reply-To: <50B48803.3010104@oracle.com> References: <50B48803.3010104@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> It seems odd to me that Builders and FXML are connected - from a Builder API or FXML user point of view they seem like such different things. I don't really know how this stuff works, so I'm going to do some speculation in this email, please correct me if I'm wrong. I knew that the FXML implementation was doing some introspection to determine property names and types, but I thought it was on the public control or layout API (e.g. HBox or Button) and not the Builder code (e.g. HBoxBuilder and ButtonBuilder). I guess that's not true and I didn't understand that relationship properly - thus Richard's comments around not polluting the Java API to support FXML explain part of the reason the FXML implementation works as it does. I'm guessing for JavaFX, with respect to visual tools like SceneBuilder, Builders are currently functioning like BeanInfo http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/org.eclipse.ve.doc/topics/cve_beaninfo.html; i.e. providing the metadata the visual tools require to do their job. I guess the connection between Builders and FXML is more an implementation detail than anything a typical JavaFX programmer using the Builder API or FXML would ever worry about? However, people writing libraries which include new controls and layout managers need to understand this connection, because they need to create compatible Builders for their controls and layouts? Currently, the safest way to do this would be use the JavaFX generated builders so that the new control would be compatible with an off the shelf SceneBuilder which did not include custom code? As a side product of the current congruence between FXML and Builders, does it mean that a tool like SceneBuilder could (without an inordinate amount of work) be made to work with generated Java Builder code rather than FXML files? -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Fuchs Sent: Tuesday, November 27, 2012 1:30 AM To: openjfx-dev at openjdk.java.net Subject: Re: Extending Builders: Layout Builders On 11/27/12 4:45 AM, openjfx-dev-request at openjdk.java.net wrote: > Message: 1 > Date: Mon, 26 Nov 2012 16:51:16 -0800 > From: Richard Bair > Subject: Re: Extending Builders: Layout Builders > To: Tom Eugelink > Cc:openjfx-dev at openjdk.java.net > Message-ID: > Content-Type: text/plain; charset=iso-8859-1 > >> > But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. > Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? > > Richard Hi, It is important for tools like SceneBuilder to be able to introspect builders, one way or another. At this time for every custom builder we need to add special code in SceneBuilder. The JavaFX generated builders can - until now - be introspected and so SceneBuilder can support them generically through introspection. Keep in mind that not all bean properties will be present in FXML - but all will need to be present in the SceneBuilder's Inspector. When a property is dynamically set by the user in the inspector, then SceneBuilder needs to emulate what the FXMLLoader would have done if it had encountered this property in FXML (this is that - or modify then reload the whole FXML). If the FXMLLoader uses custom builders whose behavior is opaque then there is no way to know what changing a property will do on the target object. Sometimes reloading the whole FXML is the only thing that SB will be able to do, for instance - if SB supports modifying some constructor property from the Inspector. But for this to happen it means that SB would first need to know that it is a constructor property - and not a simple read-write property. cheers, -- daniel From hendrik.ebbers at me.com Tue Nov 27 13:38:37 2012 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Tue, 27 Nov 2012 22:38:37 +0100 Subject: [Review request] TreeTableView In-Reply-To: <50B51C2B.2040607@oracle.com> References: <50B3EB05.6000406@oracle.com> <696269E8-EB6D-47EF-AAC8-054FA5916861@gmail.com> <50B51C2B.2040607@oracle.com> Message-ID: Hi, I will vote for that issue :) It would be a useful feature if the scrollbar is deactivatable (visible = false & all event handling is deactivated). Then you can use your own scrollbar or control to edit the viewport of the list or table. -Hendrik Am 27.11.2012 um 21:01 schrieb Jonathan Giles : > Thanks. > > Regarding disabling scrolling: it sounds like a reasonable request, and I'm not sure that there is a jira feature / tweak request logged yet. It would be great if you might consider creating one. > > -- Jonathan > > On 28/11/2012 8:49 a.m., Daniel Zwolenski wrote: >> Consistently awesome work Jonathan. >> >> I haven't had a chance to dig into all the finer details of this but on the surface it looks fantastic. >> >> One very small thing for me would be the ability to disable scrolling? I tend to mimic the web style ui where there is one big scroll bar for the whole page. The fact that I couldn't turn off scrolling on lists and tables meant I often couldn't use these cool controls in my app and had to roll my own crude ones. Probably lowish on the list though. >> >> >> On 27/11/2012, at 9:19 AM, Jonathan Giles wrote: >> >>> Hi all, >>> >>> I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: >>> >>> https://wikis.oracle.com/display/OpenJDK/TreeTableView >>> >>> This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. >>> >>> To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: >>> >>> http://javafx-jira.kenai.com/browse/RT-17288 >>> >>> The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. >>> >>> I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. >>> >>> Thanks! >>> -- Jonathan > From tom.schindl at bestsolution.at Tue Nov 27 13:49:20 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 27 Nov 2012 22:49:20 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <50B48803.3010104@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <50B53560.2020202@bestsolution.at> FXML only depends on builders when the object it creates has no no-arg constructor or one wants to set readonly attributes who can only be set when the object is constructed. Tom Am 27.11.12 22:28, schrieb John Smith: > It seems odd to me that Builders and FXML are connected - from a Builder API or FXML user point of view they seem like such different things. > I don't really know how this stuff works, so I'm going to do some speculation in this email, please correct me if I'm wrong. > > I knew that the FXML implementation was doing some introspection to determine property names and types, but I thought it was on the public control or layout API (e.g. HBox or Button) and not the Builder code (e.g. HBoxBuilder and ButtonBuilder). I guess that's not true and I didn't understand that relationship properly - thus Richard's comments around not polluting the Java API to support FXML explain part of the reason the FXML implementation works as it does. > > I'm guessing for JavaFX, with respect to visual tools like SceneBuilder, Builders are currently functioning like BeanInfo http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/org.eclipse.ve.doc/topics/cve_beaninfo.html; i.e. providing the metadata the visual tools require to do their job. > > I guess the connection between Builders and FXML is more an implementation detail than anything a typical JavaFX programmer using the Builder API or FXML would ever worry about? > > However, people writing libraries which include new controls and layout managers need to understand this connection, because they need to create compatible Builders for their controls and layouts? Currently, the safest way to do this would be use the JavaFX generated builders so that the new control would be compatible with an off the shelf SceneBuilder which did not include custom code? > > As a side product of the current congruence between FXML and Builders, does it mean that a tool like SceneBuilder could (without an inordinate amount of work) be made to work with generated Java Builder code rather than FXML files? > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Fuchs > Sent: Tuesday, November 27, 2012 1:30 AM > To: openjfx-dev at openjdk.java.net > Subject: Re: Extending Builders: Layout Builders > > On 11/27/12 4:45 AM, openjfx-dev-request at openjdk.java.net wrote: >> Message: 1 >> Date: Mon, 26 Nov 2012 16:51:16 -0800 >> From: Richard Bair >> Subject: Re: Extending Builders: Layout Builders >> To: Tom Eugelink >> Cc:openjfx-dev at openjdk.java.net >> Message-ID: >> Content-Type: text/plain; charset=iso-8859-1 >> >>>> But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. >> Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? >> >> Richard > Hi, > > It is important for tools like SceneBuilder to be able to introspect builders, one way or another. > At this time for every custom builder we need to add special code in SceneBuilder. The JavaFX generated builders can - until now - be introspected and so SceneBuilder can support them generically through introspection. > Keep in mind that not all bean properties will be present in FXML - but all will need to be present in the SceneBuilder's Inspector. When a property is dynamically set by the user in the inspector, then SceneBuilder needs to emulate what the FXMLLoader would have done if it had encountered this property in FXML (this is that - or modify then reload the whole FXML). > If the FXMLLoader uses custom builders whose behavior is opaque then there is no way to know what changing a property will do on the target object. Sometimes reloading the whole FXML is the only thing that SB will be able to do, for instance - if SB supports modifying some constructor property from the Inspector. But for this to happen it means that SB would first need to know that it is a constructor property - and not a simple read-write property. > > cheers, > > -- daniel > -- 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 Tue Nov 27 14:05:46 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 28 Nov 2012 09:05:46 +1100 Subject: Extending Builders: Layout Builders In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <50B48803.3010104@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: The following is based on my experience using FXML. Someone from Oracle might know better. Is Greg still working on this - I have a vague memory of an email saying he wasn't? > It seems odd to me that Builders and FXML are connected - from a Builder API or FXML user point of view they seem like such different things. Loosely connected. If a builder is available FXML can use it, if not reflection straight onto the class. Optional for your own custom classes, most (all?) core jfx classes have builders. > I guess the connection between Builders and FXML is more an implementation detail than anything a typical JavaFX programmer using the Builder API or FXML would ever worry about? Yes, unless you want to use them to simplify your own class construction or you're looking for convenience methods to use in FXML that aren't on the regular control class. > However, people writing libraries which include new controls and layout managers need to understand this connection, because they need to create compatible Builders for their controls and layouts? Optional. But the docco is poor (and reads like a tech manual - I've always loved the docco on spring as a guide for doing it right. The docco on maven is a guide for doing it wrong). > Currently, the safest way to do this would be use the JavaFX generated builders so that the new control would be compatible with an off the shelf SceneBuilder which did not include custom code? Safest would be to just use your class and not use a builder, then the class is the meta data. I'm not too sure on how the builder is hooked into the FXML but I would have assumed reflection too. I would have thought the tools could just inspect the builder class to find methods on it but if not perhaps there is a need to allow builders to declare their meta data (eg annotations, javadoc tags or XML). FXML operates 'above' the control level so in general it doesn't have any special information that the builder tools wouldn't have. The only difference is FXML is grabbing the data whereas the builder tools want to list the options so there could be some gaps. > > As a side product of the current congruence between FXML and Builders, does it mean that a tool like SceneBuilder could (without an inordinate amount of work) be made to work with generated Java Builder code rather than FXML files? Interesting idea. You could certainly post process the FXML to do this. Probably pretty hard to go back the other way though once the file is edited. Groovy (as in the language) is something I've wondered about as an alternative to FXML. The desire to use XML was strongly biased by the popularity of HTML, ie make it on par in terms of skillset so HTML devs could switch. Doesn't necessarily make it the 'best' technology though and since FXML is a layer above we have the option to change (and I'll stop before I get fired up on CSS). If I wasn't working on messy deployment code for the foreseeable future I would much prefer to be working on an alternative to FXML that allows for templating and scripting (more like jsp). Maybe next year, when oracle release it jfx on mobile meaning I can actually get some paid jfx work ;) > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Fuchs > Sent: Tuesday, November 27, 2012 1:30 AM > To: openjfx-dev at openjdk.java.net > Subject: Re: Extending Builders: Layout Builders > > On 11/27/12 4:45 AM, openjfx-dev-request at openjdk.java.net wrote: >> Message: 1 >> Date: Mon, 26 Nov 2012 16:51:16 -0800 >> From: Richard Bair >> Subject: Re: Extending Builders: Layout Builders >> To: Tom Eugelink >> Cc:openjfx-dev at openjdk.java.net >> Message-ID: >> Content-Type: text/plain; charset=iso-8859-1 >> >>>> But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it. >> Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML? >> >> Richard > Hi, > > It is important for tools like SceneBuilder to be able to introspect builders, one way or another. > At this time for every custom builder we need to add special code in SceneBuilder. The JavaFX generated builders can - until now - be introspected and so SceneBuilder can support them generically through introspection. > Keep in mind that not all bean properties will be present in FXML - but all will need to be present in the SceneBuilder's Inspector. When a property is dynamically set by the user in the inspector, then SceneBuilder needs to emulate what the FXMLLoader would have done if it had encountered this property in FXML (this is that - or modify then reload the whole FXML). > If the FXMLLoader uses custom builders whose behavior is opaque then there is no way to know what changing a property will do on the target object. Sometimes reloading the whole FXML is the only thing that SB will be able to do, for instance - if SB supports modifying some constructor property from the Inspector. But for this to happen it means that SB would first need to know that it is a constructor property - and not a simple read-write property. > > cheers, > > -- daniel > From tom.schindl at bestsolution.at Tue Nov 27 14:15:04 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 27 Nov 2012 23:15:04 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: References: <50B48803.3010104@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <50B53B68.1040900@bestsolution.at> > I'm not too sure on how the builder is hooked into the FXML but I would have assumed reflection too. I would have thought the tools could just inspect the builder class to find methods on it but if not perhaps there is a need to allow builders to declare their meta data (eg annotations, javadoc tags or XML). > > FXML operates 'above' the control level so in general it doesn't have any special information that the builder tools wouldn't have. The only difference is FXML is grabbing the data whereas the builder tools want to list the options so there could be some gaps. The builders are constructed through JavaFXBuilderFactory and all the FXML stuff is already in the mercurial repo. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hendrik.ebbers at me.com Tue Nov 27 14:45:22 2012 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Tue, 27 Nov 2012 23:45:22 +0100 Subject: [Review request] TreeTableView In-Reply-To: <50B3EB05.6000406@oracle.com> References: <50B3EB05.6000406@oracle.com> Message-ID: <82ABD9D0-357C-4CB7-817C-7EBD64CD1491@me.com> Hi, I just tried the tree and table API in some demos to learn JavaFX. I like both controls and think you made a great job of it. After reading your documentation and the javadocs I think that the TreeTableView is a good mixture of this two APIs. I think two interfaces "TreeBasedControl" (implemented by TreeView and TreeTableView) and "TableBasedControl" (implemented by TableView and TreeTableView) could be useful. Methodes like "setRoot(..)" then defined in the interface. But this are only my two cents. -Hendrik Am 26.11.2012 um 23:19 schrieb Jonathan Giles : > Hi all, > > I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: > > https://wikis.oracle.com/display/OpenJDK/TreeTableView > > This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. > > To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: > > http://javafx-jira.kenai.com/browse/RT-17288 > > The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. > > I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. > > Thanks! > -- Jonathan From jonathan.giles at oracle.com Tue Nov 27 14:56:48 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 28 Nov 2012 11:56:48 +1300 Subject: [Review request] TreeTableView In-Reply-To: <82ABD9D0-357C-4CB7-817C-7EBD64CD1491@me.com> References: <50B3EB05.6000406@oracle.com> <82ABD9D0-357C-4CB7-817C-7EBD64CD1491@me.com> Message-ID: <50B54530.8060309@oracle.com> As discussed previously (and recently) on this list, we prefer to not introduce interfaces whenever possible due to their brittleness and lowest-common denominator requirements. I've introduced a fair few abstract base classes (more than I would like, honestly), and am loath to introduce anything else without a really strong argument. -- Jonathan On Wednesday, 28 November 2012 11:45:22 a.m., Hendrik Ebbers wrote: > Hi, > > I just tried the tree and table API in some demos to learn JavaFX. I like both controls and think you made a great job of it. After reading your documentation and the javadocs I think that the TreeTableView is a good mixture of this two APIs. I think two interfaces "TreeBasedControl" (implemented by TreeView and TreeTableView) and "TableBasedControl" (implemented by TableView and TreeTableView) could be useful. Methodes like "setRoot(..)" then defined in the interface. But this are only my two cents. > > -Hendrik > > Am 26.11.2012 um 23:19 schrieb Jonathan Giles : > >> Hi all, >> >> I'm planning to relocate the TreeTableView control I've been developing in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 controls repo. Before that happens there is a gate here that we need to go through related to having an early API review. To make understanding the control easier, I've written up an overview of the TreeTableView control here: >> >> https://wikis.oracle.com/display/OpenJDK/TreeTableView >> >> This documentation covers the core concepts of the API, it includes examples of how the API is used, and finally I've put up a brief paragraph detailing the implementation (although I may add more detail in here as time passes and questions come in). My colleage Jindra Dinga, who is responsible for the UX design of the TreeTableView control, has posted his UX documentation for it at the same link above, so hopefully this too will prove useful for people to fully understand precisely what a TreeTableView is, and is not. >> >> To get a slightly more in-depth understanding of the path TreeTableView has taken to where it is today, you may also be interested in the following Jira issue, and perhaps you may choose to follow it and / or offer feedback directly into the Jira issue: >> >> http://javafx-jira.kenai.com/browse/RT-17288 >> >> The TreeTableView control that is in the sandbox repo is far superior to the prototype that is in the 8.0 controls repo (in the com.preview.* package). It is my intention to completely remove the old TreeTableView control and replace it with the new implementation, and even go so far as to place it in the correct packages so that I can make use of package protected API. However, it is important to note that the API _is not final_ - I'm only going through the first gate here to get the code into the correct repo and packages - there will be further discussion in the future regarding API design, missing / incorrect functionality, and straight out bugs. >> >> I hope that you are all excited about getting a TreeTableView control into JavaFX 8.0, and I hope you can all help guide the control towards an API that meets your requirements and use cases. I think what we have now is good, but API design can not be done in a vacuum so I look forward to your feedback. I would recommend that discussion regarding moving TreeTableView into the official OpenJFX 8.0 controls repo take place here, and that discussion around API design and functionality be posted on the Jira issue linked above (rather than here), to try to prevent the amount of noise on this list. >> >> Thanks! >> -- Jonathan > From jonathan.giles at oracle.com Tue Nov 27 15:39:21 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 28 Nov 2012 12:39:21 +1300 Subject: [Review request] TreeTableView In-Reply-To: <50B3EB05.6000406@oracle.com> References: <50B3EB05.6000406@oracle.com> Message-ID: <50B54F29.7040300@oracle.com> I've updated the public API class list to include a few new classes I just created, namely cell factories for the TreeTableView. You can see the latest list here: https://wikis.oracle.com/display/OpenJDK/TreeTableView+API+Discussion -- Jonathan On 27/11/2012 11:19 a.m., Jonathan Giles wrote: > Hi all, > > I'm planning to relocate the TreeTableView control I've been > developing in the OpenJFX 8.0 controls sandbox over into the proper > OpenJFX 8.0 controls repo. Before that happens there is a gate here > that we need to go through related to having an early API review. To > make understanding the control easier, I've written up an overview of > the TreeTableView control here: > > https://wikis.oracle.com/display/OpenJDK/TreeTableView > > This documentation covers the core concepts of the API, it includes > examples of how the API is used, and finally I've put up a brief > paragraph detailing the implementation (although I may add more detail > in here as time passes and questions come in). My colleage Jindra > Dinga, who is responsible for the UX design of the TreeTableView > control, has posted his UX documentation for it at the same link > above, so hopefully this too will prove useful for people to fully > understand precisely what a TreeTableView is, and is not. > > To get a slightly more in-depth understanding of the path > TreeTableView has taken to where it is today, you may also be > interested in the following Jira issue, and perhaps you may choose to > follow it and / or offer feedback directly into the Jira issue: > > http://javafx-jira.kenai.com/browse/RT-17288 > > The TreeTableView control that is in the sandbox repo is far superior > to the prototype that is in the 8.0 controls repo (in the > com.preview.* package). It is my intention to completely remove the > old TreeTableView control and replace it with the new implementation, > and even go so far as to place it in the correct packages so that I > can make use of package protected API. However, it is important to > note that the API _is not final_ - I'm only going through the first > gate here to get the code into the correct repo and packages - there > will be further discussion in the future regarding API design, missing > / incorrect functionality, and straight out bugs. > > I hope that you are all excited about getting a TreeTableView control > into JavaFX 8.0, and I hope you can all help guide the control towards > an API that meets your requirements and use cases. I think what we > have now is good, but API design can not be done in a vacuum so I look > forward to your feedback. I would recommend that discussion regarding > moving TreeTableView into the official OpenJFX 8.0 controls repo take > place here, and that discussion around API design and functionality be > posted on the Jira issue linked above (rather than here), to try to > prevent the amount of noise on this list. > > Thanks! > -- Jonathan From hang.vo at oracle.com Tue Nov 27 15:47:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 27 Nov 2012 23:47:46 +0000 Subject: hg: openjfx/8/graphics/rt: RT-23492: Text method(s) accept null, app blows up later Message-ID: <20121127234750.87B8747B56@hg.openjdk.java.net> Changeset: 54d464a6ade7 Author: Felipe Heidrich Date: 2012-11-27 15:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/54d464a6ade7 RT-23492: Text method(s) accept null, app blows up later ! javafx-ui-common/src/javafx/scene/text/Text.java From hang.vo at oracle.com Tue Nov 27 16:17:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 00:17:47 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121128001756.8607647B57@hg.openjdk.java.net> Changeset: dd45fc2ac4ba Author: "Jasper Potts" Date: 2012-11-27 16:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dd45fc2ac4ba Fixed RT-19713 & RT-26435 Add API to JavaFX to allow for setting preferred user agent stylesheet. Also add system property for setting the user agent styles. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/application/Application.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java - javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: 5d5dddfa1a60 Author: "Jasper Potts" Date: 2012-11-27 16:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5d5dddfa1a60 Added new experimental application as a playground for prototyping a new look and feel for JavaFX + apps/experiments/Modena/build.xml + apps/experiments/Modena/manifest.mf + apps/experiments/Modena/nbproject/build-impl.xml + apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties + apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties + apps/experiments/Modena/nbproject/genfiles.properties + apps/experiments/Modena/nbproject/jfx-impl.xml + apps/experiments/Modena/nbproject/jfx-impl_backup.xml + apps/experiments/Modena/nbproject/project.properties + apps/experiments/Modena/nbproject/project.xml + apps/experiments/Modena/src/modena/Modena.css + apps/experiments/Modena/src/modena/Modena.java + apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/TestApp.css From tbee at tbee.org Tue Nov 27 22:20:38 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 28 Nov 2012 07:20:38 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B53B68.1040900@bestsolution.at> References: <50B48803.3010104@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D2216088E0C22@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <50B53B68.1040900@bestsolution.at> Message-ID: <50B5AD36.1010301@tbee.org> Interesting discussions on FXML and SceneBuilder. Let me put two questions to the SceneBuilder guys: - Does the current introspection approach suffice or would there be benefits in adding custom metadata? - How would scene builder cope if a piece of code would on the fly insert a constraint tag (so without an associated JFX node) into the FXML? I am assuming it would just map the constaint tag onto the class and the values onto the setters & getters / properties. Tom From hang.vo at oracle.com Wed Nov 28 01:33:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 09:33:18 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121128093323.CE1DB47B6D@hg.openjdk.java.net> Changeset: 573f5535e6a1 Author: Martin Sladecek Date: 2012-11-28 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/573f5535e6a1 RT-25776 Animation. Cycles are not equivalent in SequentialTransition ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java ! javafx-ui-common/test/unit/javafx/animation/TransitionTest.java Changeset: fc5cf98c8d33 Author: Martin Sladecek Date: 2012-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc5cf98c8d33 merge From anthony.petrov at oracle.com Wed Nov 28 02:05:33 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 28 Nov 2012 14:05:33 +0400 Subject: JDK 7 & Retina: How to prevent HiDPI scaling? In-Reply-To: References: <97D0B63A-FDDF-4A06-B615-B21CF06DFA5B@oracle.com> <90FF3327-69D5-4BF6-9B35-734109250E7F@gmail.com> <877CD9EB-5E4A-4F2E-9005-D871901677D8@oracle.com> <81356080-7264-476D-8EF8-6601235F38FD@cinderella.de> <5C570BC7-8373-4F4D-A848-9A0AC6093B9D@apple.com> <449E0513-653F-4503-9EFB-BB7EF9979FB3@cinderella.de> <3C4B9260-2FF4-457F-ADAE-35E5C5471030@cinderella.de> Message-ID: <50B5E1ED.7050707@oracle.com> (I'm CC'ing openjfx-dev@ since this is a JavaFX topic) I think you might want to check out the following issue: http://javafx-jira.kenai.com/browse/RT-24009 Currently JavaFX isn't HiDPI-aware, and as such this is impossible to turn automatic scaling off (unless there's a hack in OS X for this.) PS. If you're interested in support for this feature in JDK as well, here's a bug to watch: http://bugs.sun.com/view_bug.do?bug_id=8000629 -- best regards, Anthony On 11/28/2012 11:36 AM, Tobias Bley wrote: > Hi (Mike), > > is it possible to tell Cocoa(?) not to scale up everthing on a Retina display? I would like to try to scale the text in JavaFX2 to factor 2.0 but currently the text size doubles ;) So how can I prevent the automatic upscaling? > > Best regards, > Tobi > From hang.vo at oracle.com Wed Nov 28 03:48:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 11:48:01 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121128114809.2BE9647B71@hg.openjdk.java.net> Changeset: 3a6dcc5adb79 Author: Martin Sladecek Date: 2012-11-28 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3a6dcc5adb79 Fixed test failure ! javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: b2e8a63feae9 Author: Martin Sladecek Date: 2012-11-28 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b2e8a63feae9 merge From zonski at gmail.com Wed Nov 28 04:48:58 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 28 Nov 2012 23:48:58 +1100 Subject: JavaFX Maven Plugin In-Reply-To: References: <50839AED.3060801@tbee.org> <8812D06B-F427-4184-8ABA-19776F59CFE4@oracle.com> <1A9E13AD-8B9D-47D4-8C04-93784CCB4816@oracle.com> <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> <50A3A0C7.1050704@nosphere.org> <4A963F55-D096-4873-8B6A-15489CBC0DEB@oracle.com> Message-ID: I have the Maven plugin assembling an 'exploded' distro for windows (what I think the JFX tools calls an 'image') as the pre-step to building an MSI with WiX. My exploded bundle looks like: .\WinLauncher.exe (pulled from %java_home%/ant-javafx.jar at build time) .\app (contains all my jar files) .\app\package.cfg (text file with a "mainjar" referencing my main executable jar in app dir) .\runtime\jre (full copy of %JAVA_HOME% at build time) When I run WinLauncher.exe I get a dialog saying "no main class" and the title of the dialog is "Expected to find com.javafx.main.MainClass". So I'm guessing the launcher is hardcoded to look for the JavaFX pre-launcher and not the one specified in the manifest of the main executable JAR? I was hoping to avoid the pre-launcher in my assembly (just adds more mess). I'm assuming there's no way to make the Launcher just run my JAR without the pre-launcher, nice and simple like? Any reason why the pre-launcher is needed at all if the JRE is co-bundled. I thought the job of the pre-launcher was to make sure you had the right JRE and JFX, etc, which seems somewhat unnecessary when you have a co-bundled JRE. Does it do anything else? Another question, does the native bundle have to work off a single "uber-jar" or can I have all my individual JARs sitting in the "app" directory outside of my main app jar? I very much hope it is the latter. Where does the app get it's classpath from (unfortunately no decompiler for WinLauncher.exe so I'm flying blind on some of this). And since I'm asking, the JFX packager looks to filter files when it copies the JRE into the bundle (I think that's what the "Rule" thing is doing anyway). Is this just to save space or for some other reason? I can't see any real pattern to the choice of files being excluded, is there one? I can probably work all of the above out through continual trial and error, etc, but if anyone has time to throw some insight my way I'd appreciate it. Thanks, Dan On Tue, Nov 27, 2012 at 9:33 AM, Daniel Zwolenski wrote: > Ignore that bit about needing it open sourced to get the launch exe out - > I was being stupid, I should be able to extract it from the JDK directly, > dodging the legal issues. I will need the launcher code for AU though > eventually and it would be nice to be able to read through the code without > using a decompiler. > > I think I can do nearly everything I need to by myself (just going to take > a heap of work) except for one thing that would open up a lot more options: > > If the JRE for each platform was available as a zip for download from > somewhere public (i.e. that an automated program could download - none of > that annoying "accept the licence" thing) then this opens the road to > cross-platform native distros and simpler builds. It doesn't have to be in > a Maven repo, it can still have the same licencing restrictions, it just > needs to be publicly available without stop-gates in the way (e.g. a simple > download from java.com). > > Technically this should be ridiculously easy and I think it would benefit > the regular JFX deployment tools a lot too. I could actually create the > zips but I'm not allowed to "distribute" the JRE, I can only "include" it > in my app. > > The easiest way around this is for Oracle to be the distributor (as it is > now) but just provide (a) the download as a zip file for each platform and > (b) a way to download these zips without having to tick the "I accept the > licence" thing on the web page. > > I know the second part will be the tricky one (kill all the lawyers) but > if someone from Oracle (e.g. the JavaFX packaging team) could do some > pushing, maybe it could happen sometime in the next year or two? > > > > > > > On Mon, Nov 26, 2012 at 8:13 AM, Jim Weaver wrote: > >> Daniel, >> >> +1 to Scott's sentiments about being glad that you're contributing to the >> vitally important JavaFX deployment effort! >> >> Thanks, >> Jim Weaver >> >> On Nov 25, 2012, at 2:25 PM, Scott Kovatch >> wrote: >> >> > On Nov 25, 2012, at 3:29 AM, Daniel Zwolenski wrote: >> > >> >> Hey guys, >> >> >> >> Is there any more news on the open sourcing of the packaging tools? >> It's >> >> been a "few days away" since October 27. >> >> >> >> What I'd really like to not have to rewrite are the native launcher >> >> executables that get bundled into the installers (i.e. the "exe" on >> >> windows). I can rip these out of the Java bundle for now to do my >> >> development but I won't be able to release my improved bundler until >> these >> >> bits are open sourced, giving me the legal all clear to include them >> in my >> >> plugin. >> >> >> >> Any chance I could get an actual timeframe on when the packaging tools >> are >> >> to be open sourced? >> > >> > I'm chugging along with this, but I was off last week due to the US >> Thanksgiving holiday. >> > >> > The code has been cleaned up (read: commented, TODO's removed/bugs >> created) and ready for review. There is some code we want to retire as part >> of this process, and that means modifying some makefiles and ensuring >> everything builds correctly in the closed repository, and then we can move >> it to the open rt project in OpenJFX and make sure it builds there. >> > >> > So, it's happening, but there were some changes in assumptions I have >> to work around. Releasing something that won't build isn't helpful. I'll >> have a better timeframe early this week. >> > >> >> I'm doing my best to contribute what I personally think is vitally >> >> important for JavaFX. In general I'm accepting of the fact that what >> I'm >> >> doing is not something Oracle sees as overly important and I'm on my >> own >> >> (it's been quite a liberating attitude to take to be honest). Open >> Sourcing >> >> the packaging tools however, was something you said you were going to >> do >> >> anyway and it would save me having to write a whole new native >> launcher for >> >> each platform. >> > >> > I think it's great that you're interested in working on this. >> Deployment is not a glamorous job but it needs to be done. Without it, the >> rest of JavaFX isn't as useful, IMO. >> > >> > What we want to do is have a core API that's as tool-ignorant as >> possible, and then let developers like you put the tool frameworks around >> it. Right now we're closely tied to ant, and I'd like to get away from that. >> > >> > -- Scott K. >> > >> > ------------------------ >> > Scott Kovatch >> > Oracle >> > Pleasanton, CA >> > >> > > From hang.vo at oracle.com Wed Nov 28 06:18:28 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 14:18:28 +0000 Subject: hg: openjfx/8/controls/rt: 9 new changesets Message-ID: <20121128141842.7E05C47B75@hg.openjdk.java.net> Changeset: 6fc99f747830 Author: flar Date: 2012-11-20 13:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6fc99f747830 Fix RT-25333: setPixels can ignore the x,y coordinates in the request ! javafx-ui-common/src/com/sun/javafx/image/ByteToBytePixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/ByteToIntPixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/IntToBytePixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/IntToIntPixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/PixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToByteConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToIntConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToByteConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToIntConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/image/ConverterTest.java Changeset: 45aeaba1af4a Author: Felipe Heidrich Date: 2012-11-20 15:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/45aeaba1af4a RT-17392: Multi-line, multi-style, rich text support ! javafx-ui-common/src/javafx/scene/text/Text.java + javafx-ui-common/src/javafx/scene/text/TextFlow.java Changeset: cacf5b967ed3 Author: Pavel Safrata Date: 2012-11-21 10:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cacf5b967ed3 RT-26391: optimized local-to-scene transform property. ! javafx-ui-common/src/com/sun/javafx/scene/transform/TransformUtils.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/transform/Transform.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/transform/TransformUtilsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/TransformHelper.java ! javafx-ui-common/test/unit/javafx/scene/Node_LocalToParentTransform_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_LocalToSceneTransform_Test.java ! javafx-ui-common/test/unit/javafx/scene/transform/AffineOperationsTest.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformOperationsTest.java Changeset: 4e7d364feafc Author: Martin Sladecek Date: 2012-11-23 14:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4e7d364feafc impl_ method cleanup in Animation. ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java Changeset: 7a36755b17b5 Author: Milan Kubec Date: 2012-11-26 16:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7a36755b17b5 fix of classpath related to move of the project from rt-closed repo to rt repo ! javafx-fxml/nbproject/project.xml Changeset: fe4bf1068eda Author: Yao Wang Date: 2012-11-26 13:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fe4bf1068eda RT-24357 Text class change ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 7a82d94e9019 Author: Pavel Safrata Date: 2012-11-27 16:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7a82d94e9019 TransformChangedEvent made final to be consistent with other events. ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java Changeset: e732d95172cf Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-27 10:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e732d95172cf Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: b4fe87e55747 Author: David Grieve Date: 2012-11-28 09:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b4fe87e55747 branch merge From hang.vo at oracle.com Wed Nov 28 06:33:17 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 14:33:17 +0000 Subject: hg: openjfx/8/graphics/rt: adding QA related assertions to documentation Message-ID: <20121128143319.6362247B76@hg.openjdk.java.net> Changeset: 42c3818c5c85 Author: Milan Kubec Date: 2012-11-28 15:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/42c3818c5c85 adding QA related assertions to documentation ! javafx-fxml/src/javafx/fxml/doc-files/introduction_to_fxml.html From eva.krejcirova at oracle.com Wed Nov 28 06:57:48 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 28 Nov 2012 15:57:48 +0100 Subject: Extending builders: PathBuilder In-Reply-To: <8F343DDF-FEE8-4BE5-BA8A-1561F3C167E9@oracle.com> References: <4FFDAD1C.2010501@oracle.com> <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> <50AD14D3.8090208@oracle.com> <8F343DDF-FEE8-4BE5-BA8A-1561F3C167E9@oracle.com> Message-ID: <50B6266C.1020105@oracle.com> On 22.11.2012 14:18, Richard Bair wrote: >>>> There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g. >>>> >>>> PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); >>>> or >>>> PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); >>>> >>>> There are several approaches for this : >>>> >>>> 1.) appending everything into one list so both of former examples return the same path. >>> This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed? >> What if somebody uses a single Group builder instance which is configured with common attributes and then used for building multiple Group-s each of them having different set of children. In that case I would expect children replacing and not adding to the existing list. > > Good argument. Ok, so are we back at option 4 then? That was following behavior: Calling elements() erases all previous calls to elements(), moveTo(), ... New methods moveTo, lineTo etc. will add the element even if there already are some elements added by elements() call previously, they will not erase anything. This will not break backwards compatibility and will be consistent with other builder methods and has clearly defined behavior. e.g. PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); will only contain ClosePath PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); will contain MoveTo, LineTo, ClosePath Eva From swpalmer at gmail.com Wed Nov 28 07:20:14 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 28 Nov 2012 10:20:14 -0500 Subject: Duplicate methods on internal classes Message-ID: I was poking around and just noticed the following: com.sun.javafx.PlatformUtil.isMac(); com.sun.javafx.PlatformUtil.isUnix(); com.sun.javafx.PlatformUtil.isWindows(); com.sun.javafx.Utils.isMac(); com.sun.javafx.Utils.isUnix(); com.sun.javafx.Utils.isWindows(); It seems the PlatformUtil class has more methods along the same lines. Should the Utils methods be removed? Is there a plan for any sort of public API along the same lines? This is the sort of code that everyone keeps re-writing. Scott P. From eva.krejcirova at oracle.com Wed Nov 28 07:27:13 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 28 Nov 2012 16:27:13 +0100 Subject: Extending builders In-Reply-To: <50AE3E5B.6010400@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> <50AE394A.4060703@oracle.com> <50AE3E5B.6010400@oracle.com> Message-ID: <50B62D51.6020601@oracle.com> There will certainly be methods with one argument, so this means that there must be a way for SceneBuilder and FXML to tell these methods apart from the property methods. We can annotate the convenience methods by special annotation (e.g. BuilderConvenienceMethod). Or we could add an annotation (e.g. BuilderProperty) to the methods which correspond to properties (= the methods which are currently in the builders). Eva On 22.11.2012 16:01, Daniel Fuchs wrote: > On 11/22/12 3:40 PM, Eva Krejcirova wrote: >> Hi, >> >> There is one more thing which needs to be sorted out before adding new >> methods to builders: >> SceneBuilder and FXML use builders to find names of properties of a >> class, so they need to have a way to differentiate between the new >> convenience methods and the methods which correspond to properties of a >> class. Daniel, is this still true? >> >> Last time we discussed this, Daniel suggested to annotate these new >> convenience methods. If we go this way, we need to create a new runtime >> annotation (and find a name for it :-) ) >> >> Eva > > Hi Eva, > > Yes this is still true. Note that SceneBuilder actually uses > builders only in special cases - for WebView - for instance - > because of the fake location attribute available on WebViewBuilder > only - and for any type which has no public constructors (e.g.: all > charts, Insets, etc...) > > However - SceneBuilder discovers whether there are constructor > properties by introspecting ClassX and ClassXBuilder and comparing > the results: it takes the name of all the single parameter > instance methods in ClassXBuilder which returns a builder, > remove the names of all writable (getter+setter) properties > found in ClassX, and what remain are assumed to be constructor > properties. > > As long as the convenience methods have more than 1 parameter > (varargs count for 1) then this logic should remain valid. > > The FXMLLoader's JavaFXBuilderFactory also introspects builders > in order to find out writable properties and type of properties, > so that's another place you will have to look at > (class JavaFXBuilderFactory.JavaFXBuilder). > > best regards, > > -- daniel > > > From hang.vo at oracle.com Wed Nov 28 08:03:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 16:03:24 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-23878: -fx-ellipsis-string doesn't apply after setStyle Message-ID: <20121128160327.3367547B79@hg.openjdk.java.net> Changeset: c578bb6b90f4 Author: leifs Date: 2012-11-28 07:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c578bb6b90f4 Fixed RT-23878: -fx-ellipsis-string doesn't apply after setStyle ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java From hang.vo at oracle.com Wed Nov 28 08:33:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 16:33:18 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121128163322.1A34647B86@hg.openjdk.java.net> Changeset: 1ea2d63fa876 Author: David Grieve Date: 2012-11-28 11:19 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1ea2d63fa876 RT-26554: if an inline style changes, clear the style cache so new styles will be recalculated. ! apps/experiments/Modena/src/modena/Modena.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/com/sun/javafx/scene/CSSFlags.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: b1f6d7efb9f2 Author: David Grieve Date: 2012-11-28 11:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b1f6d7efb9f2 branch merge From hang.vo at oracle.com Wed Nov 28 10:18:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 18:18:20 +0000 Subject: hg: openjfx/8/controls/rt: RT-26245: FXML-LoginDemo text field doesn't show characters Message-ID: <20121128181823.5E45C47B8E@hg.openjdk.java.net> Changeset: b354819486c6 Author: leifs Date: 2012-11-28 10:06 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b354819486c6 RT-26245: FXML-LoginDemo text field doesn't show characters ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java From hang.vo at oracle.com Wed Nov 28 11:17:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 28 Nov 2012 19:17:56 +0000 Subject: hg: openjfx/8/controls/rt: RT-26484: looping on invalidated method of fontProperty in Labeled caused indirectly by ObjectProperty having no check for equals. Override set method to check equals. Message-ID: <20121128191758.CA2E247B98@hg.openjdk.java.net> Changeset: 0ce17489970d Author: David Grieve Date: 2012-11-28 14:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0ce17489970d RT-26484: looping on invalidated method of fontProperty in Labeled caused indirectly by ObjectProperty having no check for equals. Override set method to check equals. ! javafx-ui-controls/src/javafx/scene/control/Labeled.java From hang.vo at oracle.com Wed Nov 28 17:03:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 29 Nov 2012 01:03:36 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26171: Add RTL support to Text node Message-ID: <20121129010339.5D11947BAC@hg.openjdk.java.net> Changeset: ef5f81064000 Author: Felipe Heidrich Date: 2012-11-28 16:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ef5f81064000 RT-26171: Add RTL support to Text node ! javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java ! javafx-ui-common/src/javafx/scene/text/Text.java From hang.vo at oracle.com Thu Nov 29 01:33:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 29 Nov 2012 09:33:06 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121129093311.5BC3C47BBC@hg.openjdk.java.net> Changeset: 26d62927eb5b Author: Martin Sladecek Date: 2012-11-29 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26d62927eb5b RT-26517, RT-26544 SequentialTransition and ParallelTransition fixes. ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 535735e49872 Author: Martin Sladecek Date: 2012-11-29 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/535735e49872 merge From hang.vo at oracle.com Thu Nov 29 03:33:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 29 Nov 2012 11:33:41 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20121129113348.EEA8547BC1@hg.openjdk.java.net> Changeset: 5ad236b5f3ed Author: tb115823 Date: 2012-11-29 09:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5ad236b5f3ed Changed names of tests to enable junit test runner to pick them - javafx-fxml/test/javafx/fxml/RT_14880.java + javafx-fxml/test/javafx/fxml/RT_14880Test.java - javafx-fxml/test/javafx/fxml/RT_15524.java + javafx-fxml/test/javafx/fxml/RT_15524Test.java - javafx-fxml/test/javafx/fxml/RT_16722.java + javafx-fxml/test/javafx/fxml/RT_16722Test.java - javafx-fxml/test/javafx/fxml/RT_16724.java + javafx-fxml/test/javafx/fxml/RT_16724Test.java - javafx-fxml/test/javafx/fxml/RT_16815.java + javafx-fxml/test/javafx/fxml/RT_16815Test.java - javafx-fxml/test/javafx/fxml/RT_16977.java + javafx-fxml/test/javafx/fxml/RT_16977Test.java - javafx-fxml/test/javafx/fxml/RT_17646.java + javafx-fxml/test/javafx/fxml/RT_17646Test.java - javafx-fxml/test/javafx/fxml/RT_17714.java + javafx-fxml/test/javafx/fxml/RT_17714Test.java - javafx-fxml/test/javafx/fxml/RT_18046.java + javafx-fxml/test/javafx/fxml/RT_18046Test.java - javafx-fxml/test/javafx/fxml/RT_18218.java + javafx-fxml/test/javafx/fxml/RT_18218Test.java - javafx-fxml/test/javafx/fxml/RT_18680.java + javafx-fxml/test/javafx/fxml/RT_18680Test.java - javafx-fxml/test/javafx/fxml/RT_18933.java + javafx-fxml/test/javafx/fxml/RT_18933Test.java - javafx-fxml/test/javafx/fxml/RT_19008.java + javafx-fxml/test/javafx/fxml/RT_19008Test.java - javafx-fxml/test/javafx/fxml/RT_19112.java + javafx-fxml/test/javafx/fxml/RT_19112Test.java - javafx-fxml/test/javafx/fxml/RT_19139.java + javafx-fxml/test/javafx/fxml/RT_19139Test.java - javafx-fxml/test/javafx/fxml/RT_19228.java + javafx-fxml/test/javafx/fxml/RT_19228Test.java - javafx-fxml/test/javafx/fxml/RT_19329.java + javafx-fxml/test/javafx/fxml/RT_19329Test.java - javafx-fxml/test/javafx/fxml/RT_19870.java + javafx-fxml/test/javafx/fxml/RT_19870Test.java - javafx-fxml/test/javafx/fxml/RT_20082.java + javafx-fxml/test/javafx/fxml/RT_20082Test.java - javafx-fxml/test/javafx/fxml/RT_20471.java + javafx-fxml/test/javafx/fxml/RT_20471Test.java - javafx-fxml/test/javafx/fxml/RT_21559.java + javafx-fxml/test/javafx/fxml/RT_21559Test.java - javafx-fxml/test/javafx/fxml/RT_22864.java + javafx-fxml/test/javafx/fxml/RT_22864Test.java - javafx-fxml/test/javafx/fxml/RT_22971.java + javafx-fxml/test/javafx/fxml/RT_22971Test.java - javafx-fxml/test/javafx/fxml/RT_23244.java + javafx-fxml/test/javafx/fxml/RT_23244Test.java - javafx-fxml/test/javafx/fxml/RT_23413.java + javafx-fxml/test/javafx/fxml/RT_23413Test.java - javafx-fxml/test/javafx/fxml/RT_24380.java + javafx-fxml/test/javafx/fxml/RT_24380Test.java Changeset: 812543070c61 Author: tb115823 Date: 2012-11-29 10:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/812543070c61 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 99e8153aadac Author: tb115823 Date: 2012-11-29 12:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/99e8153aadac Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java From tom.schindl at bestsolution.at Thu Nov 29 04:43:58 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Nov 2012 13:43:58 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B074CB.6010807@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> Message-ID: <50B7588E.6060101@bestsolution.at> Hi, Coming back to this I think the easiest solution would be to: a) have constraint objects (HBoxConstraint, ....) b) haveing $layoutPane$.add(Node,Constraint) c) having Node#setLayoutConstraint(Constraint) This makes b) simply a convenience method for c). Why do we need c) well I don't see how we can provide all the different list operations (e.g. bulk operation) with the API Tom E is proposing (List.addAll, List.set, List.add). It would have the advantage that FXML does not have to be changed because it is still the serialized object graph. Drawback: we'd have to have this layoutConstraint-Property in an area of the framework that doesn't really know about layouts but is dealing generic scenegraph/graphic stuff which might the original reason why static stuff got introduced because at its heart JavaFX is not a widget libary but a graphics framework. Tom Am 24.11.12 08:18, schrieb Tom Eugelink: > Ah, yes. We can start by agreeing that it will not be easy, or even > possible, to always create a good Java API that also is easy mappable > and readable onto FXML by simple serialization. So then you come into a > conflict of priorities, what is more important: a good Java API or a > readable FXML? > > We had similar issues with MigPane which also has a constaint class: > > > > Here we decided to use the string notation for the controls. But in > order to process this, we also needed a few static methods on MigPane. > Since I really feel uncomfortable with polluting the Java API with > things that basically are required by the layer above, I decided (to the > dismay of some others) to create a separate MigPane class in a fxml > subpackage which contains these methods. > > http://code.google.com/p/miglayout/source/browse/javafx/src/main/java/org/tbee/javafx/scene/layout/fxml/MigPane.java > > > A similar approach for the alternative HBox would basically result in > the same API as HBox currently has: > > > > > With one important difference in that there still is a formal constraint > class being set instead of an obscure internal map. And, like MigPane, I > would not place these methods in the HBox class directly, but a special > FXML version. Keep the Java API clean. > > But I'd rather use a different approach: provide (de)serializers that > help map the FXML onto the objects. I see FXML as a layer on top of the > API and good software development teachings say that lower layers should > not have any knowledge of higher layers, so I feel really really bad > about polluting the Java API to support FXML. Providing glue might be a > better approach. Java has standard plugin-style solutions in place, like > META-INF/services, so it should be easily possible to provide plugins > together with the components that help in those places where simple > serialization does not cut it. > > http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider > > > In this way both Java API and FXML can be optimal. The plugin can also > be extended to help the scene builder, by providing meta data for when > it can't rely on reflection alone. I suspect the future will only > introduce more of such conflict areas and rolling in a good solution > instead of patching it would be IMHO the right way (tm). > > Tom > > > > On 2012-11-23 11:08, Tom Schindl wrote: >> Hi, >> >> Let me retry - I hope this doesn't get too long. >> >> FXML is simply a serialization definition to serialize ANY given >> java-object graph. >> >> Let's take your example: >> >> >> >> >> which means in full blown FXML without default-attributes >> >> >> >> >> >> >> So written in Java-Code it means >> >> HBox box = new HBox(); >> Label l = new Label(); >> l.set... >> HBox.C c = new HBox.C(); >> c.set... >> l.setConstraint(c); >> box.getChildren().add(l); >> >> Definately not what you want because your layout-containers code looks >> like this: >> >> HBox box = new HBox(); >> Label l = new Label(); >> l.set... >> HBox.C c = new HBox.C(); >> c.set... >> box.add(l,c); >> >> Which clearly violates the generic serialisation which says sub-elements >> are always added (if it is a list) / set (single attribute) on the >> attribute they are the child of. >> >> So if we take your proposed FXML as shown above we have a problem >> because when we follow the general serialization/deserialization >> strategy we'd have to have a layoutConstraint-Property on the *Node* >> although things like layouts only make sense when you add the node >> inside a layout-container but not if it is e.g. a child of a Group, ... >> >> To summerize: My point - I fully agree with you that when coding the UI >> in Java your layout-container additions make a whole lot of sense but >> they break the serialization infrastructure because the addition is not >> done on the attribute itself (children) but through the owner of the >> attribute (HBox). >> >> Tom >> >> Am 22.11.12 19:51, schrieb Tom Eugelink: >>> Not sure I understand what you are trying to say here. Each layout has >>> different and much deviating constraints, so they cannot be unified into >>> one model. >>> >>> I think I summarized it well in my blogpost: "All information about the >>> layout of a single node should be stored in one place." This means >>> absolute layout can suffice with the X,Y,W,H information available in >>> the nodes (and thus allow binding), but all more advanced layouts >>> require a separate constraint class. >>> >>> Tom >>> >>> >>> >>> >>> On 2012-11-21 22:42, Tom Schindl wrote: >>>> the nice thing about the current expression with static calls is that >>>> the semantics for adding children are always the same whether your >>>> target is a Layout-Container or e.g. a Group. >>>> >>>> You always call add on the target your specified. Your way of layout >>>> containers expects two different things to happen: >>>> * for layout container you want to call add on the owner because you >>>> want to pass the constraint object >>>> * you can add on the list itself for stuff like Group but also Tables >>>> >>>> Not to forget how would you like set the constraint when you not add to >>>> a list e.g. when using a borderpane? >>>> >>>> Tom >>>> >>>> Am 21.11.12 19:02, schrieb Tom Eugelink: >>>>> I suspect the constraints were already "out" before FXML, but this >>>>> would >>>>> be a fairly acceptable notation: >>>>> >>>>> | >>>>> >>>>> | >>>>> >>>>> >>>>> Or: >>>>> >>>>> | >>>>> >>>>> | >>>>> >>>>> >>>>> >>>>> On 2012-11-21 17:46, Tom Schindl wrote: >>>>>> Am 21.11.12 09:46, schrieb Richard Bair: >>>>>>> I wanted constraint classes from the start. There was a problem >>>>>>> there, which I don't accurately remember now, but I do want to see >>>>>>> some discussion around deprecating (or at least no longer depending >>>>>>> on) the static methods and having some constraint classes again. >>>>>> They've probably been harder to implement in FXML? >>>>>> >>>>>> 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 bob.vandette at oracle.com Thu Nov 29 07:42:38 2012 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 29 Nov 2012 10:42:38 -0500 Subject: Compact Profiles for the Java Runtime (was: JFX build and deployment - squeaking wheel) In-Reply-To: <1898502.bGQlSukPCl@shire> References: <22F74D6E-5DBB-4539-B5D2-0E1A8B1C9D27@oracle.com> <6568713.h2jPD6x2RH@shire> <0960991D-B64E-4383-A89E-648604986F53@oracle.com> <1898502.bGQlSukPCl@shire> Message-ID: <5B5CEAA3-258F-49F2-A030-2B5304337585@oracle.com> Sorry for the delay in responding. Thanksgiving got in the way. On Nov 18, 2012, at 7:05 PM, Florian Brunner wrote: > Hi Bob, > > Thanks for your response. > >> We have analyzed two different OSGi implementations and they don't appear to >> have any dependencies on these classes. > > I was more refering to the fact, that OSGi sometimes has issues when packages > are split/ incomplete. We are trying to avoid splitting packages at all costs. > >> Can you provide us with a list of some concrete applications that you >> believe require Java Beans? We could investigate the feasibility of >> pushing this package down to compact3 if there's enough demand and if it >> doesn't have any dependencies that we can't untangle. > > > According to: > http://docs.oracle.com/javase/7/docs/api/java/beans/package-use.html > JavaBeans are used even by supported Compact1 profile packages such as: > - java.util.jar > - java.util.logging This dependency is being resolved in JDK8. > > Often JavaBeans classes such as PropertyChangeListener, Introspector, > BeanInfo, PropertyDescriptor etc. are used somewhere in the implementation and > not necessarily in the API, so it's a bit hard find the dependencies, but a > quick search showed at least: > > - Eclipse Link > - Spring > - Several Apache Projects > - GlassFish Projects > - robokind.org > > I'm sure the list can go on. > > Also my own framework, which I'm about to release, uses > PropertyChangeListeners under the hood in the JavaFX-independent parts. > We have not yet made a decision on these beans classes. I'll try to dig into these use cases. > > And what about the other packages I've mentioned: >>> javax.accessibility >>> javax.activation >>> javax.activity >>> javax.annotation >>> javax.print.* >>> javax.sound.* In general, we decided to keep Desktop, JAXWS and Corba out of the compact profiles. We don't want to do anything in JDK8 that will make it difficult to support Jigsaw/modules in JDK9. These groups are too difficult to split up and even in JDK9, there are no plans to do so. The packages you mention are either implemented in these broader categories or are only used by them so we decided to keep them together. javax.accessibility, print and sound are all planned for the Jigsaw desktop module (in full JRE). javax.activation is implemented in jaxws and javax.annotations is only used by jaxws in the jre javax.activity is implemented in the corba collection We have included javax.annotation.processing in compact3. This is required to support the javac compiler. Bob. > > Especially javax.annotation is also quite popular. > > Regards, > Florian > > Am Freitag, 9. November 2012, 18.34:20 schrieb Bob Vandette: >> On Nov 9, 2012, at 5:55 PM, Florian Brunner wrote: >>> Hi Bob, >>> >>> As I understand the profiles/ project Jigsaw in the context of JavaFX is >>> it to makte it easier to port Java + JavaFX to other platforms especially >>> by omitting AWT. So I understand that the following packages are omitted: >>> >>> javax.awt.* >>> javax.swing.* (dependencies to AWT) >>> javax.imagio.* (dependencies to AWT) >>> >>> But neither are any of the following packages mentioned: >>> java.beans.* >>> javax.accessibility >>> javax.activation >>> javax.activity >>> javax.annotation >>> javax.jws.* >>> javax.print.* >>> javax.sound.* >>> org.omg.* >>> >>> Now, I understand that the java.beans.PropertyEditor related classes cause >>> an issue because of the dependency to AWT, but the JEP 161 states that >>> some packages have to be split up anyway (which will probably cause >>> issues with OSGi based library, though). And Java Beans patterns (and >>> e.g. PropertyChangeListener) are used at many places in applications and >>> frameworks. >> We really want to avoid splitting packages because this will make it >> difficult to transition to Jigsaw in JDK9. >> >> The PropertyChangeListener classes are problematic. We currently have a >> small set of beans classes in compact1 that we'd like to remove. I've >> requested the fx team remove any dependency on these class in preparation >> for their possible removal. They have a few JIRA's filed to track this >> change. >> >> We have analyzed two different OSGi implementations and they don't appear to >> have any dependencies on these classes. >> >> Can you provide us with a list of some concrete applications that you >> believe require Java Beans? We could investigate the feasibility of >> pushing this package down to compact3 if there's enough demand and if it >> doesn't have any dependencies that we can't untangle. >> >>> I think there should be a profile (maybe Compact3?), which includes >>> everything except AWT related classes to allow maximum reuse and >>> portability of existing 3rd party libraries, which make the Java >>> ecosystem so rich, so they can be used in JavaFX applications. >> The compact3 profile is a very rich set of APIs. The only large group of SE >> APIs that are not found in this profile are: Desktop (AWT/SWING/Java2D), >> JAX-WS, and Corba. >> >> For embedded we felt that JAX-WS was too heavy weight and difficult to split >> up or subset. We've been working under the assumption that embedded >> devices will probably continue to use the smaller kSoap or move to JAX-RS >> for lighter weight RestFul web services. >>> And another question: >>> >>> The JEP 161 states: >>> "If a package listed in a lower Profile in this table has subpackages then >>> those subpackages are included in that Profile unless they are identified >>> as members of some higher Profile. Thus the java.lang.reflect package, >>> e.g., is in the Compact1 Profile, but java.lang.management is in the >>> Compact3 Profile." >>> >>> But the profile Compact1 states explicitly both java.util and >>> java.util.logging. >>> >>> What about the following packages? >>> >>> java.util.concurrent >>> java.util.concurrent.atomic >>> java.util.concurrent.locks >>> java.util.jar >>> java.util.regex >>> java.util.spi >>> java.util.zip >> >> We were attempting to keep the contents of the JEP to the minimum. >> >> These packages are covered by this statement "If a package listed in a lower >> Profile in this table has subpackages then those subpackages are included >> in that Profile ". Since they aren't explicitly mentioned in higher >> profiles, they are in compact1. >> >> Feel free to build your own set of linux 86 profiles where you can see >> exactly what we've proposed for each profile. >> >> You could also grab a copy of this repo and look at the >> jdk/make/profile-rtjar-includes.txt file that lists the packages included >> in each compact profile level. >> >> http://hg.openjdk.java.net/jdk8/profiles/jdk >> >> Thanks for the input, >> Bob. >> >>> I think it would be clearer if all subpackages were listed explicitly. >>> >>> - Florian >>> >>> Am Donnerstag, 8. November 2012, 16.11:31 schrieb Bob Vandette: >>>> There have been some questions on this list about Jigsaw, compact >>>> profiles, >>>> embedded, minimal VMs and the JRE customization tool called jrecreate. >>>> Richard asked me to jump in to try to clear up any confusion. >>>> >>>> Here goes .... >>>> >>>> The Java Modularity Project (project Jigsaw) that was originally planned >>>> for JDK8 was deferred to JDK9. The Java Embedded team (I'm the lead) >>>> was expecting to use Jigsaw in order to provide smaller customizable >>>> Java runtimes for embedded devices. Lacking this new functionality, we >>>> decided to propose a simpler alternate plan that would enhance the JDK8 >>>> specification to allow the distribution of a small set of profiles that >>>> are >>>> subsets of the full Java runtime. These are called Compact Profiles. >>>> We >>>> have proposed three compact profiles. A talk and presentation that I >>>> gave >>>> at JavaOne describes these profiles. >>>> >>>> https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAE >>>> AD8A BE54064406AC304AD59/CON4538_Vandette.pdf >>>> >>>> The Java Enhancement Proposal (JEP) for this work is here: >>>> >>>> http://openjdk.java.net/jeps/161 >>>> >>>> The openjdk repository that implements our current prototype is located >>>> here: >>>> >>>> http://hg.openjdk.java.net/jdk8/profiles >>>> >>>> The mailing list that discusses the profiles is >>>> build-infra-dev at openjdk.java.net since the creation of the new profiles >>>> is >>>> done using the new configure based JDK build system. >>>> >>>> This repository allows you to do a build that generates the full JRE, >>>> JDK >>>> but in addition produces three additional image targets (compact1, >>>> compact2, and compact3). >>>> >>>> In order to achieve the smallest Java runtime for embedded (our goal is >>>> around 10MB), we have applied changes to Hotspot that allow us to build >>>> a >>>> small VM (2-3MB) with reduced functionality. The small VM (minimal) + >>>> compact1 profile goal we've set is around 10MB. We're at 11MB today. >>>> >>>> In addition to the profile bundles and the small VM, we have a reduced >>>> Embedded FX stack that we'll run on embedded devices such as the >>>> RaspberryPi. This FX Embedded stack is a compatible FX implementation >>>> without media and webkit support. The goal for this added stack is >>>> 6MB. >>>> >>>> The jrecreate tool that some of you have asked about is not a java >>>> stripping tool. It's main purpose is to assist the embedded developer >>>> in customizing Java runtimes. It allows the developer to select which >>>> profile, VM, debugging options, compression, security and FX options. >>>> It does not strip the full JRE to produce the compact profile. The >>>> jrecreate will be packaged with the three compact profile binaries. It >>>> simply copies these profiles and applies some additional massaging >>>> based on the selected options. >>>> >>>> We have already pushed the minimal VM changes to JDK8 hotspot and will >>>> be >>>> open sourcing the compact profile changes since they will be a standard >>>> feature of JDK8 (independent of embedded). The current profile changes >>>> in >>>> our project repository are only functional for Linux x86. >>>> >>>> We certainly recognize the value that small Java runtimes + reduced FX >>>> could have on Java applications published on Web App stores, but the >>>> current immediate plan is that the jrecreate tool is only going to be >>>> available with our embedded binary downloads since that's where it's >>>> needed most. I've had some discussions with our Netbeans team to see >>>> what it will take to make Netbeans profile aware. This might be a good >>>> way of taking advantage of profiles, reduced FX for producing smaller >>>> applications for distribution. >>>> >>>> I hope this help, >>>> Bob. From franck.wolff at graniteds.org Thu Nov 29 08:21:55 2012 From: franck.wolff at graniteds.org (Franck Wolff) Date: Thu, 29 Nov 2012 11:21:55 -0500 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support Message-ID: Hi all, We have long been providing a solution to Flex developers, and have recently released a version of our product that supports JavaFX 2.2: Granite Data Services (GraniteDS) is a comprehensive development and integration solution for building Flex (and now JavaFX) / JavaEE RIA applications. The entire framework is open-source and released under the LGPL v2 license. To know more about what GraniteDS provides to JavaFX developers, see a comprehensive documentation here . The full announcement about this new 3.0.0.M1 version is available here, together with several links to tutorials and resources. This first public release of a GraniteDS for JavaFX is clearly in a beta stage at this time, but with the help of your feedback, we hope to be able to provide new milestones and a stable 3.0.0.GA within the coming months. Here are some additional links: - Community Site: http://www.graniteds.org/ - Blog: http://granitedataservices.com/blog/ - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds - Bug Tracking System (Jira): http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel - Nightly Builds (Bamboo): http://www.graniteds.org/bamboo/allPlans.action - Source Repository: https://github.com/graniteds - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ Your feedback will be greatly appreciated, Franck Wolff From richard.bair at oracle.com Thu Nov 29 08:38:02 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 08:38:02 -0800 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7588E.6060101@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> Message-ID: <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> > Coming back to this I think the easiest solution would be to: > a) have constraint objects (HBoxConstraint, ....) > b) haveing $layoutPane$.add(Node,Constraint) > c) having Node#setLayoutConstraint(Constraint) > > This makes b) simply a convenience method for c). > > Why do we need c) well I don't see how we can provide all the different > list operations (e.g. bulk operation) with the API Tom E is proposing > (List.addAll, List.set, List.add). > > It would have the advantage that FXML does not have to be changed > because it is still the serialized object graph. > > Drawback: we'd have to have this layoutConstraint-Property in an area of > the framework that doesn't really know about layouts but is dealing > generic scenegraph/graphic stuff which might the original reason why > static stuff got introduced because at its heart JavaFX is not a widget > libary but a graphics framework. Actually, every node already has properties on it to support layout -- isResizable, layoutBounds, and so on. So having the constraints on the Node fits right in (and in fact is how we had done it previously). The bigger concern (if I remember correctly), is what is the *type* of this constraints object? Do all layout containers have to cast this and perform an instance of check? Having to do an instance of is distasteful, as is having a base class type that really isn't overly useful (you are likely to fail in finding a least-common-denominator for all constraints types). Further, one advantage to having the layout constraints in the dynamic properties map is that you can have the constraints for two different layout managers at the same time. Niche, but the idea is that you could move a node from one layout container to another and it would just have the right settings. I don't think that is really all that important, but it is a use case. It really is one of those situations where having a nice dynamic language would have been slick. So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting? Richard From hang.vo at oracle.com Thu Nov 29 08:47:53 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 29 Nov 2012 16:47:53 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26171- adding missing override tag Message-ID: <20121129164758.0B7D047BDA@hg.openjdk.java.net> Changeset: f41875afbcf6 Author: Felipe Heidrich Date: 2012-11-29 08:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f41875afbcf6 RT-26171- adding missing override tag ! javafx-ui-common/src/javafx/scene/text/Text.java From tom.schindl at bestsolution.at Thu Nov 29 10:03:57 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Nov 2012 19:03:57 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> Message-ID: <50B7A38D.60608@bestsolution.at> Am 29.11.12 17:38, schrieb Richard Bair: >> Coming back to this I think the easiest solution would be to: >> a) have constraint objects (HBoxConstraint, ....) >> b) haveing $layoutPane$.add(Node,Constraint) >> c) having Node#setLayoutConstraint(Constraint) >> >> This makes b) simply a convenience method for c). >> >> Why do we need c) well I don't see how we can provide all the different >> list operations (e.g. bulk operation) with the API Tom E is proposing >> (List.addAll, List.set, List.add). >> >> It would have the advantage that FXML does not have to be changed >> because it is still the serialized object graph. >> >> Drawback: we'd have to have this layoutConstraint-Property in an area of >> the framework that doesn't really know about layouts but is dealing >> generic scenegraph/graphic stuff which might the original reason why >> static stuff got introduced because at its heart JavaFX is not a widget >> libary but a graphics framework. > > Actually, every node already has properties on it to support layout -- isResizable, layoutBounds, and so on. So having the constraints on the Node fits right in (and in fact is how we had done it previously). The bigger concern (if I remember correctly), is what is the *type* of this constraints object? Do all layout containers have to cast this and perform an instance of check? Having to do an instance of is distasteful, as is having a base class type that really isn't overly useful (you are likely to fail in finding a least-common-denominator for all constraints types). > > Further, one advantage to having the layout constraints in the dynamic properties map is that you can have the constraints for two different layout managers at the same time. Niche, but the idea is that you could move a node from one layout container to another and it would just have the right settings. I don't think that is really all that important, but it is a use case. > Correct and but what if they by chance use the same key for different values, then you hit an even worse problem today ;-) > It really is one of those situations where having a nice dynamic language would have been slick. > > So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting? One way of thinking could be that Constraint is a map like construct because then the layout containers access their information through the same means they do today and don't have to cast to anything class Constraint { private Map data; protected void set(String key, Object value) { data.put(key,value); } public get(String key) { return data.get(key); } } And then you have concrete subclasses e.g. class HBoxConstraint extends Constraint { public void setHgrow(Priority priority) { set(key,priority); } public Priority getHgrow() { return get(key); } } So that users have a type-safe API. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Thu Nov 29 10:32:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 10:32:31 -0800 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7A38D.60608@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> Message-ID: <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> >> It really is one of those situations where having a nice dynamic language would have been slick. >> >> So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting? > > One way of thinking could be that Constraint is a map like construct > because then the layout containers access their information through the > same means they do today and don't have to cast to anything > > class Constraint { > private Map data; > > protected void set(String key, Object value) { > data.put(key,value); > } > > public get(String key) { > return data.get(key); > } > } > > And then you have concrete subclasses e.g. > > class HBoxConstraint extends Constraint { > public void setHgrow(Priority priority) { > set(key,priority); > } > > public Priority getHgrow() { > return get(key); > } > } > > So that users have a type-safe API. That does look like one way, have a type-safe API for developers (more or less -- they still have to cast the constraint if they do node.getConstraint() but at least when they set the constraint up they have some type safe API). However another problem I've had with this approach (and with our current approach) is that layout happens A LOT and costs a lot, so having to hit a map for all the constraint information (and not just the constraint object, but every property in the constraint object) is going to be expensive. Especially when thinking about embedded. Between that and just having a type-safe API and having to cast, I'd probably go with the cast. Get the object, if instance of then extract the constraint values into local fields, otherwise set those local fields to default values, and off you go. Probably the fastest approach, but does require a cast. I wouldn't use a type-parameter on the Node based on constraint type (yikes). Richard From tbee at tbee.org Thu Nov 29 10:42:23 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 19:42:23 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7A38D.60608@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> Message-ID: <50B7AC8F.6080702@tbee.org> On 2012-11-29 19:03, Tom Schindl wrote: > Am 29.11.12 17:38, schrieb Richard Bair: >> >> Actually, every node already has properties on it to support layout -- isResizable, layoutBounds, and so on. So having the constraints on the Node fits right in (and in fact is how we had done it previously). The bigger concern (if I remember correctly), is what is the *type* of this constraints object? Do all layout containers have to cast this and perform an instance of check? Having to do an instance of is distasteful, as is having a base class type that really isn't overly useful (you are likely to fail in finding a least-common-denominator for all constraints types). >> >> Further, one advantage to having the layout constraints in the dynamic properties map is that you can have the constraints for two different layout managers at the same time. Niche, but the idea is that you could move a node from one layout container to another and it would just have the right settings. I don't think that is really all that important, but it is a use case. >> > Correct and but what if they by chance use the same key for different > values, then you hit an even worse problem today ;-) Why would constraints need to have a common super class? Constraints can be so different that trying to force a general API IMHO always will be a bit of a kludge. And I have a working proposal for the constraints-for-multiple-different-layout-managers in the JFXtras versions: each layout holds the contraints in a WeakHashmap. As soon as a Node is no longer referenced, all its constraints are cleared. And this has another advantage: you can have different constaints; so a node can be left aligned in one layout and right aligned in the other. > >> It really is one of those situations where having a nice dynamic language would have been slick. >> >> So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting? > No instanceof, no casting, just a type safe constraint class, specific to this one layout. https://raw.github.com/JFXtras/jfxtras-labs/master/src/main/java/jfxtras/labs/scene/layout/HBox.java Tom From tom.schindl at bestsolution.at Thu Nov 29 11:25:09 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Nov 2012 20:25:09 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7AC8F.6080702@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <50B7AC8F.6080702@tbee.org> Message-ID: <50B7B695.1080807@bestsolution.at> Am 29.11.12 19:42, schrieb Tom Eugelink: > On 2012-11-29 19:03, Tom Schindl wrote: >> Am 29.11.12 17:38, schrieb Richard Bair: >>> >>> Actually, every node already has properties on it to support layout >>> -- isResizable, layoutBounds, and so on. So having the constraints on >>> the Node fits right in (and in fact is how we had done it >>> previously). The bigger concern (if I remember correctly), is what is >>> the *type* of this constraints object? Do all layout containers have >>> to cast this and perform an instance of check? Having to do an >>> instance of is distasteful, as is having a base class type that >>> really isn't overly useful (you are likely to fail in finding a >>> least-common-denominator for all constraints types). >>> >>> Further, one advantage to having the layout constraints in the >>> dynamic properties map is that you can have the constraints for two >>> different layout managers at the same time. Niche, but the idea is >>> that you could move a node from one layout container to another and >>> it would just have the right settings. I don't think that is really >>> all that important, but it is a use case. >>> >> Correct and but what if they by chance use the same key for different >> values, then you hit an even worse problem today ;-) > > Why would constraints need to have a common super class? Constraints can > be so different that trying to force a general API IMHO always will be a > bit of a kludge. > > And I have a working proposal for the > constraints-for-multiple-different-layout-managers in the JFXtras > versions: each layout holds the contraints in a WeakHashmap Constaint>. As soon as a Node is no longer referenced, all its > constraints are cleared. And this has another advantage: you can have > different constaints; so a node can be left aligned in one layout and > right aligned in the other. > I think storing the constraint on the owner is not a good idea because you don't have an API for e.g. bulk-operations. The Layout#add(Node,Constraint) API should only be a convenience one for developers. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Thu Nov 29 11:38:39 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Nov 2012 20:38:39 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> Message-ID: <50B7B9BF.6010008@bestsolution.at> Am 29.11.12 19:32, schrieb Richard Bair: >>> It really is one of those situations where having a nice dynamic language would have been slick. >>> >>> So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting? >> >> One way of thinking could be that Constraint is a map like construct >> because then the layout containers access their information through the >> same means they do today and don't have to cast to anything >> >> class Constraint { >> private Map data; >> >> protected void set(String key, Object value) { >> data.put(key,value); >> } >> >> public get(String key) { >> return data.get(key); >> } >> } >> >> And then you have concrete subclasses e.g. >> >> class HBoxConstraint extends Constraint { >> public void setHgrow(Priority priority) { >> set(key,priority); >> } >> >> public Priority getHgrow() { >> return get(key); >> } >> } >> >> So that users have a type-safe API. > > That does look like one way, have a type-safe API for developers (more or less -- they still have to cast the constraint if they do node.getConstraint() but at least when they set the constraint up they have some type safe API). However another problem I've had with this approach (and with our current approach) is that layout happens A LOT and costs a lot, so having to hit a map for all the constraint information (and not just the constraint object, but every property in the constraint object) is going to be expensive. Especially when thinking about embedded. > > Between that and just having a type-safe API and having to cast, I'd probably go with the cast. Get the object, if instance of then extract the constraint values into local fields, otherwise set those local fields to default values, and off you go. Probably the fastest approach, but does require a cast. I wouldn't use a type-parameter on the Node based on constraint type (yikes). > Who says it has to be a map class Constraint { private Object[] data; protected Constraint(int attributesCount) { data = new Object[attributesCount]; } protected void set(int index, Object value) { data.put(key,value); } public get(int key) { return data[index]; } } class HBoxConstraint extends Constraint { public static final int PRIORTIY = 0; public HBoxConstraint() { super(1); } public void setHgrow(Priority priority) { set(PRIORTIY,priority); } public Priority getHgrow() { return get(PRIORITY); } } All we need to some reflective way to access the data without casting I'm not sure about the overhead of array-index look ups but I think they are fairly small and they don't we only have one object instance If we have constraints with really many attributes we could move the ones with expect to be used more often at the beginning and the others with a higher value and make our initial array size smaller. 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 tbee at tbee.org Thu Nov 29 11:02:35 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 20:02:35 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7AC8F.6080702@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <50B7AC8F.6080702@tbee.org> Message-ID: <50B7B14B.40907@tbee.org> > And I have a working proposal for the constraints-for-multiple-different-layout-managers in the JFXtras versions: each layout holds the contraints in a WeakHashmap. As soon as a Node is no longer referenced, all its constraints are cleared. And this has another advantage: you can have different constaints; so a node can be left aligned in one layout and right aligned in the other. Naturally this weak reference is only used in the multiple layout use case. Normally the constraint is removed immediately when the node is removed from the children. Tom From tbee at tbee.org Thu Nov 29 11:32:43 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 20:32:43 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7B695.1080807@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <50B7AC8F.6080702@tbee.org> <50B7B695.1080807@bestsolution.at> Message-ID: <50B7B85B.9040906@tbee.org> On 2012-11-29 20:25, Tom Schindl wrote: > Am 29.11.12 19:42, schrieb Tom Eugelink: > I think storing the constraint on the owner is not a good idea because you don't have an API for e.g. bulk-operations. The Layout#add(Node,Constraint) API should only be a convenience one for developers. Can you give an example of such bulk operations? Tom From tom.schindl at bestsolution.at Thu Nov 29 12:31:48 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Nov 2012 21:31:48 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7B85B.9040906@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <50B7AC8F.6080702@tbee.org> <50B7B695.1080807@bestsolution.at> <50B7B85B.9040906@tbee.org> Message-ID: <50B7C634.6060306@bestsolution.at> Am 29.11.12 20:32, schrieb Tom Eugelink: > On 2012-11-29 20:25, Tom Schindl wrote: >> Am 29.11.12 19:42, schrieb Tom Eugelink: >> I think storing the constraint on the owner is not a good idea because >> you don't have an API for e.g. bulk-operations. The >> Layout#add(Node,Constraint) API should only be a convenience one for >> developers. > > Can you give an example of such bulk operations? > > Tom > box.getChildren().set(nodes); box.getChildren().addAll(nodes); box.getChildren().addAll(10, nodes); For single adds I think the add on the node is fine for convenience but it hides a but what really happens (the add on the underlying list). I know many people are used to this because this allows them to send notifications in JavaBean world but this is not needed on JavaFX because all and everything can be observed (property/list). Given Richards comments: a) performance is mportant b) Node already has layout-attributes so why not adding one more The only thing that storing of the constraint on the node we can't cover is that it can have different constraints on different layout containers. I don't know how common this is but I'd say a user has to deal with this situation and reassign a layout data when he moves the node from container a to container b. 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 tbee at tbee.org Thu Nov 29 11:56:11 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 20:56:11 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7B9BF.6010008@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> Message-ID: <50B7BDDB.6040001@tbee.org> All these constraints-stored-in-the-node approaches ignore the fact that not the same constraints need to be valid for all possible layouts. Two layouts also can be extremely different; suppose a HBox and a Circular layout. Layout constraints exist in the intersection between node and layout, they should not be pushed into some generic store. And there is concern about speed because of casting, but won't reflection have a much bigger performance penalty? TomE From tom.schindl at bestsolution.at Thu Nov 29 12:50:16 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Nov 2012 21:50:16 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7BDDB.6040001@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> Message-ID: <50B7CA88.7000408@bestsolution.at> Where do you see reflection happening? The Layout container would call the get(int) method and you get what you want a constraint specific for your layout container to programm against. Tom Am 29.11.12 20:56, schrieb Tom Eugelink: > All these constraints-stored-in-the-node approaches ignore the fact that > not the same constraints need to be valid for all possible layouts. Two > layouts also can be extremely different; suppose a HBox and a Circular > layout. Layout constraints exist in the intersection between node and > layout, they should not be pushed into some generic store. > > And there is concern about speed because of casting, but won't > reflection have a much bigger performance penalty? > TomE > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Thu Nov 29 12:57:23 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 12:57:23 -0800 Subject: [Review request] TreeTableView In-Reply-To: <23221300-C1B1-4D18-8E0C-57E6EE61D6C3@oracle.com> References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> <50B41143.30504@oracle.com> <50B41523.40206@oracle.com> <1A44E4A1-CBCB-41EF-8374-328A225D6EE8@oracle.com> <23221300-C1B1-4D18-8E0C-57E6EE61D6C3@oracle.com> Message-ID: Bummer. I think the API is good enough we can move over to the javafx package space and lets get the feedback from people trying to use it! Richard On Nov 27, 2012, at 9:33 AM, Jonathan Giles wrote: > Yes, it appears so. > > -- Jonathan > > On 28/11/2012, at 4:12 AM, Richard Bair wrote: > >> Is this part of existing API? >> >> On Nov 26, 2012, at 5:19 PM, Jonathan Giles wrote: >> >>> This appears to be an unfortunate and unintentional historical oversight. I have no desire for it to be Double, and could quite easily use double instead. Because of this, the meaning of null is undefined, but should probably mean 0.0. >>> >>> -- Jonathan >>> >>> On 27/11/2012 2:14 p.m., Richard Bair wrote: >>>> Why does ResizeFeaturesBase getDelta return a Double instead of a double? What does the "null" value mean in this context? >>>> >>>> On Nov 26, 2012, at 5:02 PM, Jonathan Giles wrote: >>>> >>>>> The Javadoc documentation has been attached to the Jira issue here: >>>>> >>>>> http://javafx-jira.kenai.com/browse/RT-17288 >>>>> >>>>> -- Jonathan >>> >> From richard.bair at oracle.com Thu Nov 29 12:59:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 12:59:22 -0800 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: Message-ID: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Cool! Are there any online samples? BlazeDS I remember had some great sample pages or videos (I don't remember which) that showed things such as two browser windows open, writing in one and auto-updating the UI in the other, etc. I'm wondering if graniteds has anything of that kind? Thanks Richard On Nov 29, 2012, at 8:21 AM, Franck Wolff wrote: > Hi all, > > We have long been providing a solution to Flex developers, and have > recently released a version of our product that supports JavaFX 2.2: Granite > Data Services (GraniteDS) is a comprehensive > development and integration solution for building Flex (and now JavaFX) / > JavaEE RIA applications. The entire framework is open-source and released > under the LGPL v2 license. > > To know more about what GraniteDS provides to JavaFX developers, see a > comprehensive documentation > here > . > > The full announcement about this new 3.0.0.M1 version is available > here, > together with several links to tutorials and resources. This first public > release of a GraniteDS for JavaFX is clearly in a beta stage at this time, > but with the help of your feedback, we hope to be able to provide new > milestones and a stable 3.0.0.GA within the coming months. > > Here are some additional links: > > > - Community Site: http://www.graniteds.org/ > - Blog: http://granitedataservices.com/blog/ > - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds > - Bug Tracking System (Jira): > http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel > - Nightly Builds (Bamboo): > http://www.graniteds.org/bamboo/allPlans.action > - Source Repository: https://github.com/graniteds > - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ > > Your feedback will be greatly appreciated, > > Franck Wolff From zonski at gmail.com Thu Nov 29 13:16:13 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 30 Nov 2012 08:16:13 +1100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7CA88.7000408@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> Message-ID: <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> This thread has meandered a bit and I've lost track of the problem you're trying to solve. Would it be possible to restate the end goal (in a short sentence or two)? If it is to simplify the FXML then I still think builders would do it (Greg would normally have chimed in by now so I assume he's off-list). If you provide a short snip of your ideal FXML I'll have a crack at achieving it with builders. If the goal is better tool support, I'm not sure what can't be achieved through inspection of node and builder classes so an example would be good. If the goal is something else, I lost track. One comment: the idea of setting constraints in case the node moves to another type of parent (ie right align me in a GridPane, left align my in a HBox) is something I don't like the look of. You need the contextual information (eg am I on the person details page or the person summary page), the container 'type' does not provide this. If you want true portability of your fxml control better to push the declaration of the constraints into each FXML that declares the container (migpane can do this to a certain extent). This can again be achieved with builders (and numerous other techniques). Happy to show examples of this if needs be. On 30/11/2012, at 7:50 AM, Tom Schindl wrote: > Where do you see reflection happening? > > The Layout container would call the get(int) method and you get what you > want a constraint specific for your layout container to programm against. > > Tom > > Am 29.11.12 20:56, schrieb Tom Eugelink: >> All these constraints-stored-in-the-node approaches ignore the fact that >> not the same constraints need to be valid for all possible layouts. Two >> layouts also can be extremely different; suppose a HBox and a Circular >> layout. Layout constraints exist in the intersection between node and >> layout, they should not be pushed into some generic store. >> >> And there is concern about speed because of casting, but won't >> reflection have a much bigger performance penalty? >> TomE >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Thu Nov 29 13:29:33 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 13:29:33 -0800 Subject: Why is jfxrt.jar not distributed as .pack? In-Reply-To: References: Message-ID: Kevin, do you know? On Nov 26, 2012, at 8:12 AM, Sven Reimers wrote: > Hi, > > the subject says it all. rt.jar is delivered inside the jre installer as a > .pack file to reduce download bandwidth / distribution size. Why is > jfxrt.jar not delivered the same way? > > Should this be the case? Is this behaviour intentional? Shall I file a bug > with JIRA? > > Thanks > > -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 tbee at tbee.org Thu Nov 29 12:43:08 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 21:43:08 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7C634.6060306@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <50B7AC8F.6080702@tbee.org> <50B7B695.1080807@bestsolution.at> <50B7B85B.9040906@tbee.org> <50B7C634.6060306@bestsolution.at> Message-ID: <50B7C8DC.7030908@tbee.org> > box.getChildren().set(nodes); > box.getChildren().addAll(nodes); > box.getChildren().addAll(10, nodes); > Ah, ok. That is a matter of preference; I rather have clean constraints than these bulk methods. These methods in my concept indeed only are usable in absolute layout (graphics framework "mode"), where all constraint information is in the node. The advanced layouts need to use the add(n,c) (form "mode"). One consideration: how often are advanced layouts used with bulk nodes? Tom From kevin.rushforth at oracle.com Thu Nov 29 14:09:01 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Nov 2012 14:09:01 -0800 Subject: Why is jfxrt.jar not distributed as .pack? In-Reply-To: References: Message-ID: <50B7DCFD.9050801@oracle.com> No, but I can find out. We just deliver jfxrt.jar into the JDK / JRE build and rely on the JRE installer to package it up from there. -- Kevin Richard Bair wrote: > Kevin, do you know? > > On Nov 26, 2012, at 8:12 AM, Sven Reimers wrote: > > >> Hi, >> >> the subject says it all. rt.jar is delivered inside the jre installer as a >> .pack file to reduce download bandwidth / distribution size. Why is >> jfxrt.jar not delivered the same way? >> >> Should this be the case? Is this behaviour intentional? Shall I file a bug >> with JIRA? >> >> Thanks >> >> -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 tbee at tbee.org Thu Nov 29 13:16:57 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 22:16:57 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7CA88.7000408@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> Message-ID: <50B7D0C9.50107@tbee.org> You used the words "reflective way to access the data" and I reacted to that. On 2012-11-29 21:50, Tom Schindl wrote: > Where do you see reflection happening? > > The Layout container would call the get(int) method and you get what you > want a constraint specific for your layout container to programm against. > > Tom > From richard.bair at oracle.com Thu Nov 29 14:28:25 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 14:28:25 -0800 Subject: Extending builders In-Reply-To: <50B62D51.6020601@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> <50AE394A.4060703@oracle.com> <50AE3E5B.6010400@oracle.com> <50B62D51.6020601@oracle.com> Message-ID: <2A13C99B-D20F-4005-B523-0016F58E6B9E@oracle.com> I'm confused, don't we want scene builder / FXML to be able to use these new methods defined on builders as well? If they are used, then we have to use a builder instead of just configuring an object via reflection, or some such? Richard On Nov 28, 2012, at 7:27 AM, Eva Krejcirova wrote: > There will certainly be methods with one argument, so this means that there must be a way for SceneBuilder and FXML to tell these methods apart from the property methods. > We can annotate the convenience methods by special annotation (e.g. BuilderConvenienceMethod). > Or we could add an annotation (e.g. BuilderProperty) to the methods which correspond to properties (= the methods which are currently in the builders). > > Eva > > On 22.11.2012 16:01, Daniel Fuchs wrote: >> On 11/22/12 3:40 PM, Eva Krejcirova wrote: >>> Hi, >>> >>> There is one more thing which needs to be sorted out before adding new >>> methods to builders: >>> SceneBuilder and FXML use builders to find names of properties of a >>> class, so they need to have a way to differentiate between the new >>> convenience methods and the methods which correspond to properties of a >>> class. Daniel, is this still true? >>> >>> Last time we discussed this, Daniel suggested to annotate these new >>> convenience methods. If we go this way, we need to create a new runtime >>> annotation (and find a name for it :-) ) >>> >>> Eva >> >> Hi Eva, >> >> Yes this is still true. Note that SceneBuilder actually uses >> builders only in special cases - for WebView - for instance - >> because of the fake location attribute available on WebViewBuilder >> only - and for any type which has no public constructors (e.g.: all charts, Insets, etc...) >> >> However - SceneBuilder discovers whether there are constructor properties by introspecting ClassX and ClassXBuilder and comparing >> the results: it takes the name of all the single parameter >> instance methods in ClassXBuilder which returns a builder, >> remove the names of all writable (getter+setter) properties >> found in ClassX, and what remain are assumed to be constructor properties. >> >> As long as the convenience methods have more than 1 parameter >> (varargs count for 1) then this logic should remain valid. >> >> The FXMLLoader's JavaFXBuilderFactory also introspects builders >> in order to find out writable properties and type of properties, >> so that's another place you will have to look at >> (class JavaFXBuilderFactory.JavaFXBuilder). >> >> best regards, >> >> -- daniel >> >> >> > From richard.bair at oracle.com Thu Nov 29 14:28:54 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 14:28:54 -0800 Subject: Extending builders: PathBuilder In-Reply-To: <50B6266C.1020105@oracle.com> References: <4FFDAD1C.2010501@oracle.com> <9720B243-7559-4926-B217-4B51FC13AC0A@oracle.com> <50AD14D3.8090208@oracle.com> <8F343DDF-FEE8-4BE5-BA8A-1561F3C167E9@oracle.com> <50B6266C.1020105@oracle.com> Message-ID: Looks like. On Nov 28, 2012, at 6:57 AM, Eva Krejcirova wrote: > On 22.11.2012 14:18, Richard Bair wrote: >>>>> There is one part which is unclear: What to do, if BOTH elements() and new methods (moveTo, etc.) are used? e.g. >>>>> >>>>> PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); >>>>> or >>>>> PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); >>>>> >>>>> There are several approaches for this : >>>>> >>>>> 1.) appending everything into one list so both of former examples return the same path. >>>> This was my natural inclination. Is it really likely that we would break anybody if we decided to treat all such methods (like children()) in this way, where they are additive? I mean, does anybody have a builder with two calls to children where they expected the second to replace the first? It seems maybe this is a place where the spec should be changed? >>> What if somebody uses a single Group builder instance which is configured with common attributes and then used for building multiple Group-s each of them having different set of children. In that case I would expect children replacing and not adding to the existing list. >> >> Good argument. > Ok, so are we back at option 4 then? That was following behavior: > > Calling elements() erases all previous calls to elements(), moveTo(), ... New methods moveTo, lineTo etc. will add the element even if there already are some elements added by elements() call previously, they will not erase anything. This will not break backwards compatibility and will be consistent with other builder methods and has clearly defined behavior. > e.g. > PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); will only contain ClosePath > PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).closePath().build(); will contain MoveTo, LineTo, ClosePath > > Eva From tbee at tbee.org Thu Nov 29 13:27:43 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 29 Nov 2012 22:27:43 +0100 Subject: Layouts with constraint classes (was: Extending Builders: Layout Builders) In-Reply-To: <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> Message-ID: <50B7D34F.8090904@tbee.org> On 2012-11-29 22:16, Daniel Zwolenski wrote: > This thread has meandered a bit and I've lost track of the problem you're trying to solve. Would it be possible to restate the end goal (in a short sentence or two)? > Your are right. The original post suggested adding an number of methods to the layout builders. I suggested to not do that, but use formal constraint classes. Richard asked for a discussion on that topic. There was one, but at this point I would say that it comes down to preference, because the getChildren() API and the add(N,C) are in conflict. One camp wants the constraints in the node so you can still use getChildren. The other wants the constraints in the layout, because they are only of value in context of that particular layout. (About your remark on "another type of parent"; that is "another parent", or another instance of a layout classes... there is nothing static going on.) Tom From richard.bair at oracle.com Thu Nov 29 14:51:14 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 14:51:14 -0800 Subject: Layouts with constraint classes (was: Extending Builders: Layout Builders) In-Reply-To: <50B7D34F.8090904@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> Message-ID: >> This thread has meandered a bit and I've lost track of the problem you're trying to solve. Would it be possible to restate the end goal (in a short sentence or two)? >> > > Your are right. The original post suggested adding an number of methods to the layout builders. I suggested to not do that, but use formal constraint classes. Richard asked for a discussion on that topic. There was one, but at this point I would say that it comes down to preference, because the getChildren() API and the add(N,C) are in conflict. One camp wants the constraints in the node so you can still use getChildren. The other wants the constraints in the layout, because they are only of value in context of that particular layout. (About your remark on "another type of parent"; that is "another parent", or another instance of a layout classes... there is nothing static going on.) Having the constraints on the child is certainly the most natural solution with respect to how the FX APIs work. I think we cannot discount the fact that children is a full blown observable list and has the methods for keeping some, removing all, etc. When constraints are defined on the child node itself, it also works more naturally with FXML, and also (for what its worth) means that you can probably define the layout information in CSS and have it apply to a particular node as well. Which is a long-sought-after-feature. The big hang-up is, if the constraint is defined on the child, then we're left with either a map of constraints (current situation, except we could have direct API on the node for it rather than static methods on the parent), or we require an instance of check and a cast. At least, that is how I see the options when constraints are on the child. Or have an uber-constraint object with everything imaginable, but that obviously isn't scalable to 3rd party layouts and sounds like an awful idea in any case. Any other ideas? Richard From daniel.fuchs at oracle.com Thu Nov 29 15:18:30 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 30 Nov 2012 00:18:30 +0100 Subject: Extending builders In-Reply-To: <2A13C99B-D20F-4005-B523-0016F58E6B9E@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> <50AE394A.4060703@oracle.com> <50AE3E5B.6010400@oracle.com> <50B62D51.6020601@oracle.com> <2A13C99B-D20F-4005-B523-0016F58E6B9E@oracle.com> Message-ID: <50B7ED46.9080100@oracle.com> On 11/29/12 11:28 PM, Richard Bair wrote: > I'm confused, don't we want scene builder / FXML to be able to use these new methods defined on builders as well? If they are used, then we have to use a builder instead of just configuring an object via reflection, or some such? > > Richard Hi Richard, SceneBuilder is able to deal with Builders methods if there is a corresponding getter on the object. If there is no getter on the object, then SceneBuilder can't figure out what the corresponding value should be - in which case there needs to be specific code in SB to take advantage of said methods. A good example is the faked 'url' attribute for Image, or the fake 'location' attribute added to WebViewBuilder. In both cases - we had to add specific code in SB to handle these... It's not because there's no value for an attribute in FXML that there's no value for that attribute on the object itself. Let's say you have something like: which happens to return a WebView... What value for the location attribute are you going to show in the Inspector? How is SceneBuilder going to figure out that this location attribute should be read-only, because it can only be supplied to the WebViewBuilder, and therefore is valid whereas is not - because the object returned by fx:include is already built? Usually you will need to add specific code that knows about this - e.g - that knows that you can get the value of the location attribute by calling WebView.getEngine().location()... So even if the FXML loader is able to use these methods SceneBuilder might not - at least not out of the box... -- daniel > > On Nov 28, 2012, at 7:27 AM, Eva Krejcirova wrote: > >> There will certainly be methods with one argument, so this means that there must be a way for SceneBuilder and FXML to tell these methods apart from the property methods. >> We can annotate the convenience methods by special annotation (e.g. BuilderConvenienceMethod). >> Or we could add an annotation (e.g. BuilderProperty) to the methods which correspond to properties (= the methods which are currently in the builders). >> >> Eva >> >> On 22.11.2012 16:01, Daniel Fuchs wrote: >>> On 11/22/12 3:40 PM, Eva Krejcirova wrote: >>>> Hi, >>>> >>>> There is one more thing which needs to be sorted out before adding new >>>> methods to builders: >>>> SceneBuilder and FXML use builders to find names of properties of a >>>> class, so they need to have a way to differentiate between the new >>>> convenience methods and the methods which correspond to properties of a >>>> class. Daniel, is this still true? >>>> >>>> Last time we discussed this, Daniel suggested to annotate these new >>>> convenience methods. If we go this way, we need to create a new runtime >>>> annotation (and find a name for it :-) ) >>>> >>>> Eva >>> Hi Eva, >>> >>> Yes this is still true. Note that SceneBuilder actually uses >>> builders only in special cases - for WebView - for instance - >>> because of the fake location attribute available on WebViewBuilder >>> only - and for any type which has no public constructors (e.g.: all charts, Insets, etc...) >>> >>> However - SceneBuilder discovers whether there are constructor properties by introspecting ClassX and ClassXBuilder and comparing >>> the results: it takes the name of all the single parameter >>> instance methods in ClassXBuilder which returns a builder, >>> remove the names of all writable (getter+setter) properties >>> found in ClassX, and what remain are assumed to be constructor properties. >>> >>> As long as the convenience methods have more than 1 parameter >>> (varargs count for 1) then this logic should remain valid. >>> >>> The FXMLLoader's JavaFXBuilderFactory also introspects builders >>> in order to find out writable properties and type of properties, >>> so that's another place you will have to look at >>> (class JavaFXBuilderFactory.JavaFXBuilder). >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> From richard.bair at oracle.com Thu Nov 29 15:29:05 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 29 Nov 2012 15:29:05 -0800 Subject: Extending builders In-Reply-To: <50B7ED46.9080100@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> <50AE394A.4060703@oracle.com> <50AE3E5B.6010400@oracle.com> <50B62D51.6020601@oracle.com> <2A13C99B-D20F-4005-B523-0016F58E6B9E@oracle.com> <50B7ED46.9080100@oracle.com> Message-ID: Interesting, especially in the case of web view where location is not only synthetic, but actually exists on an object deeper down (getEngine())! On Nov 29, 2012, at 3:18 PM, Daniel Fuchs wrote: > On 11/29/12 11:28 PM, Richard Bair wrote: >> I'm confused, don't we want scene builder / FXML to be able to use these new methods defined on builders as well? If they are used, then we have to use a builder instead of just configuring an object via reflection, or some such? >> >> Richard > Hi Richard, > > SceneBuilder is able to deal with Builders methods if there is a corresponding getter on the object. > If there is no getter on the object, then SceneBuilder can't figure out what the corresponding value should be - in which case there needs to be specific code in SB to take advantage of said methods. > > A good example is the faked 'url' attribute for Image, or the fake 'location' attribute added to WebViewBuilder. > In both cases - we had to add specific code in SB to handle these... > > It's not because there's no value for an attribute in FXML that there's no value for that attribute on the object itself. > > Let's say you have something like: > > > > which happens to return a WebView... What value for the location attribute are you going to show in the Inspector? How is SceneBuilder going to figure out that this location attribute should be read-only, because it can only be supplied to the WebViewBuilder, and therefore is valid whereas is not - because the object returned by fx:include is already built? > Usually you will need to add specific code that knows about this - e.g - that knows that you can get the value of the > location attribute by calling WebView.getEngine().location()... > > So even if the FXML loader is able to use these methods SceneBuilder might not - at least not out of the box... > > -- daniel > >> >> On Nov 28, 2012, at 7:27 AM, Eva Krejcirova wrote: >> >>> There will certainly be methods with one argument, so this means that there must be a way for SceneBuilder and FXML to tell these methods apart from the property methods. >>> We can annotate the convenience methods by special annotation (e.g. BuilderConvenienceMethod). >>> Or we could add an annotation (e.g. BuilderProperty) to the methods which correspond to properties (= the methods which are currently in the builders). >>> >>> Eva >>> >>> On 22.11.2012 16:01, Daniel Fuchs wrote: >>>> On 11/22/12 3:40 PM, Eva Krejcirova wrote: >>>>> Hi, >>>>> >>>>> There is one more thing which needs to be sorted out before adding new >>>>> methods to builders: >>>>> SceneBuilder and FXML use builders to find names of properties of a >>>>> class, so they need to have a way to differentiate between the new >>>>> convenience methods and the methods which correspond to properties of a >>>>> class. Daniel, is this still true? >>>>> >>>>> Last time we discussed this, Daniel suggested to annotate these new >>>>> convenience methods. If we go this way, we need to create a new runtime >>>>> annotation (and find a name for it :-) ) >>>>> >>>>> Eva >>>> Hi Eva, >>>> >>>> Yes this is still true. Note that SceneBuilder actually uses >>>> builders only in special cases - for WebView - for instance - >>>> because of the fake location attribute available on WebViewBuilder >>>> only - and for any type which has no public constructors (e.g.: all charts, Insets, etc...) >>>> >>>> However - SceneBuilder discovers whether there are constructor properties by introspecting ClassX and ClassXBuilder and comparing >>>> the results: it takes the name of all the single parameter >>>> instance methods in ClassXBuilder which returns a builder, >>>> remove the names of all writable (getter+setter) properties >>>> found in ClassX, and what remain are assumed to be constructor properties. >>>> >>>> As long as the convenience methods have more than 1 parameter >>>> (varargs count for 1) then this logic should remain valid. >>>> >>>> The FXMLLoader's JavaFXBuilderFactory also introspects builders >>>> in order to find out writable properties and type of properties, >>>> so that's another place you will have to look at >>>> (class JavaFXBuilderFactory.JavaFXBuilder). >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> > From tom.schindl at bestsolution.at Thu Nov 29 16:08:28 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 30 Nov 2012 01:08:28 +0100 Subject: Extending Builders: Layout Builders In-Reply-To: <50B7D0C9.50107@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <50B7D0C9.50107@tbee.org> Message-ID: <50B7F8FC.6040902@bestsolution.at> Ah I see with reflective I meant the get/set API which does not require you to call the property-getter but use get(String)/get(int) instead. Tom Am 29.11.12 22:16, schrieb Tom Eugelink: > You used the words "reflective way to access the data" and I reacted to > that. > > > On 2012-11-29 21:50, Tom Schindl wrote: >> Where do you see reflection happening? >> >> The Layout container would call the get(int) method and you get what you >> want a constraint specific for your layout container to programm against. >> >> 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 zonski at gmail.com Thu Nov 29 17:02:11 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 30 Nov 2012 12:02:11 +1100 Subject: Layouts with constraint classes (was: Extending Builders: Layout Builders) In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> Message-ID: When I say "defining" constraints in the parent (vs child) I am talking about how you declare it in the FXML and this does not have to match what happens in the Java world (because we have binders). The Java side of it can still "store" the constraints on the child (or not, whatever you want). The "glue" (e.g. binders) can map from FXML world to Java world, allowing both to be optimal for their needs. The suggestion looked to me to be that the Java model needs changing in order to better support atomic FXML snippets being more easily moved from container to container (i.e. if I happen to be in a HBox use these, if I happen to be in a GridPane use these). If the goal is to allow for the FXML to be reused then the container should know about the child but the child should not know about it's container. So we just need a way to "declare" the constraints in the parent (i.e. I am the PersonDetails view so I will add this atomic block of FXML left aligned, vs I am the PersonSummaryView so I will add this block right aligned) instead of in the child (i.e. I am an atomic block of FXML - if you put me in a HBox I should be left aligned, if you put me in a GridPane I should be right aligned). Plenty of mechanisms already exist for declaring the constraints in the outer FXML (builders being one of them) and these co-exist with the existing way of specifying them at a child level, allowing developers to mix and match based on their scenario. For me, I don't see a need to change the Java API to make anything "better" here for FXML and component re-use. This was just a side comment though and the thread meanders further. In lieu of someone else summarizing the goals, here's my take and you guys can maybe correct any misunderstanding I have: - there are no problems in FXML at the moment, binders can be used to add syntactic sugar. Possibly some of the existing binders could be enhanced to add some more sugar - we should define the sweet FXML and work out the binding enhancements needed. - there may be some problems with the tools (i.e. scene builder) detecting certain things but it's not too clear what these problems are - we should identify the problems. - there is a perfectly functional but not-very-nice use of static methods in the Java code to set constraints - these would be nice to avoid but were done this way for a reason (which may now be forgotten) - we could discuss ways to get rid of these but this is largely independent on what we want to see in the FXML. Cheers, Dan On Fri, Nov 30, 2012 at 9:51 AM, Richard Bair wrote: > >> This thread has meandered a bit and I've lost track of the problem > you're trying to solve. Would it be possible to restate the end goal (in a > short sentence or two)? > >> > > > > Your are right. The original post suggested adding an number of methods > to the layout builders. I suggested to not do that, but use formal > constraint classes. Richard asked for a discussion on that topic. There was > one, but at this point I would say that it comes down to preference, > because the getChildren() API and the add(N,C) are in conflict. One camp > wants the constraints in the node so you can still use getChildren. The > other wants the constraints in the layout, because they are only of value > in context of that particular layout. (About your remark on "another type > of parent"; that is "another parent", or another instance of a layout > classes... there is nothing static going on.) > > Having the constraints on the child is certainly the most natural solution > with respect to how the FX APIs work. I think we cannot discount the fact > that children is a full blown observable list and has the methods for > keeping some, removing all, etc. When constraints are defined on the child > node itself, it also works more naturally with FXML, and also (for what its > worth) means that you can probably define the layout information in CSS and > have it apply to a particular node as well. Which is a > long-sought-after-feature. > > The big hang-up is, if the constraint is defined on the child, then we're > left with either a map of constraints (current situation, except we could > have direct API on the node for it rather than static methods on the > parent), or we require an instance of check and a cast. At least, that is > how I see the options when constraints are on the child. Or have an > uber-constraint object with everything imaginable, but that obviously isn't > scalable to 3rd party layouts and sounds like an awful idea in any case. > > Any other ideas? > > Richard From jonathan.giles at oracle.com Thu Nov 29 17:20:01 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 30 Nov 2012 14:20:01 +1300 Subject: [Review request] TreeTableView In-Reply-To: References: <50B3EB05.6000406@oracle.com> <021CE73D-03CA-4948-83A5-47F986E94DF3@oracle.com> <50B40B76.7030809@oracle.com> <50B41143.30504@oracle.com> <50B41523.40206@oracle.com> <1A44E4A1-CBCB-41EF-8374-328A225D6EE8@oracle.com> <23221300-C1B1-4D18-8E0C-57E6EE61D6C3@oracle.com> Message-ID: <50B809C1.3080708@oracle.com> Thanks. I will work to get this into the openjfx 8.0 controls repo by early next week at the latest - I'm just finishing off the first pass at javadoc. I look forward to getting real-world user feedback. -- Jonathan On Friday, 30 November 2012 9:57:23 a.m., Richard Bair wrote: > Bummer. > > I think the API is good enough we can move over to the javafx package space and lets get the feedback from people trying to use it! > > Richard > > On Nov 27, 2012, at 9:33 AM, Jonathan Giles wrote: > >> Yes, it appears so. >> >> -- Jonathan >> >> On 28/11/2012, at 4:12 AM, Richard Bair wrote: >> >>> Is this part of existing API? >>> >>> On Nov 26, 2012, at 5:19 PM, Jonathan Giles wrote: >>> >>>> This appears to be an unfortunate and unintentional historical oversight. I have no desire for it to be Double, and could quite easily use double instead. Because of this, the meaning of null is undefined, but should probably mean 0.0. >>>> >>>> -- Jonathan >>>> >>>> On 27/11/2012 2:14 p.m., Richard Bair wrote: >>>>> Why does ResizeFeaturesBase getDelta return a Double instead of a double? What does the "null" value mean in this context? >>>>> >>>>> On Nov 26, 2012, at 5:02 PM, Jonathan Giles wrote: >>>>> >>>>>> The Javadoc documentation has been attached to the Jira issue here: >>>>>> >>>>>> http://javafx-jira.kenai.com/browse/RT-17288 >>>>>> >>>>>> -- Jonathan >>>> >>> > From hang.vo at oracle.com Thu Nov 29 20:03:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 30 Nov 2012 04:03:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26590: Text unit test failure after adding RTL support Message-ID: <20121130040338.3227147BFD@hg.openjdk.java.net> Changeset: fcce9e4370aa Author: Felipe Heidrich Date: 2012-11-29 19:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fcce9e4370aa RT-26590: Text unit test failure after adding RTL support ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java From hang.vo at oracle.com Thu Nov 29 22:22:54 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 30 Nov 2012 06:22:54 +0000 Subject: hg: openjfx/8/master/rt: 34 new changesets Message-ID: <20121130062337.67F4B47C1F@hg.openjdk.java.net> Changeset: 30a695b3c758 Author: Paru Somashekar Date: 2012-11-14 14:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/30a695b3c758 RT-26148 Add RTL support for Chart ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 45835ed4cac5 Author: leifs Date: 2012-11-18 19:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/45835ed4cac5 RT-24233: Add NodeOrientation support to TextField. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java Changeset: e45a7663b26d Author: raginip Date: 2012-11-19 14:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e45a7663b26d Fixed copyright and removed author ! 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-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 Changeset: ae5697996ff1 Author: David Grieve Date: 2012-11-19 20:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ae5697996ff1 RT-26172: revert changes related to Parent having its own stylemanager - javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java - javafx-ui-common/src/com/sun/javafx/css/SceneStyleManager.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/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 37cdc2382b25 Author: David Grieve Date: 2012-11-20 10:34 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/37cdc2382b25 unit test fixes and ignores ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleManagerTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java Changeset: ca9d915db72f Author: David Grieve Date: 2012-11-20 11:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ca9d915db72f branch merge - javafx-ui-common/src/com/sun/javafx/css/ParentStyleManager.java - javafx-ui-common/src/com/sun/javafx/css/SceneStyleManager.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 6948b1cc29c5 Author: Felipe Heidrich Date: 2012-11-14 10:54 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6948b1cc29c5 [ECLISPE_ONLY] removing old classpath & project files - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project Changeset: 5c36a4a20edb Author: Martin Sladecek Date: 2012-11-19 09:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5c36a4a20edb RT-26296 Ensemble: Pause Transition hangs ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 0c13364d5766 Author: Lubomir Nerad Date: 2012-11-20 14:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0c13364d5766 Fix for RT-25977: added missing KeyCombination.ModifierValue javadoc ! javafx-ui-common/src/javafx/scene/input/KeyCombination.java Changeset: 591592a4ae64 Author: Lubomir Nerad Date: 2012-11-20 16:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/591592a4ae64 Fix for RT-26241: made Screen class more robust ! javafx-ui-common/src/javafx/stage/Screen.java + javafx-ui-common/test/unit/javafx/stage/ScreenTest.java Changeset: 37c2ab46c51d Author: Eva Krejcirova Date: 2012-11-20 17:52 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/37c2ab46c51d RT-25618: ArcTo needs javadoc ! javafx-ui-common/src/javafx/scene/shape/ArcTo.java + javafx-ui-common/src/javafx/scene/shape/doc-files/arcto-flags.png + javafx-ui-common/src/javafx/scene/shape/doc-files/arcto.png Changeset: f4ac2f436738 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-20 10:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f4ac2f436738 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project Changeset: a7ce5f766cf4 Author: David Grieve Date: 2012-11-20 13:55 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a7ce5f766cf4 RT-26326: distance to look for font styles was zero if no shorthand was found. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 686b52a44cc4 Author: David Grieve Date: 2012-11-21 09:22 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/686b52a44cc4 [TEST-ONLY] ignore failing test to get build back on track ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java Changeset: ececf104ffcc Author: David Grieve Date: 2012-11-21 11:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ececf104ffcc branch merge - decora-compiler/.classpath - decora-compiler/.project - javafx-fxml/.classpath - javafx-fxml/.project - javafx-ui-charts/.classpath - javafx-ui-charts/.project - javafx-ui-common/.classpath - javafx-ui-common/.project - javafx-ui-controls/.classpath - javafx-ui-controls/.project - javafx-util-converter/.classpath - javafx-util-converter/.project Changeset: acd1cfc745ee Author: "Jasper Potts" Date: 2012-11-21 12:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/acd1cfc745ee Fix RT-25325: Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.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/skin/AccordionSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/DoubleField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/InputField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Button.java ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java ! javafx-ui-controls/src/javafx/scene/control/ChoiceBox.java ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PasswordField.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitMenuButton.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableRow.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 156774e6fa98 Author: mickf Date: 2012-11-26 14:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/156774e6fa98 RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input ! javafx-ui-common/src/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TitledPaneBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ToolBarBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusListBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TwoLevelFocusPopupBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java Changeset: 8b2acf78b060 Author: "Jasper Potts" Date: 2012-11-26 10:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8b2acf78b060 Fix for control skin needing two pulses after default skin change. ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 1956221ada12 Author: "Jasper Potts" Date: 2012-11-26 10:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1956221ada12 Fix for control skin needing two pulses after default skin change. ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 4e5a8c827dc4 Author: leifs Date: 2012-11-26 12:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4e5a8c827dc4 RT-24228: Add RTL support to Scrollbar / ScrollPane ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: a90b954395d7 Author: Paru Somashekar Date: 2012-11-26 12:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a90b954395d7 fix RT-26110 LineChart removes existing styles from custom symbols ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java Changeset: 769200bca5be Author: "Jasper Potts" Date: 2012-11-26 19:06 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/769200bca5be Fix by David for StyleManager to make user agent stylesheet changes clear all caches and do complete refresh. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 5d89eacf62cc Author: "Jasper Potts" Date: 2012-11-26 19:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5d89eacf62cc Added way to override a nodes pseudo class state for testing and theme design. It is disabled by default and can be enabled by -Djavafx.pseudoClassOverrideEnabled=true that was done to minimize any performance impact. Once that is enabled you can do myButton.getProperties().put("javafx.scene.Node.pseudoClassOverride", "hover"); to make it look in the hover state. ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 71a6192f9af2 Author: David Grieve Date: 2012-11-27 12:59 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/71a6192f9af2 RT-26525: check for null displayNode in ColorPickerSkin colorLabelVisible property invalidated method ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 60400c9e4ce7 Author: David Grieve Date: 2012-11-27 13:01 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/60400c9e4ce7 [TEST-ONLY] Ignore test in StyleablePropertyTest that fails with ArrayIndexOutOfBounds. A fix for the exception exists in another scrum, so this test should be restored after integration. ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java Changeset: 6fc99f747830 Author: flar Date: 2012-11-20 13:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6fc99f747830 Fix RT-25333: setPixels can ignore the x,y coordinates in the request ! javafx-ui-common/src/com/sun/javafx/image/ByteToBytePixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/ByteToIntPixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/IntToBytePixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/IntToIntPixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/PixelConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToByteConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToIntConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToByteConverter.java ! javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToIntConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/image/ConverterTest.java Changeset: 45aeaba1af4a Author: Felipe Heidrich Date: 2012-11-20 15:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/45aeaba1af4a RT-17392: Multi-line, multi-style, rich text support ! javafx-ui-common/src/javafx/scene/text/Text.java + javafx-ui-common/src/javafx/scene/text/TextFlow.java Changeset: cacf5b967ed3 Author: Pavel Safrata Date: 2012-11-21 10:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cacf5b967ed3 RT-26391: optimized local-to-scene transform property. ! javafx-ui-common/src/com/sun/javafx/scene/transform/TransformUtils.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/transform/Transform.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/transform/TransformUtilsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/TransformHelper.java ! javafx-ui-common/test/unit/javafx/scene/Node_LocalToParentTransform_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_LocalToSceneTransform_Test.java ! javafx-ui-common/test/unit/javafx/scene/transform/AffineOperationsTest.java ! javafx-ui-common/test/unit/javafx/scene/transform/TransformOperationsTest.java Changeset: 4e7d364feafc Author: Martin Sladecek Date: 2012-11-23 14:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4e7d364feafc impl_ method cleanup in Animation. ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java Changeset: 7a36755b17b5 Author: Milan Kubec Date: 2012-11-26 16:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a36755b17b5 fix of classpath related to move of the project from rt-closed repo to rt repo ! javafx-fxml/nbproject/project.xml Changeset: fe4bf1068eda Author: Yao Wang Date: 2012-11-26 13:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe4bf1068eda RT-24357 Text class change ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 7a82d94e9019 Author: Pavel Safrata Date: 2012-11-27 16:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a82d94e9019 TransformChangedEvent made final to be consistent with other events. ! javafx-ui-common/src/javafx/scene/transform/TransformChangedEvent.java Changeset: e732d95172cf Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-11-27 10:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e732d95172cf Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 12cce04e7847 Author: hudson Date: 2012-11-29 22:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/12cce04e7847 Added tag 8.0-b66 ! .hgtags From tbee at tbee.org Fri Nov 30 00:02:00 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 30 Nov 2012 09:02:00 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> Message-ID: <50B867F8.2060609@tbee.org> On 2012-11-29 23:51, Richard Bair wrote: > Having the constraints on the child is certainly the most natural solution with respect to how the FX APIs work. I think we cannot discount the fact that children is a full blown observable list and has the methods for keeping some, removing all, etc. When constraints are defined on the child node itself, it also works more naturally with FXML, and also (for what its worth) means that you can probably define the layout information in CSS and have it apply to a particular node as well. Which is a long-sought-after-feature. The big hang-up is, if the constraint is defined on the child, then we're left with either a map of constraints (current situation, except we could have direct API on the node for it rather than static methods on the parent), or we require an instance of check and a cast. At least, that is how I see the options when constraints are on the child. Or have an uber-constraint object with everything imaginable, but that obviously isn't scalable to 3rd party > layouts and sounds like an awful idea in any case. Any other ideas? Richard I do not agree with the statement that because children is a full blown observable list, we are obliged to use it. You use what suites best. An API should be setup so it is optimized for the most common scenario's. I have a big car in my drive way, but when taking the kids to school, I use the small one; it suits better for the task. OTOH when I have to drive my basketballteam to a match... How many JFX developers have, in their first JavaFX application, created a HBox layout, typed ".add", and hit ctrl-space... Then be confused because there is no sensible method to add the node and googled to discovered the getChildren method? And to go even further, how many developers have looked at that "hbox.getChildren().add(node)" line and wondered about the verbosity? So, all this FXML is great, but my first priority is a good and natural Java API. To me, getChildren and static methods are not it. Tom From tom.schindl at bestsolution.at Fri Nov 30 00:13:11 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 30 Nov 2012 09:13:11 +0100 Subject: Layouts with constraint classes In-Reply-To: <50B867F8.2060609@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> Message-ID: <50B86A97.4010500@bestsolution.at> Am 30.11.12 09:02, schrieb Tom Eugelink: > > On 2012-11-29 23:51, Richard Bair wrote: >> Having the constraints on the child is certainly the most natural >> solution with respect to how the FX APIs work. I think we cannot >> discount the fact that children is a full blown observable list and >> has the methods for keeping some, removing all, etc. When constraints >> are defined on the child node itself, it also works more naturally >> with FXML, and also (for what its worth) means that you can probably >> define the layout information in CSS and have it apply to a particular >> node as well. Which is a long-sought-after-feature. The big hang-up >> is, if the constraint is defined on the child, then we're left with >> either a map of constraints (current situation, except we could have >> direct API on the node for it rather than static methods on the >> parent), or we require an instance of check and a cast. At least, that >> is how I see the options when constraints are on the child. Or have an >> uber-constraint object with everything imaginable, but that obviously >> isn't scalable to 3rd party layouts and sounds like an awful idea in >> any case. Any other ideas? Richard > > I do not agree with the statement that because children is a full blown > observable list, we are obliged to use it. You use what suites best. An > API should be setup so it is optimized for the most common scenario's. I > have a big car in my drive way, but when taking the kids to school, I > use the small one; it suits better for the task. OTOH when I have to > drive my basketballteam to a match... > We are not obliged to use it but if wanted we can and if we don't have the setLayoutConstraint()-API on the node I can't. Having this layout-constraint API on Node gives us both what we want: a) you can have the convenience API on layout b) I can still use bulk operations c) There's not change needed in FXML infrastructure > How many JFX developers have, in their first JavaFX application, created > a HBox layout, typed ".add", and hit ctrl-space... Then be confused > because there is no sensible method to add the node and googled to > discovered the getChildren method? And to go even further, how many > developers have looked at that "hbox.getChildren().add(node)" line and > wondered about the verbosity? > > So, all this FXML is great, but my first priority is a good and natural > Java API. To me, getChildren and static methods are not it. > I understood Richards last comment in the way that having the layout-constraint on each node has the benefit that no changes to FXML are needed. I think what Richard and myself are after is to have an API that allows to have a Java-API which does not make the FXML case harder. 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 tbee at tbee.org Fri Nov 30 00:27:01 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 30 Nov 2012 09:27:01 +0100 Subject: Layouts with constraint classes In-Reply-To: <50B86A97.4010500@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> Message-ID: <50B86DD5.7040603@tbee.org> On 2012-11-30 09:13, Tom Schindl wrote: > We are not obliged to use it but if wanted we can and if we don't have the setLayoutConstraint()-API on the node I can't. Having this layout-constraint API on Node gives us both what we want: a) you can have the convenience API on layout b) I can still use bulk operations c) There's not change needed in FXML infrastructure I believe 99% of the use cases will not involve operations that benefit from getChildren; most use case will be simple "add-node-to-layout-with-specific-constaints". This is what the API should be optimized for. Maybe we can find some source that helps us define the most common use cases. > I understood Richards last comment in the way that having the layout-constraint on each node has the benefit that no changes to FXML are needed. I think what Richard and myself are after is to have an API that allows to have a Java-API which does not make the FXML case harder. But the things that are needed to make FXML not harder (or make the FXML format readable) should not pollute the Java API. Glue IMHO should be put in a separate class or file. Tom From zonski at gmail.com Fri Nov 30 01:10:52 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 30 Nov 2012 20:10:52 +1100 Subject: Layouts with constraint classes In-Reply-To: <50B86DD5.7040603@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> Message-ID: Disagree that there are not a lot of use cases for getChildren (observable/binding would be a start) but the point is completely moot since I would guess there is a big fat zero chance of that kind of change happening - backwards compatibility won't even let us have interfaces "just in case", getting rid of getChildren would be out of the park. Agree that the process should (in all things) be 1) define the ideal Java API first 2) use glue to adapt higher level tools/APIs to that ideal Java one 3) only compromise the ideal API as a last resort if the glue can't do it (should be extremely rare). In general, from what I have seen Richard has done a pretty good job at this (except in the case of CSS where the exact opposite was done), with Builders being a great example/pattern. I'm pretty confident if you specified your ideal FXML it could be built using builders - possibly with some modifications and at worse some tweaks to the FXMLLoader. Changing the Java Node classes should not be needed for this. Up to you guys, but I think your conversation is best focused on the Java API and leave FXML out of it until the end. On the Java API side of it, my 2c: - The current API works fine and doesn't "need" to be changed but it is also a bit weird and unintuitive so it could be improved. - For backwards compatibility any proposed change would likely need to be in-addition-to the current API (i.e. addition of extra convenience methods, not removal or major refactoring). - Builders provide a way to specify an alternate API (in Java as much as FXML) for this exact goal of convenience and intuitiveness, e.g. you could easily have a HboxBuilder.add(Node, HboxConstraints) if you want that called the static methods on the Node (based on HboxConstraints), and then added the Node to the HBox. A suite of enhanced builders sounds like a great mini-project for JFXtras, with the good ones eventually making it into JFX official. For me personally this is all a pretty low priority (it's just that this deployment code is so painful I am easily distracted) so I'll leave you guys to it unless you want me to chime in on the FXML side of it (I've hand written a hell of a lot of FXML, written custom components with builders in it, and had a good few debates/arguments with Greg about some of the internals). I am still a little curious though, is Greg no longer working on this, and if so who is now responsible for FXML? On Fri, Nov 30, 2012 at 7:27 PM, Tom Eugelink wrote: > On 2012-11-30 09:13, Tom Schindl wrote: > >> We are not obliged to use it but if wanted we can and if we don't have >> the setLayoutConstraint()-API on the node I can't. Having this >> layout-constraint API on Node gives us both what we want: a) you can have >> the convenience API on layout b) I can still use bulk operations c) There's >> not change needed in FXML infrastructure >> > > I believe 99% of the use cases will not involve operations that benefit > from getChildren; most use case will be simple "add-node-to-layout-with-**specific-constaints". > This is what the API should be optimized for. Maybe we can find some source > that helps us define the most common use cases. > > > > I understood Richards last comment in the way that having the >> layout-constraint on each node has the benefit that no changes to FXML are >> needed. I think what Richard and myself are after is to have an API that >> allows to have a Java-API which does not make the FXML case harder. >> > > But the things that are needed to make FXML not harder (or make the FXML > format readable) should not pollute the Java API. Glue IMHO should be put > in a separate class or file. > > Tom > > > From tbee at tbee.org Fri Nov 30 01:23:04 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 30 Nov 2012 10:23:04 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> Message-ID: <50B87AF8.3050200@tbee.org> On 2012-11-30 10:10, Daniel Zwolenski wrote: > Disagree that there are not a lot of use cases for getChildren (observable/binding would be a start) but the point is completely moot since I would guess there is a big fat zero chance of that kind of change happening - backwards compatibility won't even let us have interfaces "just in case", getting rid of getChildren would be out of the park. Correct, my approach does not get rid of getChildren; it is a very value collection, it just not the optimal API for developers IMHO. Richard also said he would like to deprecate the static methods. I agree, so that is my focus. The builders could indeed make the API better, but they're basically a workaround. And it fails to address the multiple layouts scenario. So knowing we're going to have a long lived legacy there, let's not make it more heavy. (Although I'm a proponent of cleaning up deprecated stuff on major releases.) Tom From milan.kubec at oracle.com Fri Nov 30 01:56:34 2012 From: milan.kubec at oracle.com (Milan Kubec) Date: Fri, 30 Nov 2012 10:56:34 +0100 Subject: Extending builders In-Reply-To: <50B62D51.6020601@oracle.com> References: <4FFD905B.9070009@oracle.com> <205F8375-5C20-439C-A45D-E5A914FD64B0@oracle.com> <50AE394A.4060703@oracle.com> <50AE3E5B.6010400@oracle.com> <50B62D51.6020601@oracle.com> Message-ID: <50B882D2.4000402@oracle.com> Hello, I'm slightly more for the second option: having "BuilderProperty" annotation for curent methods, because then builder authors are free do do anything they want without worying about breaking SB and FXML introspection functionality and creating new annotation to distinguish some new methods of functionality. BuilderProperty annotation can have parameters to fine tune property handling via introspection. Milan Dne 28.11.2012 16:27, Eva Krejcirova napsal(a): > There will certainly be methods with one argument, so this means that > there must be a way for SceneBuilder and FXML to tell these methods > apart from the property methods. > We can annotate the convenience methods by special annotation (e.g. > BuilderConvenienceMethod). > Or we could add an annotation (e.g. BuilderProperty) to the methods > which correspond to properties (= the methods which are currently in > the builders). > > Eva > > On 22.11.2012 16:01, Daniel Fuchs wrote: >> On 11/22/12 3:40 PM, Eva Krejcirova wrote: >>> Hi, >>> >>> There is one more thing which needs to be sorted out before adding new >>> methods to builders: >>> SceneBuilder and FXML use builders to find names of properties of a >>> class, so they need to have a way to differentiate between the new >>> convenience methods and the methods which correspond to properties of a >>> class. Daniel, is this still true? >>> >>> Last time we discussed this, Daniel suggested to annotate these new >>> convenience methods. If we go this way, we need to create a new runtime >>> annotation (and find a name for it :-) ) >>> >>> Eva >> >> Hi Eva, >> >> Yes this is still true. Note that SceneBuilder actually uses >> builders only in special cases - for WebView - for instance - >> because of the fake location attribute available on WebViewBuilder >> only - and for any type which has no public constructors (e.g.: all >> charts, Insets, etc...) >> >> However - SceneBuilder discovers whether there are constructor >> properties by introspecting ClassX and ClassXBuilder and comparing >> the results: it takes the name of all the single parameter >> instance methods in ClassXBuilder which returns a builder, >> remove the names of all writable (getter+setter) properties >> found in ClassX, and what remain are assumed to be constructor >> properties. >> >> As long as the convenience methods have more than 1 parameter >> (varargs count for 1) then this logic should remain valid. >> >> The FXMLLoader's JavaFXBuilderFactory also introspects builders >> in order to find out writable properties and type of properties, >> so that's another place you will have to look at >> (class JavaFXBuilderFactory.JavaFXBuilder). >> >> best regards, >> >> -- daniel >> >> >> > From zonski at gmail.com Fri Nov 30 01:59:12 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 30 Nov 2012 20:59:12 +1100 Subject: Layouts with constraint classes In-Reply-To: <50B87AF8.3050200@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> Message-ID: > And it fails to address the multiple layouts scenario. It doesn't fail to address it - there are plenty of options for this currently (e.g. move the constraint specification to the container builder, or add a binding to the 'parent' that changes the constraints to match, etc, etc). It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. > Although I'm a proponent of cleaning up deprecated stuff on major releases. Me too - in theory. The JRE AU policy means every Webstart, Applet and regular app running using a normally installed JRE will break the day that major version is released. Maybe there's hope with Java 9 with Jigsaw, but I doubt it. The option to be able to clean the API was one of the sacrifices for including JFX in the JRE ( http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000401.html ). Right, no more distractions. Back to the JavaFX packager code for me. I am trying to work out whether I am a simpleton with no grasp on the complexities this code is trying to overcome, or whether the native bundler code is just ridiculously over engineered. Call me a dreamer but having a launcher.exe, a jfx launcher main class (that searches the registry!), an optional jfx launcher pre-loader, and a fall-back JRE link seems a tad like overkill when you have a co-bundled JRE. From tbee at tbee.org Fri Nov 30 02:20:08 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 30 Nov 2012 11:20:08 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> Message-ID: <50B88858.4080500@tbee.org> On 2012-11-30 10:59, Daniel Zwolenski wrote: > It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. From zonski at gmail.com Fri Nov 30 05:11:34 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 00:11:34 +1100 Subject: Layouts with constraint classes In-Reply-To: <50B88858.4080500@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AC9317.90306@tbee.org> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> Message-ID: Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. I knocked up a very rough sample for you quickly. The FXML looks like this:
(see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml ) I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java And then a specific instance of HBoxConstraints: https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink wrote: > On 2012-11-30 10:59, Daniel Zwolenski wrote: > >> It just doesn't do it the exact way you suggest where you specify >> multiple possibilities directly in the child in case it ends up in a >> different parent - not an approach I agree with anyway (see my previous >> comments), but that's just my opinion. >> > > Just to make sure my suggestion is not misunderstood, it does not specify > multiple possibilities in the child, but in the layout. > > > > > > > > From franck.wolff at graniteds.org Fri Nov 30 05:33:09 2012 From: franck.wolff at graniteds.org (Franck Wolff) Date: Fri, 30 Nov 2012 08:33:09 -0500 Subject: Fwd: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: The features and the samples you are looking for exist and are available through tutorials: http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ We don't have any other material right now (such as videos or a test drive), but we did our best to make things as clear and easy as possible. And yes, if you open each application described in those tutorials twice, your changes in one of them will be reflected in the other one "in real time". Franck. On Nov 29, 2012 3:59 PM, "Richard Bair" wrote: > Cool! Are there any online samples? BlazeDS I remember had some great > sample pages or videos (I don't remember which) that showed things such as > two browser windows open, writing in one and auto-updating the UI in the > other, etc. I'm wondering if graniteds has anything of that kind? > > Thanks > Richard > > On Nov 29, 2012, at 8:21 AM, Franck Wolff > wrote: > > > Hi all, > > > > We have long been providing a solution to Flex developers, and have > > recently released a version of our product that supports JavaFX 2.2: > Granite > > Data Services (GraniteDS) is a comprehensive > > development and integration solution for building Flex (and now JavaFX) / > > JavaEE RIA applications. The entire framework is open-source and released > > under the LGPL v2 license. > > > > To know more about what GraniteDS provides to JavaFX developers, see a > > comprehensive documentation > > here< > http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html > > > > . > > > > The full announcement about this new 3.0.0.M1 version is available > > here< > http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ > >, > > together with several links to tutorials and resources. This first public > > release of a GraniteDS for JavaFX is clearly in a beta stage at this > time, > > but with the help of your feedback, we hope to be able to provide new > > milestones and a stable 3.0.0.GA within the coming months. > > > > Here are some additional links: > > > > > > - Community Site: http://www.graniteds.org/ > > - Blog: http://granitedataservices.com/blog/ > > - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds > > - Bug Tracking System (Jira): > > > http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > - Nightly Builds (Bamboo): > > http://www.graniteds.org/bamboo/allPlans.action > > - Source Repository: https://github.com/graniteds > > - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ > > > > Your feedback will be greatly appreciated, > > > > Franck Wolff > > -- Franck Wolff Granite Data Services Inc. CEO & Founder From franck.wolff at graniteds.org Fri Nov 30 06:01:42 2012 From: franck.wolff at graniteds.org (Franck Wolff) Date: Fri, 30 Nov 2012 09:01:42 -0500 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: (sorry for the double post, I first replied to Richard without the forum in copy and then tried today to forward my answer, which is not in the same thread, my fault, first time in this forum, won't do it again...) -------------------- The features and the samples you are looking for exist and are available through tutorials: http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ We don't have any other material right now (such as videos or a test drive), but we did our best to make things as clear and easy as possible. And yes, if you open each application described in those tutorials twice, your changes in one of them will be reflected in the other one "in real time". -------------------- More on the subject: Richard has tried to run the 2nd tutorial on a Mac (Mountain Lion, java 1.7.0_09 64 bits) and it's causing some ugly random crashes of the JVM: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff900dc250, pid=366, tid=9991 # # JRE version: 7.0_09-b05 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libobjc.A.dylib+0x6250] objc_msgSend+0x10 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/franckwolff/shop-admin/shop-admin-javafx/javafx/hs_err_pid366.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Abort trap: 6 I have been able to reproduce the issue (same environment) and I really don't know what to do with this error ("outside the Java Virtual Machine in native code")... You shouldn't experience this problem on Windows, and hopefully on Linux. Franck. 2012/11/29 Richard Bair > Cool! Are there any online samples? BlazeDS I remember had some great > sample pages or videos (I don't remember which) that showed things such as > two browser windows open, writing in one and auto-updating the UI in the > other, etc. I'm wondering if graniteds has anything of that kind? > > Thanks > Richard > > On Nov 29, 2012, at 8:21 AM, Franck Wolff > wrote: > > > Hi all, > > > > We have long been providing a solution to Flex developers, and have > > recently released a version of our product that supports JavaFX 2.2: > Granite > > Data Services (GraniteDS) is a comprehensive > > development and integration solution for building Flex (and now JavaFX) / > > JavaEE RIA applications. The entire framework is open-source and released > > under the LGPL v2 license. > > > > To know more about what GraniteDS provides to JavaFX developers, see a > > comprehensive documentation > > here< > http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html > > > > . > > > > The full announcement about this new 3.0.0.M1 version is available > > here< > http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ > >, > > together with several links to tutorials and resources. This first public > > release of a GraniteDS for JavaFX is clearly in a beta stage at this > time, > > but with the help of your feedback, we hope to be able to provide new > > milestones and a stable 3.0.0.GA within the coming months. > > > > Here are some additional links: > > > > > > - Community Site: http://www.graniteds.org/ > > - Blog: http://granitedataservices.com/blog/ > > - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds > > - Bug Tracking System (Jira): > > > http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > - Nightly Builds (Bamboo): > > http://www.graniteds.org/bamboo/allPlans.action > > - Source Repository: https://github.com/graniteds > > - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ > > > > Your feedback will be greatly appreciated, > > > > Franck Wolff > > -- Franck Wolff Granite Data Services Inc. CEO & Founder From zonski at gmail.com Fri Nov 30 07:42:22 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 02:42:22 +1100 Subject: The competition Message-ID: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> It's the space that oracle doesn't care about but just for reference here's some stuff that web are doing: http://blog.alexmaccaw.com/the-next-web My analysis of this market segment, for what it is worth: Web is moving faster than jfx, with a head start in a lot of areas, with big backing from all vendors and a deployment model that is seamless across more platforms. Jfx being based on established, type-safe java and having all the java libraries/tools makes it a big draw card for developers compared to jscript. However there is little benefit to users and it is users who will drive the choice of technology. Feature wise jfx and web are generally on par - in many cases web is better but generally in areas not fully standardized yet so limited to certain browsers etc. Standardization is happening quickly in web unlike the days of old. In general web is improving faster than the current jfx road map. In JFX's favour is the java brand and libraries from java's dominance in the server space. Java's reputation plus one-language/WORA end to end are the key selling points for jfx. One-language/WORA is currently a perceived advantage only since jfx does not work on as many platforms as web and it is only server side that jscript does not currently compete. Developers are starting to realize that jfx is not delivering on wora and business decision makers are unlikely to be convinced by developers without WORA as a selling point. Several early forays of jscript into the server space have already happened with some minor success. Expect this to be a growth area and the wora/one-language advantage could switch, making it one of the draw cards of jscript over jfx within the next 12 months (though java on the server is likely to dominate for many years still through pure momentum and market position). Jscript is also being enhanced to have more appeal to developers, however it has a lot of legacy perceptions to overcome before it will appeal to traditional server developers. Performance is also a perceived advantage of jfx (web is currently perceived as slow, whereas as 'desktop' is seen as fast) however in practice jfx is no faster than modern browsers and web is increasingly improving performance. The perceived advantage will be short lived especially with windows 8 driving more pc upgrades and the inevitable drop off of ie7 and ie8 (responsible for most of the negative performance opinions). Web is rapidly addressing its perceived performance issues. The mobile space is currently still open. The technology that provides good cross-mobile development will dominate here. Existing solutions like phone gap have had mixed success. WORA is the selling point but poor user experience and performance are the main complaints. Jscript based solutions are improving however and there are a number of vendors targeting this space. Phones typically have a 2 to 3 year life cycle so as we start to see the drop off of older android devices, jscript solutions will become more performant and user friendly. Javafx has a small window, maybe 12 months at most, of opportunity to capture some of the consumer market space. Mobile is particularly open but web is also in a transition state and some aggressive positioning could see jfx capitalize on the java brand to establish itself before web achieves its current trajectory. Claiming some market space now coupled with java server dominance could see jfx survive the onslaught of html5 frenzy. Deployment is currently the number one inhibitor to both the web and mobile space. A good deployment model is needed on major platforms to have broad range appeal. Should javafx not gain market space before the "html5" era truly establishes itself then jfx is unlikely to ever make it into the consumer space in its current form. It is likely to continue to have some market share in select back-office environments (particularly those that oracle is directly working with) and may spread a little wider if alternate deployment solutions such as running javafx ontop of jscript, or compiling to jscript are implemented. In the embedded space, java and javafx is well positioned with hardware/technology at the sweet point for embedded jre usage. Expect this to be a growth area over the next few years with javafx likely to dominate this space. From tobi at ultramixer.com Fri Nov 30 12:58:30 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 30 Nov 2012 21:58:30 +0100 Subject: Porting from Swing - JavaFX 2 for JDK 6 for Mac needed Message-ID: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> Hi, we plan to develop new module for our current Swing based software in JavaFX 2. Our commercial swing apps are based on JDK6 because OpenJDK7 for mac is not really ready for production use (graphical issues, no retina support, no 32bit support, ?) So currently we can't port our swing apps to OpenJDK 7 on Mac (JDK7 for windows is good). To develop new peaces of our swing based apps in JavaFX 2 we need JFX for JDK6 on mac! Currently there is only JFX2 for JDK6 on windows available. Is it possible to use JFX2 on (32bit) JDK6 on mac? Best regards, Tobi From richard.bair at oracle.com Fri Nov 30 13:22:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 30 Nov 2012 13:22:29 -0800 Subject: The competition In-Reply-To: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> Message-ID: <280FE4BC-84FC-4A09-88C2-12042C0FADF1@oracle.com> > in practice jfx is no faster than modern browsers In every test I've seen, we are are much as 10x faster than browsers (for example, on PI). Do you have any data to suggest the browser actually is comparable? Or are you just saying that for simple pages that don't need to scale, the performance of a browser fits within 60fps and thus you don't see a difference? From richard.bair at oracle.com Fri Nov 30 13:23:34 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 30 Nov 2012 13:23:34 -0800 Subject: Porting from Swing - JavaFX 2 for JDK 6 for Mac needed In-Reply-To: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> References: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> Message-ID: <3CE6D20C-9763-4F7C-B486-28AEEDD8F3D6@oracle.com> Hi Tobi, JavaFX is only supported on Java 7. Maybe it will work on 32-bit Java 6, but you'd be on your own attempting it. Thanks Richard On Nov 30, 2012, at 12:58 PM, Tobias Bley wrote: > Hi, > > we plan to develop new module for our current Swing based software in JavaFX 2. Our commercial swing apps are based on JDK6 because OpenJDK7 for mac is not really ready for production use (graphical issues, no retina support, no 32bit support, ?) > > So currently we can't port our swing apps to OpenJDK 7 on Mac (JDK7 for windows is good). To develop new peaces of our swing based apps in JavaFX 2 we need JFX for JDK6 on mac! Currently there is only JFX2 for JDK6 on windows available. > > Is it possible to use JFX2 on (32bit) JDK6 on mac? > > Best regards, > Tobi > From tobi at ultramixer.com Fri Nov 30 13:31:07 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 30 Nov 2012 22:31:07 +0100 Subject: Porting from Swing - JavaFX 2 for JDK 6 for Mac needed In-Reply-To: <3CE6D20C-9763-4F7C-B486-28AEEDD8F3D6@oracle.com> References: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> <3CE6D20C-9763-4F7C-B486-28AEEDD8F3D6@oracle.com> Message-ID: Hi Richard, JFX2 (from JDK7u9) doesn't work on JDK6 32bit (mac) because the libGlass.dylib doesn't support 32bit? Richard, how do Oracle think java developers should move from Swing to JFX2 if JFX2 only works on 64bit JDK7??? Best regards, Tobi Am 30.11.2012 um 22:23 schrieb Richard Bair : > Hi Tobi, > > JavaFX is only supported on Java 7. Maybe it will work on 32-bit Java 6, but you'd be on your own attempting it. > > Thanks > Richard > > On Nov 30, 2012, at 12:58 PM, Tobias Bley wrote: > >> Hi, >> >> we plan to develop new module for our current Swing based software in JavaFX 2. Our commercial swing apps are based on JDK6 because OpenJDK7 for mac is not really ready for production use (graphical issues, no retina support, no 32bit support, ?) >> >> So currently we can't port our swing apps to OpenJDK 7 on Mac (JDK7 for windows is good). To develop new peaces of our swing based apps in JavaFX 2 we need JFX for JDK6 on mac! Currently there is only JFX2 for JDK6 on windows available. >> >> Is it possible to use JFX2 on (32bit) JDK6 on mac? >> >> Best regards, >> Tobi >> > From richard.bair at oracle.com Fri Nov 30 13:31:06 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 30 Nov 2012 13:31:06 -0800 Subject: The competition In-Reply-To: <280FE4BC-84FC-4A09-88C2-12042C0FADF1@oracle.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <280FE4BC-84FC-4A09-88C2-12042C0FADF1@oracle.com> Message-ID: <4442A2ED-45EE-4AEE-80D3-91317FCE0376@oracle.com> On Nov 30, 2012, at 1:22 PM, Richard Bair wrote: >> in practice jfx is no faster than modern browsers > > In every test I've seen, we are are much as 10x faster than browsers (for example, on PI). Do you have any data to suggest the browser actually is comparable? Or are you just saying that for simple pages that don't need to scale, the performance of a browser fits within 60fps and thus you don't see a difference? Make sure this is stated accurately -- in some tests on some platforms I've seen more than 10x performance difference -- in other cases it is less, but in no case have I seen any test where we are slower than a browser -- any browser. Richard From richard.bair at oracle.com Fri Nov 30 13:33:04 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 30 Nov 2012 13:33:04 -0800 Subject: Porting from Swing - JavaFX 2 for JDK 6 for Mac needed In-Reply-To: References: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> <3CE6D20C-9763-4F7C-B486-28AEEDD8F3D6@oracle.com> Message-ID: <70F37F11-8F79-424D-A55F-A42D6B679C75@oracle.com> Hi Tobi, We haven't had many complaints thus far from Swing developers migrating on Mac. But besides that, we don't support the Java 6 VM, Apple does, and that limits what kind of things we can do with regards to integration and fixes. We don't have infinite resources. Apple is clearly leaving 32 bit behind and encouraging people to upgrade to Java 7. That's the way forward. Richard On Nov 30, 2012, at 1:31 PM, Tobias Bley wrote: > Hi Richard, > > JFX2 (from JDK7u9) doesn't work on JDK6 32bit (mac) because the libGlass.dylib doesn't support 32bit? > > Richard, how do Oracle think java developers should move from Swing to JFX2 if JFX2 only works on 64bit JDK7??? > > Best regards, > Tobi > > > Am 30.11.2012 um 22:23 schrieb Richard Bair : > >> Hi Tobi, >> >> JavaFX is only supported on Java 7. Maybe it will work on 32-bit Java 6, but you'd be on your own attempting it. >> >> Thanks >> Richard >> >> On Nov 30, 2012, at 12:58 PM, Tobias Bley wrote: >> >>> Hi, >>> >>> we plan to develop new module for our current Swing based software in JavaFX 2. Our commercial swing apps are based on JDK6 because OpenJDK7 for mac is not really ready for production use (graphical issues, no retina support, no 32bit support, ?) >>> >>> So currently we can't port our swing apps to OpenJDK 7 on Mac (JDK7 for windows is good). To develop new peaces of our swing based apps in JavaFX 2 we need JFX for JDK6 on mac! Currently there is only JFX2 for JDK6 on windows available. >>> >>> Is it possible to use JFX2 on (32bit) JDK6 on mac? >>> >>> Best regards, >>> Tobi >>> >> > From hang.vo at oracle.com Fri Nov 30 13:33:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 30 Nov 2012 21:33:01 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-25973: BorderConverter should not be public API Message-ID: <20121130213307.91B3E47C49@hg.openjdk.java.net> Changeset: 005267bc4e2e Author: rbair Date: 2012-11-30 13:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/005267bc4e2e Fix for RT-25973: BorderConverter should not be public API ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java From steve at winnall.ch Fri Nov 30 14:49:52 2012 From: steve at winnall.ch (Stephen Winnall) Date: Fri, 30 Nov 2012 23:49:52 +0100 Subject: The competition In-Reply-To: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> Message-ID: <90588816-1F17-4265-9920-65ED14B0D0E0@winnall.ch> Lots of good points in Daniel's post. I don't think we can emphasise them enough. My take on "web" vs "apps": It seems to me that "web" is driven by designers, whereas JavaFX and other client-side technologies are driven by programmers. Or putting it in blunt terms (as a programmer myself), the web tends to be good design driven by bad programming, whereas the client-side is often bad design programmed well. People like good design, but sooner or later they get fed up with bad programming too (thought they only see bad performance, slow upgrades, difficult integration and bugs. amongst other evils). On the whole, there are not a lot of Leonardo da Vincis out there uniting programming and design. No Leonardos means that programmers and designers have to learn to work together in coalition (separation of concerns?) if we really want to produce good stuff. Whichever of "web" and "apps" sorts this first has the advantage. JavaScript vs. Java should be a no-brainer. JavaScript was never designed for programming in the large but rather for moving bits of DOM around a screen. Surely some marketeer can put this to the decision makers? I'm not sure what the word is which describes the essential difference between "web" and "apps" in terms of regular use. The word "fluidity" comes to mind in the sense of creating natural transitions from one UI state to another. If form-based web interfaces which require browser refreshes are the answer, I don't understand the question. Native experience is another crucial battle in the war of "web" against "apps". Unfortunately, both sides interpret WORA as meaning "write once, rubbish anywhere". People need to have the native experience of the platform they are used to. It's only programmers and designers who use more than one platform (an insignificant minority in successful applications). The danger of WORA is that managers see it as the opportunity to get something for nothing, so the end-user becomes insignificant. Whoever first combines WORA with native experience on all significant platforms will win. The mobile space proves that end-users prefer "apps" over "web". The mobile market exploded with the introduction of Apple's App Store. Before that, nobody really cared about mobile "web" applications. But that brings us back to WORA, the native experience and "fluidity", which are equally important for mobiles. Deployment is just about the only objective argument *for* "web" that I can see. It's tied together with managerial control, which makes it less amenable to reason and a nasty combination to tackle. We are presumably in agreement that JavaFX is intended to be the technical make-over to replace Swing on the client side. So what is going to replace Web Start (JNLI)? It's got to be possible to push Java apps to any device reliably and effectively. Daniel writes that "it's the space that Oracle doesn't care about". I'd agree that Sun failed to grasp the importance of this, but can't we hope for better from Oracle? All these things suggest to me huge marketing opportunities for Java and JavaFX in the "apps" space (not just mobile, also on the desktop). However, I fear that the propaganda war is being lost: "web" has a lot of impetus behind it and "apps in Java" have missed a lot of opportunities. Just being the best technology doesn't count for much. Being technology-centric counts for even less. The history of IT is littered with better technologies which lost because they were badly marketed or badly managed. As I think Daniel is saying, that can happened again. And if it doesn't, it won't be because we are the good guys, but because we learnt to do marketing. Sorry about that, I'm feeling better now :-) Steve On 30 Nov 2012, at 16:42, Daniel Zwolenski wrote: > It's the space that oracle doesn't care about but just for reference here's some stuff that web are doing: > > http://blog.alexmaccaw.com/the-next-web > > My analysis of this market segment, for what it is worth: > > Web is moving faster than jfx, with a head start in a lot of areas, with big backing from all vendors and a deployment model that is seamless across more platforms. > > Jfx being based on established, type-safe java and having all the java libraries/tools makes it a big draw card for developers compared to jscript. However there is little benefit to users and it is users who will drive the choice of technology. Feature wise jfx and web are generally on par - in many cases web is better but generally in areas not fully standardized yet so limited to certain browsers etc. Standardization is happening quickly in web unlike the days of old. In general web is improving faster than the current jfx road map. > > In JFX's favour is the java brand and libraries from java's dominance in the server space. Java's reputation plus one-language/WORA end to end are the key selling points for jfx. > > One-language/WORA is currently a perceived advantage only since jfx does not work on as many platforms as web and it is only server side that jscript does not currently compete. Developers are starting to realize that jfx is not delivering on wora and business decision makers are unlikely to be convinced by developers without WORA as a selling point. > > Several early forays of jscript into the server space have already happened with some minor success. Expect this to be a growth area and the wora/one-language advantage could switch, making it one of the draw cards of jscript over jfx within the next 12 months (though java on the server is likely to dominate for many years still through pure momentum and market position). Jscript is also being enhanced to have more appeal to developers, however it has a lot of legacy perceptions to overcome before it will appeal to traditional server developers. > > Performance is also a perceived advantage of jfx (web is currently perceived as slow, whereas as 'desktop' is seen as fast) however in practice jfx is no faster than modern browsers and web is increasingly improving performance. The perceived advantage will be short lived especially with windows 8 driving more pc upgrades and the inevitable drop off of ie7 and ie8 (responsible for most of the negative performance opinions). Web is rapidly addressing its perceived performance issues. > > The mobile space is currently still open. The technology that provides good cross-mobile development will dominate here. Existing solutions like phone gap have had mixed success. WORA is the selling point but poor user experience and performance are the main complaints. Jscript based solutions are improving however and there are a number of vendors targeting this space. Phones typically have a 2 to 3 year life cycle so as we start to see the drop off of older android devices, jscript solutions will become more performant and user friendly. > > Javafx has a small window, maybe 12 months at most, of opportunity to capture some of the consumer market space. Mobile is particularly open but web is also in a transition state and some aggressive positioning could see jfx capitalize on the java brand to establish itself before web achieves its current trajectory. Claiming some market space now coupled with java server dominance could see jfx survive the onslaught of html5 frenzy. > > Deployment is currently the number one inhibitor to both the web and mobile space. A good deployment model is needed on major platforms to have broad range appeal. > > Should javafx not gain market space before the "html5" era truly establishes itself then jfx is unlikely to ever make it into the consumer space in its current form. It is likely to continue to have some market share in select back-office environments (particularly those that oracle is directly working with) and may spread a little wider if alternate deployment solutions such as running javafx ontop of jscript, or compiling to jscript are implemented. > > In the embedded space, java and javafx is well positioned with hardware/technology at the sweet point for embedded jre usage. Expect this to be a growth area over the next few years with javafx likely to dominate this space. > > > > From zonski at gmail.com Fri Nov 30 14:50:03 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 09:50:03 +1100 Subject: The competition In-Reply-To: <4442A2ED-45EE-4AEE-80D3-91317FCE0376@oracle.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <280FE4BC-84FC-4A09-88C2-12042C0FADF1@oracle.com> <4442A2ED-45EE-4AEE-80D3-91317FCE0376@oracle.com> Message-ID: <99BDDB9B-E979-4490-8645-97889B31D362@gmail.com> Hi Richard, There was a thread a couple of weeks ago on jfx performance to which myself and a couple of others responded but no one from Oracle did. The conclusion from that thread from people building rich jfx apps was that jfx was not providing smooth performance. Unless I missed it there's been nothing to negate that - the onus of making sure the perception is otherwise rests with oracle really. Perhaps jfx has a higher frame rate, I don't know. That's quite a narrow benchmark though and from my experience using jfx, and also building very similar applications in jscript (ie dynamically updating trees, tables, forms with page animations) the jfx app was noticeably laggy and/or jittery on reasonably high end win7 desktops and laptops. Those same computers running the latest version of Google Chrome achieve better visual outcomes for similarly complex/rich jscript screens. Whether this is what you mean by "simple" screens I couldn't say but I would say they are the standard, modern, popular, rich web application screens and my review was preceded with the statement that web was the context I was reviewing it in. As a side note, I also can't see any technical reason why Chrome for example would have any limitations on it that java doesn't have. They are both virtual machines that adapt a higher level language to the native OS. As I said in my email, performance is an area where historically browsers have been bad (opportunity for jfx) but it's also an area that browser vendors are heavily focused on and rapidly improving (risk for jfx). If jfx has a lead in this space, it will need to work hard to maintain it, and fast to capatilize on it. The raspberry pi would feature very low in terms of market share in the space I am talking about. Also it was all just my personal analysis of the space, provided as a side note to your main work since oracle has stated its not a space it is focusing on. Performance was just one small part of my breakdown of the space. The viability of jfx as a competitor to jscript in the web/consumer space (the purpose of my email) is based on a tapestry of factors. I meant only to highlight my view from the street and also I am using this analysis to determine what areas of jfx I am focusing on so it is helpful for me to put it in words. Basically I took on board your response to my Enterprise JFX working group proposal and I'm just doing what I said I thought needed doing instead of pushing oracle to do it. So that includes a maven plugin, analysis of the enterprise/consumer space and next I plan to release example code and a maven archetype for client-server jfx with security and db. These were the things I listed in my proposal. I'm not expecting oracle to care too much about this given its not a target space and my analysis was sent out more for the sub-group in this community who are in the same space of me (they are there and tend to email me directly instead of replying to the group for some reason). I'm always open to rebuttal and generally pretty good at taking on board corrections and better ideas if they are tangible. The performance one is hard to quantify currently because while there are many jscript apps out there to look at, there are very few (any?) publicly available, commercial quality jfx apps out there to compare to. If you can provide some example of real world apps where the jfx experience is better than can be achieved with jscript in the latest chrome or Firefox then I will very happily change my opinion. Cheers, Dan On 01/12/2012, at 8:31 AM, Richard Bair wrote: > > On Nov 30, 2012, at 1:22 PM, Richard Bair wrote: > >>> in practice jfx is no faster than modern browsers >> >> In every test I've seen, we are are much as 10x faster than browsers (for example, on PI). Do you have any data to suggest the browser actually is comparable? Or are you just saying that for simple pages that don't need to scale, the performance of a browser fits within 60fps and thus you don't see a difference? > > Make sure this is stated accurately -- in some tests on some platforms I've seen more than 10x performance difference -- in other cases it is less, but in no case have I seen any test where we are slower than a browser -- any browser. > > Richard From richard.bair at oracle.com Fri Nov 30 15:05:38 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 30 Nov 2012 15:05:38 -0800 Subject: The competition In-Reply-To: <99BDDB9B-E979-4490-8645-97889B31D362@gmail.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <280FE4BC-84FC-4A09-88C2-12042C0FADF1@oracle.com> <4442A2ED-45EE-4AEE-80D3-91317FCE0376@oracle.com> <99BDDB9B-E979-4490-8645-97889B31D362@gmail.com> Message-ID: <85A3B2A2-12A6-48AD-BF2B-BE3F02395D6F@oracle.com> > Perhaps jfx has a higher frame rate, I don't know. That's quite a narrow benchmark though and from my experience using jfx, and also building very similar applications in jscript (ie dynamically updating trees, tables, forms with page animations) the jfx app was noticeably laggy and/or jittery on reasonably high end win7 desktops and laptops. Those same computers running the latest version of Google Chrome achieve better visual outcomes for similarly complex/rich jscript screens. Whether this is what you mean by "simple" screens I couldn't say but I would say they are the standard, modern, popular, rich web application screens and my review was preceded with the statement that web was the context I was reviewing it in. This feedback is unfortunately not actionable, so I don't know how to help. WIthout a test case or benchmark to look at, all I can say is that we are not seeing anything like this on windows. There is an issue we're fixing right now regarding event starvation on windows, but that is unlikely to be what you noticed. We've had many customer conversations in the enterprise space where guys had tried web first, found it didn't even get close to the performance they needed, switched to JavaFX and were very pleased with the results. I just wanted to make sure that the claim that the browser was as fast as JavaFX didn't go without comment, because I've seen no data to support that. All the other points regarding deployment are of course irrefutable, which is why I didn't comment on any of that. > As a side note, I also can't see any technical reason why Chrome for example would have any limitations on it that java doesn't have. Two huge technical reasons: JavaScript and DOM. Both have "features" of their design that preclude the kinds of performance optimizations that we can do on Java / JavaFX. > The raspberry pi would feature very low in terms of market share in the space I am talking about. I mentioned PI, though even on desktop we're 5-10x faster on GUIMark text benchmark from any of the browsers. (10x Firefox). We haven't published these numbers because our benchmarks are not open source -- see below. > Also it was all just my personal analysis of the space, provided as a side note to your main work since oracle has stated its not a space it is focusing on. Performance was just one small part of my breakdown of the space. I know, but I wasn't going to let a statement that we're slower than browsers to go uncontested :-). From all the data I have (and I'm happy for any bug reports with benchmarks indicating areas we need to improve!) we're much faster than the browsers in all phases (images, text, and vectors). On Mac we have serious smoothness issues (we know what those are and are working on them), but we've not seen these issues on Windows. There are outstanding bug reports on things like the rendering performance of Paths and Lines, but even our results on GUIMark2 indicates we're much faster than the browser. > I'm always open to rebuttal and generally pretty good at taking on board corrections and better ideas if they are tangible. The performance one is hard to quantify currently because while there are many jscript apps out there to look at, there are very few (any?) publicly available, commercial quality jfx apps out there to compare to. If you can provide some example of real world apps where the jfx experience is better than can be achieved with jscript in the latest chrome or Firefox then I will very happily change my opinion. I'm working on getting our benchmarks open sourced with everything else. But if you've got a sample handy where the browser is faster, I'd love to see it and fix it. I'm manic about performance (ask the team). We have been very, very focused on performance from the get-go, complete with regular performance regression analysis, repeatable benchmarks, engineers who's full-time responsibility is performance analysis and tooling, benchmark tools, etc. Richard From hang.vo at oracle.com Fri Nov 30 15:33:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 30 Nov 2012 23:33:06 +0000 Subject: hg: openjfx/8/graphics/rt: Removed unused property that was added in 8.0 erroneously. Fix for RT-25937 Message-ID: <20121130233308.2CE6F47C51@hg.openjdk.java.net> Changeset: 204b00c41d61 Author: rbair Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/204b00c41d61 Removed unused property that was added in 8.0 erroneously. Fix for RT-25937 ! javafx-ui-common/src/javafx/scene/layout/Region.java From zonski at gmail.com Fri Nov 30 16:49:41 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 11:49:41 +1100 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: Websockets are a powerful emerging option. Nice use of them in this project and nice fallback onto polling given the newness of Websockets. Imagine how much more powerful those demos would be if users could run them with a couple of clicks - sorry, couldn't resist. On 01/12/2012, at 1:01 AM, Franck Wolff wrote: > (sorry for the double post, I first replied to Richard without the forum in > copy and then tried today to forward my answer, which is not in the same > thread, my fault, first time in this forum, won't do it again...) > > -------------------- > > The features and the samples you are looking for exist and are available > through tutorials: > > http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ > > http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ > > We don't have any other material right now (such as videos or a test > drive), but we did our best to make things as clear and easy as possible. > > And yes, if you open each application described in those tutorials twice, > your changes in one of them will be reflected in the other one "in real > time". > -------------------- > > More on the subject: Richard has tried to run the 2nd tutorial on a Mac > (Mountain Lion, java 1.7.0_09 64 bits) and it's causing some ugly random > crashes of the JVM: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fff900dc250, pid=366, tid=9991 > # > # JRE version: 7.0_09-b05 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # C [libobjc.A.dylib+0x6250] objc_msgSend+0x10 > # > # Failed to write core dump. Core dumps have been disabled. To enable core > dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/franckwolff/shop-admin/shop-admin-javafx/javafx/hs_err_pid366.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > Abort trap: 6 > > I have been able to reproduce the issue (same environment) and I really > don't know what to do with this error ("outside the Java Virtual Machine in > native code")... > > You shouldn't experience this problem on Windows, and hopefully on Linux. > > Franck. > > 2012/11/29 Richard Bair > >> Cool! Are there any online samples? BlazeDS I remember had some great >> sample pages or videos (I don't remember which) that showed things such as >> two browser windows open, writing in one and auto-updating the UI in the >> other, etc. I'm wondering if graniteds has anything of that kind? >> >> Thanks >> Richard >> >> On Nov 29, 2012, at 8:21 AM, Franck Wolff >> wrote: >> >>> Hi all, >>> >>> We have long been providing a solution to Flex developers, and have >>> recently released a version of our product that supports JavaFX 2.2: >> Granite >>> Data Services (GraniteDS) is a comprehensive >>> development and integration solution for building Flex (and now JavaFX) / >>> JavaEE RIA applications. The entire framework is open-source and released >>> under the LGPL v2 license. >>> >>> To know more about what GraniteDS provides to JavaFX developers, see a >>> comprehensive documentation >>> here< >> http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html >>> >>> . >>> >>> The full announcement about this new 3.0.0.M1 version is available >>> here< >> http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ >>> , >>> together with several links to tutorials and resources. This first public >>> release of a GraniteDS for JavaFX is clearly in a beta stage at this >> time, >>> but with the help of your feedback, we hope to be able to provide new >>> milestones and a stable 3.0.0.GA within the coming months. >>> >>> Here are some additional links: >>> >>> >>> - Community Site: http://www.graniteds.org/ >>> - Blog: http://granitedataservices.com/blog/ >>> - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds >>> - Bug Tracking System (Jira): >>> >> http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel >>> - Nightly Builds (Bamboo): >>> http://www.graniteds.org/bamboo/allPlans.action >>> - Source Repository: https://github.com/graniteds >>> - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ >>> >>> Your feedback will be greatly appreciated, >>> >>> Franck Wolff >> >> > > > -- > Franck Wolff > Granite Data Services Inc. > CEO & Founder From tbee at tbee.org Fri Nov 30 22:28:28 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 01 Dec 2012 07:28:28 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> Message-ID: <50B9A38C.5060905@tbee.org> Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C. Tom On 2012-11-30 14:11, Daniel Zwolenski wrote: > Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? > > Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. > > I knocked up a very rough sample for you quickly. The FXML looks like this: > > > > > > > > >
> > >
> > > > (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml) > > I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): > https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java > > And then a specific instance of HBoxConstraints: > https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java > > Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. > > So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. > > > > > On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink > wrote: > > On 2012-11-30 10:59, Daniel Zwolenski wrote: > > It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. > > > Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. > > > > > > > > > From zonski at gmail.com Fri Nov 30 23:01:27 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 18:01:27 +1100 Subject: Layouts with constraint classes In-Reply-To: <50B9A38C.5060905@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AD055E.9080301@bestsolution.at> <50AD1724.3090305@tbee.org> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9A38C.5060905@tbee.org> Message-ID: <1821A591-267F-4D56-A769-17682D0C9AC9@gmail.com> You've lost me. What are you expecting the actual view to look like with this FXML? If I interpret it literally you've defined two HBox's one after the other. The first one has no children and an unused constraint, the second one has a Label in it with a constraint on it. I'm guessing you are trying to do something more but it's not real clear what that more is? On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: > Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C. > > > > > > > > > > Tom > > > On 2012-11-30 14:11, Daniel Zwolenski wrote: >> Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? >> >> Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. >> >> I knocked up a very rough sample for you quickly. The FXML looks like this: >> >> >> >> >> >> >> >> >>
>> >> >>
>> >> >> >> (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml) >> >> I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): >> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java >> >> And then a specific instance of HBoxConstraints: >> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java >> >> Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. >> >> So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. >> >> >> >> >> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink > wrote: >> >> On 2012-11-30 10:59, Daniel Zwolenski wrote: >> >> It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. >> >> >> Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. >> >> >> >> >> >> >> >> >> > From tbee at tbee.org Fri Nov 30 23:17:59 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 01 Dec 2012 08:17:59 +0100 Subject: Layouts with constraint classes In-Reply-To: <1821A591-267F-4D56-A769-17682D0C9AC9@gmail.com> References: <4FFEDD3B.6030109@oracle.com> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9A38C.50 60905@tbee.org> <1821A591-267F-4D56-A769-17682D0C9AC9@gmail.co m> Message-ID: <50B9AF27.6040903@tbee.org> Because of animation the label may move from one HBox to the other. This is the reason why the current approach stores constraints inside the node, so that when it moves from layout A to B, the constraints also move. My approach allows to specify different constraints for the same node in each layout. You are right that there should be a parent layout, I left it out to not confuse things, but apparently that is confusing :-) On 2012-12-01 08:01, Daniel Zwolenski wrote: > You've lost me. What are you expecting the actual view to look like with this FXML? > > If I interpret it literally you've defined two HBox's one after the other. The first one has no children and an unused constraint, the second one has a Label in it with a constraint on it. I'm guessing you are trying to do something more but it's not real clear what that more is? > > > > On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: > >> Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C. >> >> >> >> >> >> >> >> >> >> Tom >> >> >> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>> Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? >>> >>> Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. >>> >>> I knocked up a very rough sample for you quickly. The FXML looks like this: >>> >>> >>> >>> >>> >>> >>> >>> >>>
>>> >>> >>>
>>> >>> >>> >>> (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml) >>> >>> I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): >>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java >>> >>> And then a specific instance of HBoxConstraints: >>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java >>> >>> Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. >>> >>> So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. >>> >>> >>> >>> >>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink > wrote: >>> >>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>> >>> It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. >>> >>> >>> Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. >>> >>> >>> >>> >>> >>> >>> >>> >>> From zonski at gmail.com Fri Nov 30 23:38:55 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 18:38:55 +1100 Subject: Layouts with constraint classes In-Reply-To: <50B9AF27.6040903@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50AD4AD7.5030301@bestsolution.at> <50AE7435.8020503@tbee.org> <50AF4B23.9000404@bestsolution.at> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9A38C.50 60905@tbee.org> <1821A591-267F-4D56-A769-17682D0C9AC9@gmail.co m> <50B9AF27.6040903@tbee.org> Message-ID: Ah ok, so in the first hbox you are saying when the "arrow" node is moved into here use these new constraints. I think I've got you now. That should be do-able using some more helper classes. I can knock some up but my first thought would be to do it as part of the animation since its the thing that has the most knowledge about what's going on and why. How/where do you define and trigger your animation - are you specifying it in the FXML? If so the constraints could be part of that eg. (made up pseudo FXML): > (also slightly confusing is that the constraints you are using aren't applicable to HBox) If you don't like that approach I can knock up the alternative? On 01/12/2012, at 6:17 PM, Tom Eugelink wrote: > Because of animation the label may move from one HBox to the other. This is the reason why the current approach stores constraints inside the node, so that when it moves from layout A to B, the constraints also move. My approach allows to specify different constraints for the same node in each layout. > > You are right that there should be a parent layout, I left it out to not confuse things, but apparently that is confusing :-) > > > > > > > > > > > > > On 2012-12-01 08:01, Daniel Zwolenski wrote: >> You've lost me. What are you expecting the actual view to look like with this FXML? >> >> If I interpret it literally you've defined two HBox's one after the other. The first one has no children and an unused constraint, the second one has a Label in it with a constraint on it. I'm guessing you are trying to do something more but it's not real clear what that more is? >> >> >> >> On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: >> >>> Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Tom >>> >>> >>> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>>> Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? >>>> >>>> Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. >>>> >>>> I knocked up a very rough sample for you quickly. The FXML looks like this: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>
>>>> >>>> >>>>
>>>> >>>> >>>> >>>> (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml) >>>> >>>> I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): >>>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java >>>> >>>> And then a specific instance of HBoxConstraints: >>>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java >>>> >>>> Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. >>>> >>>> So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. >>>> >>>> >>>> >>>> >>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink > wrote: >>>> >>>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>>> >>>> It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. >>>> >>>> >>>> Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> > From tbee at tbee.org Fri Nov 30 23:47:09 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 01 Dec 2012 08:47:09 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9A38C.50 60905@tbee.org> <1821A591-267F-4D56-A769-17682D0C9AC9@gmail.co m> <50B9AF27.6040903@tbee.org> Message-ID: <50B9B5FD.5020501@tbee.org> Yes, correct :-) The approach where the constraint is set in the animation feels procedural and not declarative to me. Like you say yourself, I think it should be define like: when node X is part of this layout, use these constraints. In this way it is not relevant where the animation is defined or how the node got there. Tom On 2012-12-01 08:38, Daniel Zwolenski wrote: > Ah ok, so in the first hbox you are saying when the "arrow" node is moved into here use these new constraints. I think I've got you now. > > That should be do-able using some more helper classes. I can knock some up but my first thought would be to do it as part of the animation since its the thing that has the most knowledge about what's going on and why. > > How/where do you define and trigger your animation - are you specifying it in the FXML? If so the constraints could be part of that eg. (made up pseudo FXML): > > > >> > > > > (also slightly confusing is that the constraints you are using aren't applicable to HBox) > > If you don't like that approach I can knock up the alternative? > > > > On 01/12/2012, at 6:17 PM, Tom Eugelink wrote: > >> Because of animation the label may move from one HBox to the other. This is the reason why the current approach stores constraints inside the node, so that when it moves from layout A to B, the constraints also move. My approach allows to specify different constraints for the same node in each layout. >> >> You are right that there should be a parent layout, I left it out to not confuse things, but apparently that is confusing :-) >> >> >> >> >> >> >> >> >> >> >> >> >> On 2012-12-01 08:01, Daniel Zwolenski wrote: >>> You've lost me. What are you expecting the actual view to look like with this FXML? >>> >>> If I interpret it literally you've defined two HBox's one after the other. The first one has no children and an unused constraint, the second one has a Label in it with a constraint on it. I'm guessing you are trying to do something more but it's not real clear what that more is? >>> >>> >>> >>> On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: >>> >>>> Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Tom >>>> >>>> >>>> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>>>> Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? >>>>> >>>>> Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. >>>>> >>>>> I knocked up a very rough sample for you quickly. The FXML looks like this: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>
>>>>> >>>>> >>>>>
>>>>> >>>>> >>>>> >>>>> (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml) >>>>> >>>>> I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): >>>>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java >>>>> >>>>> And then a specific instance of HBoxConstraints: >>>>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java >>>>> >>>>> Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. >>>>> >>>>> So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink > wrote: >>>>> >>>>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>>>> >>>>> It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. >>>>> >>>>> >>>>> Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>